自动驾驶网络系列二： 从哲学源头开始思考架构设计

本篇我重点讲方法论，自动驾驶网络关键在架构创新，创新不是漫无边际，毫无逻辑和实现可能性的瞎想，没有约束和方法论的瞎想是民科干的事情。我们要通过坚实的架构设计方法，铺就一个通往愿景的路。

下面讲的方法论既是一种知识，也是一种技能。通过知识学习可以更好的理解架构设计技巧。但是作为技能，却需要不断磨练才能掌握。就像学游泳一样，没有知识你很难游好，但是你有了再多知识，进入水中一样不会游。

在讲架构设计之前，先学习点逻辑知识。先用一个例子帮助大家理解一下什么是概念的内涵以及语境的知识。我们有时讨论问题经常整拧巴了，大家讨论不到一块去，很多时候是因为概念理解的不一样。讲个小故事，有一次我讲课时，说管理老外和管理中国人差不多，结果很多人反对，觉得我不了解老外，然后讲了很多老外不同的地方，我反问了一句，那中国人是不是管理方式就一样呢？当你从人的一般特点看老外的时候，其实大家都一样，都有七情六欲，都需要愿景，都需要尊重，都需要指导，都需要鞭策，这和中国人有啥不一样？人面对事情需要寻找共性才能高效处理。如果要寻找个性，那就麻烦了，这世界有完全一样的人吗？昨天的你和今天的你是一样的吗?

我说老外一样的时候显然是在讲一般原则，而对具体的事情处理上，不止老外，其实面对每个个体，每个个体的不同时刻，都要区分处理。而说话时到底是指“一般原则”还是“特殊原则”，这个隐含的背景信息就是语境，语境一般在对话中并不出现，而是靠沟通双方根据理解来自动补充。人对语境处理的能力非常强，但是对话有时语境理解会发生错误，这个就是平时所说的沟通不在一个频道上了。

软件开发要求逻辑非常清晰，特别是大型软件的架构设计更是如此，需要非常好的抽象思维能力，所以深入理解逻辑方法很重要。

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

关于思维方法有比较、分类、分析、抽象、概括、综合几种方法，在传统的哲学中，“比较”方法一般和其他方法并列，其实不是这样的，比较是最基础的思维过程，是“分析”“抽象”等其他方法的基础。人是通过比较才能确定事物的边界的，然后根据边界进行划分类别，也就是“分类”。比如一堆杂粮你可以通过分析看出有黑豆，红豆，绿豆，薏米，莲子，小米，大米等等，这个过程就是你对图像进行了不断比较，找到图像的边缘，和记忆中图像比较确定杂粮种类。只是对图像的比较分析都是用神经网络一瞬间完成的，人没有心理意识，而对抽象事物的分析过程是可以知觉的，你回想一下，分析事物过程是不也这样，就是不停的比较各个情况。

所以分析就是通过不停的比较，根据比较结果对事物进行划分，分解出各种实体，实体属性和实体间关系。

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

还是用一堆杂粮举例，通过分析这个筛子把黑豆，红豆，绿豆，薏米，莲子，小米，大米这些米豆都分开了。抽象的动作就像你认为小米和大米都不算粗粮，只留了薏米，莲子、各种豆子。但是也有另外的抽象方法，就是我只选可以解毒的粗粮，那就只抽象出绿豆了，其他就都是次要的了。所以抽象什么不是绝对的，而是根据需要进行的。

抽象往往和本质一词有关联，顺便说一下什么是事物本质属性。抽象一般是根据需要把没用的属性去掉，只留关键的属性是，例如简笔画为了区分梨和苹果，一般抽象到形状就能分出来了，这种抽象就够用了，但是如果哪天要画苹果梨（真有这种水果的），形状的抽象就不行了，所以显然形状不是苹果和梨的本质区别。那是什么是这两者的本质区别呢，口味显然也不行，我们现在可以改良品种搞成口味差不多。梨和苹果最本质的区别是他们的DNA不同。所以事物本质属性就是能抽象到用于对事物进行分类的最少特征属性。

总结一下，抽象就是根据需要选择属性和关系的思维过程。至于怎么选择属性和关系、需要到什么程度，主要看实际场景了，这个才是难点。就像画画一样，颜料，笔，纸都一样，理工科的你画的和徐悲鸿画的那价值可是差远了。你画的能被大家看到欣赏一下已经很不错了，徐悲鸿一张画就够一般人奋斗一辈子，这就是差别，是吧！

如果抽象的对象是像苹果一样的实物，你可以识别出画的苹果的，画的最抽象的情况下就是一个简笔画。如果把抽象结果和语言符号连接起来，就成了概念“苹果”这个词了。而如果抽象的对象是像文章这种本身也是抽象的和复杂的，那么这个过程我们可以称作概括方法。换一句话说，“概括”就是一种特殊的抽象。

刚刚讲的方法都是把事物分解开的方法，那么“综合”是反过来的过程，是把各个部分组织起来进行思维的方法。综合不是各个部分的简单相加，而是一种再加工过程，会产生从各个部分分别看无法生成的新知识来。不知道大家看油画时有没有注意到，你走进油画细看，就是一些色块，看不出啥东西来，但是走远一点，看到全貌的时候，一副栩栩如生的画就出现了，这个就是综合。综合思维在底层用到了“比较”和“顿悟”两个思维方法。

2.1       如何做业务抽象建模

理解了看起来哲学看起来很High的思维方法，我们开始讨论业务建模方法了，业务建模的本质就是对业务进行抽象和重构。先看一下建模过程简图，之后我再打开讲。

2.1.1         业务抽象与分类

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

第一个步骤就是堆砌材料，很多人理解业务有点不知道怎么入手，其实也很简单，就是到处收集材料，有几类：

1. 已经有的框架，前人的智力成果肯定要参考的。

2. 通用知识，可以帮助理解背景。

3. 如下图的7P类资料，这是引用我以前写的一个业务调研框架。

这些材料拿到后先通读一遍，有个大概印象，等需要时再细读。

第二个步骤就是对业务功能进行抽象，确定思考最大的思考框架。比如自动驾驶网络需要哪些大的功能。

第三个步骤是在框架下分类，分类维度可以按照：时间，空间，人际，业务类型等分解。这个步骤先不用做细，大概分分，便于进一步进行思考。现存的业务功能一般都是互相交叉的，你中有我，我中有你。这种情况有时就是没想清楚引起的，有时是环境变化引起的。比如以前可以说西红柿是蔬菜，但是新的圣女果西红柿却变成水果了，严格讲就不能再说西红柿是蔬菜了。当存在这种交叉时就要进一步细分维度，只要足够细分维度，事情最终总是可以找到MECE（互相独立，完全穷尽）可分的维度。西红柿分类这个就比较简单了，以后给小朋友介绍时就变成传统西红柿是蔬菜和圣女果西红柿是水果了。这个过程最重要，一定要把所有交叉去掉。

第四个步骤，再进行抽象，把一些不关键的内容去掉。

上面这些过程要迭代好多次，反复提炼才行，经过这个过程一般就比较清晰了。

2.1.2         组件建模

抽象完之后下一步工作就是按最简洁原则对分类进行聚类，聚类要考虑将各类别统一到一个层次上，并对聚类进行命名便于管理。最后再识别一下各个聚类间关系，形成关系图。

还是用杂粮举例。我们开始会把分出来的黑豆，红豆，绿豆，薏米，莲子分别打包。但是这样分类比较多，卖的时候不好介绍。这时觉得黑豆，红豆，绿豆作用差不多，就再统一打成一个豆类的大包，和薏米、莲子包并列，就成了下面情况。黑豆，红豆，绿豆合并的过程就是一种聚类。这样介绍起来就清晰一点。

2.1.3         系统重构

上面分类打包完了如果要卖，显然要看看是不是和市场匹配了，如果不合适还要调整关系。比如豆子打包后发现绿豆有消毒的特殊功能，可以多卖钱，这个时候就要把绿豆拿出来单独卖。这个就是系统重构了。

2.2       业务抽象的技巧-角色扮演方法

当一个非常复杂的业务要做业务梳理时是困难的，关键是涉及的东西太多了，如果真要从各种细节了解起，那工作量是不可承受的，而且最后效果还不一定好。这个时候就可以使用角色扮演方法，这个也是通用的学习方法，可以高速的掌握一个领域的新知识。具体过程就是在了解事物前，不着急从实际入手，而是根据经验先自我设计一个框架，再根据假设框架去对照实际事物，如果一致就说明理解正确，如果不一致就找到原因，这样既可以快速了解业务，又可以发现现存的问题。这个是理解事物的一个非常快捷的方法。

2.3       业务梳理工具XMind

梳理业务肯定要有一个合适的工具。我经常用XMind。XMind可以导出各种漂亮的图，但是这个工具最大的作用是方便的进行属性和关系调整，对复杂的事情人一下子可能很难想清楚，所以可以把所有想法都列到工具里，然后慢慢进行逻辑调整，这样会保证效率。

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在美国国防部信息管理技术架构的基础上发布的，非常完善和详细，很值得学习。

现代知识搜索非常容易，如果知道哪些知识不知道，一搜索就查到了，关键是有时根本不知道自己哪些东西不知道。所以这里大家只要知道有这个很好的方法就行了，具体我就不讲了，有兴趣的话网上资料很多。

4.1       软件架构设计

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

DDD首先是一种设计思想，所谓思想就是回答“设计的本质是什么，主要逻辑是什么”这类大的问题。DDD强调要从业务视角思考怎么设计软件架构，设计一定要知道业务是什么样子的，业务的需求和问题是什么，有什么内在逻辑，而不是从软件技术本身出发设计，这个对设计而言就是大的方向问题。虽然这个方向说出来好像没什么，但是实践上很多软件人员更多是从软件本身开始设计，一遇到业务问题容易绕道走，所以强调从业务出发是这个方法最有价值的地方。

自动驾驶网络的参考设计，下面架构可以对比了解一下。

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（我的香皂）模型，欢迎大家一起探讨。