关于自动驾驶:从哲学源头思考自动驾驶网络架构设计

摘要：本篇从哲学的角度论述主动驾驶网络架构设计的办法。

主动驾驶网络要害在架构翻新，翻新不是漫无边际，毫无逻辑和实现可能性的瞎想，没有束缚和方法论的瞎想是民科干的事件。咱们要通过松软的架构设计办法，铺就一个通往愿景的路。

上面讲的方法论既是一种常识，也是一种技能。通过常识学习能够更好的了解架构设计技巧。然而作为技能，却须要一直磨难能力把握。就像学游泳一样，没有常识你很难游好，然而你有了再多常识，进入水中一样不会游。

01 从哲学源头开始思考

在讲架构设计之前，先学习点逻辑常识。先用一个例子帮忙大家了解一下什么是概念的外延以及语境的常识。咱们有时探讨问题常常整拧巴了，大家探讨不到一块去，很多时候是因为概念了解的不一样。讲个小故事，有一次我讲课时，说治理老外和治理中国人差不多，后果很多人拥护，感觉我不理解老外，而后讲了很多老外不同的中央，我反诘了一句，那中国人是不是治理形式就一样呢？当你从人的个别特点看老外的时候，其实大家都一样，都有七情六欲，都须要愿景，都须要尊重，都须要领导，都须要鞭策，这和中国人有啥不一样？人面对事件须要寻找共性能力高效解决。如果要寻找共性，那就麻烦了，这世界有齐全一样的人吗？昨天的你和明天的你是一样的吗?

我说老外一样的时候显然是在讲个别准则，而对具体的事件解决上，不止老外，其实面对每个个体，每个个体的不同时刻，都要辨别解决。而谈话时到底是指“个别准则”还是“非凡准则”，这个隐含的背景信息就是语境，语境个别在对话中并不呈现，而是靠沟通单方依据了解来主动补充。人对语境解决的能力十分强，然而对话有时语境了解会产生谬误，这个就是平时所说的沟通不在一个频道上了。

软件开发要求逻辑十分清晰，特地是大型软件的架构设计更是如此，须要十分好的抽象思维能力，所以深刻了解逻辑办法很重要。

在了解逻辑办法之前，首先要了解咱们说的主观世界就是由实体、实体属性和关系三种因素确定的。明确这三种因素，事物就惟一确定了。而软件世界其实就是实体世界的映像，所以也是这三种因素。我画了一张简图，先看一下，前面会用到。

对于思维办法有比拟、分类、剖析、形象、概括、综合几种办法，在传统的哲学中，“比拟”办法个别和其余办法并列，其实不是这样的，比拟是最根底的思维过程，是“剖析”“形象”等其余办法的根底。人是通过比拟能力确定事物的边界的，而后依据边界进行划分类别，也就是“分类”。比方一堆杂粮你能够通过剖析看出有黑豆，红豆，绿豆，薏米，莲子，小米，大米等等，这个过程就是你对图像进行了一直比拟，找到图像的边缘，和记忆中图像比拟确定杂粮品种。只是对图像的比拟剖析都是用神经网络一瞬间实现的，人没有心理意识，而对形象事物的剖析过程是能够知觉的，你回忆一下，剖析事物过程是不也这样，就是不停的比拟各个状况。

所以剖析就是通过不停的比拟，依据比拟后果对事物进行划分，合成出各种实体，实体属性和实体间关系。

哲学上“形象”的办法了解也简略，实体不是有很多属性吗，比方人有人格特色，社会关系，生物等很多属性，生物属性上面还有状态和 DNA 等属性。形象就是依据须要抉择属性的过程，这种“须要”的了解有时就是单方的默契，如果预计沟通的时候没有默契就要明确形象到什么水平。例如刚开始我讲了老外都是一样的，我就是选了老外的人格特色属性，而疏忽了社会关系属性。我哪天说其实人和狗也一样，就是选了两种的生物属性的共性。要是哪天我说其实石头和人也是一样的，只有形象到质子和中子一级就行了。我要说明天的我的昨天的我不一样也行，因为想法和年龄都变了嘛。

还是用一堆杂粮举例，通过剖析这个筛子把黑豆，红豆，绿豆，薏米，莲子，小米，大米这些米豆都离开了。形象的动作就像你认为小米和大米都不算细粮，只留了薏米，莲子、各种豆子。然而也有另外的形象办法，就是我只选能够解毒的细粮，那就只形象出绿豆了，其余就都是主要的了。所以形象什么不是相对的，而是依据须要进行的。

形象往往和实质一词有关联，顺便说一下什么是事物本质属性。形象个别是依据须要把没用的属性去掉，只留要害的属性是，例如简笔画为了辨别梨和苹果，个别形象到形态就能分进去了，这种形象就够用了，然而如果哪天要画苹果梨（真有这种水果的），形态的形象就不行了，所以显然形态不是苹果和梨的本质区别。那是什么是这两者的本质区别呢，口味显然也不行，咱们当初能够改良品种搞成口味差不多。梨和苹果最实质的区别是他们的 DNA 不同。所以事物本质属性就是能形象到用于对事物进行分类的起码特色属性。

总结一下，形象就是依据须要抉择属性和关系的思维过程。至于怎么抉择属性和关系、须要到什么水平，次要看理论场景了，这个才是难点。就像画画一样，颜料，笔，纸都一样，理工科的你画的和徐悲鸿画的那价值可是差远了。你画的能被大家看到观赏一下曾经很不错了，徐悲鸿一张画就够个别人奋斗一辈子，这就是差异，是吧！

如果形象的对象是像苹果一样的实物，你能够辨认出画的苹果的，画的最形象的状况下就是一个简笔画。如果把形象后果和语言符号连接起来，就成了概念“苹果”这个词了。而如果形象的对象是像文章这种自身也是形象的和简单的，那么这个过程咱们能够称作概括办法。换一句话说，“概括”就是一种非凡的形象。

刚刚讲的办法都是把事物合成开的办法，那么“综合”是反过来的过程，是把各个局部组织起来进行思维的办法。综合不是各个局部的简略相加，而是一种再加工过程，会产生从各个局部别离看无奈生成的新常识来。不晓得大家看油画时有没有留神到，你走进油画细看，就是一些色块，看不出啥货色来，然而走远一点，看到全貌的时候，一副栩栩如生的画就呈现了，这个就是综合。综合思维在底层用到了“比拟”和“顿悟”两个思维办法。

0 2 业务建模办法

2.1 如何做业务形象建模

了解了看起来哲学看起来很 High 的思维办法，咱们开始探讨业务建模办法了，业务建模的实质就是对业务进行形象和重构。先看一下建模过程简图，之后我再关上讲。

2.1.1 业务形象与分类

理论业务建模过程可分为以下几个步骤：

第一个步骤就是堆砌资料，很多人了解业务有点不晓得怎么动手，其实也很简略，就是到处收集资料，有几类：

1. 曾经有的框架，前人的智力成绩必定要参考的。
2. 通用常识，能够帮忙了解背景。
3. 如下图的 7P 类材料，这是援用我以前写的一个业务调研框架。

这些资料拿到后先通读一遍，有个大略印象，等须要时再细读。

第二个步骤就是对业务性能进行形象，确定思考最大的思考框架。比方主动驾驶网络须要哪些大的性能。

第三个步骤是在框架下分类，分类维度能够依照：工夫，空间，人际，业务类型等合成。这个步骤先不必做细，大略分分，便于进一步进行思考。现存的业务性能个别都是相互穿插的，你中有我，我中有你。这种状况有时就是没想分明引起的，有时是环境变动引起的。比方以前能够说西红柿是蔬菜，然而新的圣女果西红柿却变成水果了，严格讲就不能再说西红柿是蔬菜了。当存在这种穿插时就要进一步细分维度，只有足够细分维度，事件最终总是能够找到 MECE（相互独立，齐全穷尽）可分的维度。西红柿分类这个就比较简单了，当前给小朋友介绍时就变成传统西红柿是蔬菜和圣女果西红柿是水果了。这个过程最重要，肯定要把所有穿插去掉。

第四个步骤，再进行形象，把一些不要害的内容去掉。

下面这些过程要迭代好屡次，重复提炼才行，通过这个过程个别就比拟清晰了。

2.1.2 组件建模

形象完之后下一步工作就是按最简洁准则对分类进行聚类，聚类要思考将各类别对立到一个档次上，并对聚类进行命名便于管理。最初再辨认一下各个聚类间关系，造成关系图。

还是用杂粮举例。咱们开始会把分进去的黑豆，红豆，绿豆，薏米，莲子别离打包。然而这样分类比拟多，卖的时候不好介绍。这时感觉黑豆，红豆，绿豆作用差不多，就再对立打成一个豆类的大包，和薏米、莲子包并列，就成了上面状况。黑豆，红豆，绿豆合并的过程就是一种聚类。这样介绍起来就清晰一点。

2.1.3 零碎重构

下面分类打包完了如果要卖，显然要看看是不是和市场匹配了，如果不适合还要调整关系。比方豆子打包后发现绿豆有消毒的非凡性能，能够多卖钱，这个时候就要把绿豆拿进去独自卖。这个就是零碎重构了。

2.2 业务形象的技巧 - 角色扮演办法

当一个非常复杂的业务要做业务梳理时是艰难的，要害是波及的货色太多了，如果真要从各种细节理解起，那工作量是不可接受的，而且最初成果还不肯定好。这个时候就能够应用角色扮演办法，这个也是通用的学习办法，能够高速的把握一个畛域的新常识。具体过程就是在理解事物前，不焦急从理论动手，而是依据教训先自我设计一个框架，再依据假如框架去对照理论事物，如果统一就阐明了解正确，如果不统一就找到起因，这样既能够疾速理解业务，又能够发现现存的问题。这个是了解事物的一个十分快捷的办法。

2.3 业务梳理工具 XMind

梳理业务必定要有一个适合的工具。我常常用 XMind。XMind 能够导出各种丑陋的图，然而这个工具最大的作用是不便的进行属性和关系调整，对简单的事件人一下子可能很难想分明，所以能够把所有想法都列到工具里，而后缓缓进行逻辑调整，这样会保障效率。

0 3 如何进行架构设计

3.1 架构设计过程

在设计架构前首先晓得啥是架构，很多人个别把架构设计等同于软件架构设计，不过我这里把架构范畴略微扩充一点，把 IT，流程，组织这类比较复杂的零碎都纳入架构设计的范畴，因为这三者往往是相互关联的。不过很遗憾的是，只管很多人都谈架构，我却没有找到一个很好的架构定义。套用一句对于大数据的笑话，放在架构上也实用：

Architecture is like **age sex，everybody talks about it，nobody really knows what is it

本文借鉴 TOGAF 架构定义，从新进行了定义：

架构：是简单零碎组织模式的形象形容，包含零碎外部的组成模块，外部模块之间的关系及零碎与环境之间的关系。

架构设计：是为了满足零碎的业务应用需要，在业务价值空间、历史积攒、架构倒退的束缚下，通过业务形象、组件建模、零碎重构形式构建架构，使零碎的稳定性，灵活性，可演进性，老本实现具备最优解的过程。输入包含设计准则，架构和演变准则三个局部。

架构的设计的需要了解，业务建模办法在后面的大节中曾经讲过了。上面再讲讲我对设计束缚和架构师要求的了解。

架构不是凭空进去的，架构要思考能不能实现和实现的代价，我刚刚买了一个智能音箱，发现音箱的音量调节逻辑很乱，我倡议做音箱的兄弟把音量调节和应用场景绑定。这样从应用界面看最简略。但架构要不要这样做呢？架构师这个时候就要思考关键点，因为音箱的音量能够在不同中央调节，如何放弃各软件音量状态统一，就须要底层反对。他就肯定要理解底层的实现能力，如果是以前的 android 版本，实现这个性能可能很艰难，界面好用也得舍弃，而如何新的服务架构可能会反对，就值得试试，有艰难也能够冲破一下，所以架构设计肯定是在充沛了解零碎能力的根底上的一种取舍。

还有架构设计也肯定要思考将来架构的稳定性，比方咱们有的大型软件系统在服务化曾经成为显著趋势的状况下还是采纳了传统架构，干了几年后有不得不从新进行服务化设计。所以软件架构设计就要综合架构不同设计的收益大小，历史的积攒状况，架构的将来倒退几个因素综合思考。

架构设计还是很简单的，有时候就是一种艺术，须要各自均衡。如果想干架构师，那么有几个特点就不能少了。一个是凋谢，不能按部就班，啥事看看老祖宗咋说，没本人的见解必定不行。一个是要有洞察力，晓得去粗存精，不能眉毛胡子一把抓，把架构越搞越简单。业务也要精通，要长于学习，要常识多，常识越多思考越全面。作为架构师不得不既懂业务，又懂软件。不然没法做出很好的设计。

架构设计师是十分要害的角色，往往决定了软件应用生死，承当如此之重的责任，大家会有疑难，那这么牛的人不是很难找？其实齐全不必放心，架构设计说到底还是工程型问题，不像相对论除了蠢才谁也搞不了。这世界搞工程型问题的人才济济，不可能找不到的，只是看怎么找，给多少钱的问题。当然还有另外的放心，那老本会不会很高，其实也不必放心，架构师人数要求也很少，绝对零碎的老本并不高，所以苹果才会全力以赴找最优良的人才。

3.2 业界的架构设计办法

下面讲了最个别的架构设计的框架，上面这个 ADM（Architecture Development Method）是 TOGAF（The Open Group Architecture Framework）的企业架构设计办法，是 The Open Group 在美国国防部信息管理技术架构的根底上公布的，十分欠缺和具体，很值得学习。

古代常识搜寻非常容易，如果晓得哪些常识不晓得，一搜寻就查到了，要害是有时基本不晓得本人哪些货色不晓得。所以这里大家只有晓得有这个很好的办法就行了，具体我就不讲了，有趣味的话网上材料很多。

0 4 架构设计利用示例

4.1 软件架构设计

我这里不讲具体的软件架构设计自身，着重讲一下软件架构设计的理念。从很风行的畛域驱动设计办法（DDD:Domain-Driven Design）的理念看，实质上，业务软件设计就是用软件对事实业务的模仿，设计软件的过程就是对业务的了解过程。

DDD 首先是一种设计思维，所谓思维就是答复“设计的实质是什么，次要逻辑是什么”这类大的问题。DDD 强调要从业务视角思考怎么设计软件架构，设计肯定要晓得业务是什么样子的，业务的需要和问题是什么，有什么外在逻辑，而不是从软件技术自身登程设计，这个对设计而言就是大的方向问题。尽管这个方向说进去如同没什么，然而实际上很多软件人员更多是从软件自身开始设计，一遇到业务问题容易绕道走，所以强调从业务登程是这个办法最有价值的中央。

0 5 架构参考设计

主动驾驶网络的参考设计，上面架构能够比照理解一下。

5.1 TOGAF EA 和 Frameworx

Frameworx 是 TMF 的 NOSS 框架，相当于 TOGAF EA 的电信版实例。

5.2 TMF 自治网络架构

上面是 TMF 的自治网络参考架构：

上面全文引自：中国电信《001-CTGMBOSS-OSS-2.5- 概念体系分册(终审稿)》，这个文档比拟老，然而当初问题仍旧没变。

“业界对 OSS 的概念形容的比拟清晰的 TMF SID 对概念的形容。在 SID 的体系中，包含了产品 (Product)、服务(Service)、资源(Resource) 三个次要概念，其中服务又细分成面向客户的服务 CFS(Customer Facing Service)和面向资源的服务 RFS(Resource Facing Servcie)。其中产品能够蕴含多个面向客户的服务、面向客户的服务由多个面向资源的服务组成，面向资源的服务由资源组成。具体关系如图所示。TMF 在 eTOM 中对各个概念的定义原文如下：

Product is what an entity (supplier) offers or provides to another entity (customer). Product may include service, processed material, software or hardware or any combination thereof. A product may be tangible (e.g. goods) or intangible (e.g. concepts) or a combination thereof. However, a product ALWAYS includes a service component.

Services are developed by a Service Provider for sale within Products. The same service may be included in multiple products, packaged differently, with different pricing, etc.

Resources represent physical and non-physical components used to construct Services. They are drawn from the Application, Computing and Network domains, and include, for example, Network Elements, software, IT systems, and technology components.

本篇从哲学的角度论述了架构设计的办法，下篇我将介绍一个我本人了解的网络运行性能的新 ISOAP（我的香皂）模型，欢送大家一起探讨。

点击关注，第一工夫理解华为云陈腐技术~