火箭架构思维模型六元组 - 势 道 法 术 器 界

动机

万事万物逃脱不出“不易、简易、变易”这三个层次，演绎法认为“道生一、一生二、二生三、三生万物”，而归纳法也可以认为“万物合三，三合二、二合一、一合道”。本文的目的之一是通过归纳法找出分布式系统架构设计最为本质的“道”，使之可以用于解读各式各样的分布式系统架构设计。

从应用领域来看分布式系统可以分为三大类：分布式计算、分布式存储以及分布式调度，本文做的是从这三大领域的”变易”中找出“不易、简易”，“以”不变“应”万变“，从而抽象出一种分布式架构思维使之可以应用于这三大领域的架构设计。

架构思维模型

在面向对象编程有四个最高的思想，即“抽象、封装、继承与多态”，将这个思想迁移应用到本文，可以解读为架构思维是第 8 式“火箭技术思维模型”的以及第 0 式”设计总决“的继承，这里我把它定义为“分布式系统火箭架构思维模型”，如下图：

火箭架构思维模型

这个架构思维模型用图形是一个内部分层的三角形，类比为一个 5 级火箭体，它包括“势 道 法 术 器 界”这六个要素，其下一级为上一级的提供动力的同时又受三条边的约束。

狭义上的分布式系统架构通常指的是架构的技能，其属于“术”的范畴，而广义的分布式系统架构则是市场趋势、架构理念、架构方法论、架构技能、架构用的工具以及架构的边界这几个方面的组合体，应用抽象思维，即“势、道、法、术、器、界”这六个字 ，简称架构思维六元组。

势：时势，是架构的方向

“势”是架构的方向。从宏观处着眼，“势”是产品架构设计的市场趋势、是客户需求趋势也是技术的应用趋势；从微观处着手，“势”是功能设计的价值与目的。架构设计需要从宏观处着眼微观处着手，看清客户的需求趋势、市场趋势以及技术趋势，功能设计需要分析清楚当前功能的价值与目的。除了明白架构的是什麽的问题，还需要明白为什麽需要做这个架构设计，这就需要从“势”处定义问题、分析问题、过滤问题以及解决问题。

团队一起讨论架构选型与功能设计的问题，经常会遇到 A 说 A 有理，B 说 B 有理，最终方案无法达成一致致使项目拖延甚至失败的情形。这就需要梳理清楚架构的目的、原则、质量与边界，对方案进行方向上的约束，那么“势”就是架构选型与功能设计的约束条件之一，其用于定义架构的目的。

道：理念，是架构的认知

“道”是架构的认知，是架构师的设计理念、设计意图，是产品架构的灵魂。美国学者布卢姆认为认知有六层次：识记、理解、应用、分析、评价、创造。产品架构是由人设计的，那么不可避免的就会带有人的因素在里头，”见其所欲“，你所看到的架构都是架构师欲让你看到的，对分布式系统认知层次不同的人，理念也是不同的，欲深入理解一个产品的架构必须要能找到设计它的人的设计”理念“。

进行分布式系统的架构设计，首先我们要知道分布式系统的第一性原理是什么？即分布式系统的类似公理性质的定义，Google 出来的对分布式系统的定义有：

A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another. The components interact with one another in order to achieve a common goal.

即：

分布式系统是一个组件分布在不同的联网的计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，这些组件相互交互以实现一个共同的目标。

这句话就是分布式系统的第一性原理，是分布式系统的类公理性质的理论定义，其非常重要，默认不变的公理性定义，解读开来就是：“分布式系统是由建立在网络上的通过消息进行通信和协调的系统，各个机器相互交互一起完成一个共同的目标。”，从这句话里可以推理出分布式系统的几个类似定理性质的特征定义：

• 分布式系统是基于网络的，网络所具有的毛病它都有，网络会丢包、网络有带宽限制、网络有安全隐患、网络有负载均衡问题等，那么这些问题在分布式系统里需要怎么解决？那么如何提高服务的可靠性？如何保证服务的可用性？

• 分布式系统是基于消息传递的，那么如何保证消息的幂等性？如何保证消息的正确性？如何保证消息传递的性能？如何保证消息传递的可靠性？

• 分布式系统是协调工作的，那么如何协调大量的计算机节点的完成一个共同的目标，如何解决协调的复杂性以及提高协调的可靠性？

• 分布式系统是一起相互交互完成一个共同的目标的，那么如何一起交互？如何拆分目标？如何聚合目标，如何提高完成目标的性能？

• 分布式系统是分布式的，其具有分布性的特点，那么如何保证分布式所要求的负载均衡、可伸缩性、韧性等功能与质量需求？

依据分布式系统的第一性原理，本文解读了分布式系统的理论认知，除此之外还可以依据个人对分布式系统的工程经验推理出分布式系统的实践认知，依据工程实践经验，这里我定于分布式系统为：

分布式系统是面向集群状态的编程, 它是抽象、分层、解耦、拆分、聚合、治理、取舍、模型、质量、边界、演化思维的创造性应用，其要交付的是功能价值，但功夫却体现在非功能。

不同于教科书以及一些论文对分布式系统的理论定义，这个定义来源于个人工程经验，是认知的创造。分布式系统的功能、质量与约束都来自于这两个理论定义与工程定义。

法：方法论，是架构的套路

”法“是方法论，是架构设计的方法论，是架构设计的套路，它是认知论的上一级，方法论体现在产品的设计原则、设计心法以及设计功能。从工程经验的角度，本文认为分布式系统设计可以依从以下的”9 法 10 项 2 原则“ 作为方法论。

9 法

少读少写少依赖，业务拆业务合，功能拆性能聚，时空换同异换

硬件顺天性，服务需治理，数据保一致，哪都不可靠，事事慎权衡

• 少读少写少依赖: 少读，即减少读放大，减少需要读的数据量；少写，即减少写放大，减少需要写的数据量；少读少写的策略可以是提高 cache 命中率也可以是进行数据压缩，还可以是合适的读写算法与数据结构等，少依赖，即解耦，拆分，高内聚低耦合

• 业务拆业务合：分布式系统里要有拆有合，拆的目的是为了解耦、是为了集群业务可伸缩，是为了组件上的小可以支持集群规模上的大；合的目的是为了内聚，聚合拆分的服务返回的子结果，从而返回大结果；“业务拆业务合”，其理论依据来源于“康威定律”，即： 设计系统的组织其产生的设计等价于组织间的沟通结构，软件架构的拆合关系来源与团队的组织结构。

• 功能拆性能聚：在分布式系统里有拆有合，那么拆与合的取舍依据在哪里？这句话讲的就是拆与合的取舍关系：依据功能进行拆分，但是也要依据性能进行聚合，拆开后会影响性能的地方最好不拆

• 时空换同异换： 时空换同异换讲的是性能优化的路数，解读开来说即是：时间换空间、空间换时间、同步换异步、异步换同步。例如：采用 cache 的功能可以减少计算的时间，这是存储空间换时间从而提升性能；采用批处理的方式提升性能，这是减少计算时间；采用异步换同步的方式提升性能也是减少计算时间；减少 IO 的数据量从而提升性能，这是存储空间换时间；减少 IO 路径提升性能，这也是网络空间换时间；采用最新的硬件提升性能，这可以是计算换时间，也可以是存储或网络空间换时间

• 硬件顺天性：硬件顺天性讲的是软件设计要遵循硬件的原生特性，CPU 的分核调度、机械盘性能不如固态硬盘、磁盘分块需要对齐、磁盘是有可能会电子位飘逸丢数据的、内存性能好适合做缓存但是下电就丢数据、网络是不可靠的并且有带宽限制、RDMA 网络比 IP 网络性能好，机器学习采用 GPU 比 CPU 更能获得高计算性能；不同的应用场景要依据硬件的不同特性做架构选型以及架构设计等。

• 服务需治理：指的是分布式系统是由各种不同的组件进行组合连接而成，其需要服务治理设计，服务需治理背后的原因来源于分布式系统式搭建在网络上的，其继承了网络的毛病，背后的指导思想是“墨菲定律”，即“会出错的事总会出错”，服务治理的具体解决方案可分为容错、降级、限流、熔断、隔板这五个模式

• 数据保一致：要保证分布式系统对外提供的服务的数据的一致性，cache 掉电会丢数据、网络不可靠会丢数据、磁盘电子不可靠会丢数据，计算丢请求会丢数据，各种场景下都需要保证数据的一致性，比如缓存的 MESI 算法保数据、掉电刷内存保数据、网络端到端的校验、磁盘扫描校验、数据副本保数据等

• 哪都不可靠：指的是磁盘不可靠、网络不可靠、计算不可靠、运维的人不可靠，何种场景都需要进行系统的韧性设计

• 事事慎权衡：指的是架构设计本身的设计方法论，即 trade-off

10 项

提供 注册 配置 调用 路由

观测 治理 编排 质量 边界

• 提供：即服务接入的提供，指的是对外提供 restful 接口服务：权限、多组合、监控、审计、计费等，对外提供 SQL 服务接入接口服务、对外提供自然语言接入接口服务等

• 注册：即服务注册，将集群的工作负载注册到集群注册中心

• 配置：即配置管理，将集群的配置管理在配置中心；

• 调用，即服务调用，各种 RPC 调用，系统内的消息传递

• 路由：即服务路由，目的是集群的负载均衡与扩伸缩性

• 观测：指的是集群内部指标的可观测性，即监控、告警、追踪、日志

• 治理：指的是集群内部的服务治理：熔断、降级、限流、隔离、容错

• 编排：即服务编排，基于 k8s+ docker，完成安装、升级、扩容、运维、调度等；

• 质量：指的是安装部署运维质量、客户质量、用户质量与开发质量

• 边界：指的是系统内的约束条件，涵盖 硬件资源、客户约束、用户约束以及团队约束

2 原则：

• 最佳物种原则

• 功能非功能原则

最佳物种原则

最佳物种原则其来源是生物的物种进化理论，讲的是产品原则，其可以一分为二：

1，最佳原则，做产品架构设计的时候要挖掘不同的业务特性以及其业务本质，从而设计出与业务最为匹配的架构。天上飞的是鸟儿，地上奔跑的是走兽，水里游的是鱼儿。架构设计由大及小，由外及内也是如此。比如计算用的是分布式计算、存储用的是分布式存储，调度用的是分布式调度，其负责的领域各不相同，不存在一个全能的分布式中间件可以最佳的完成计算、存储、调度三合一的功能。从小处来讲也是如此，比如分布式系统内部的注册、路由、成员管理、服务提供、复制、安全、算法模型、存储等各有其自己最佳的设计方案，再依据这些最佳组件、最佳方案组合出一个最佳分布式中间件。

2，进化原则，万物由微而显，由简而繁，物竞天择，优胜劣汰，好的架构是根据业务演化而来，而不是一开始就完美的设计好的。但是不管是微还是显，其最本质的功能还是不变的，一个产品从 POC 到 MVP 再到企业级达标其最核心的功能是不变的，比如计算、存储与调度。

功能非功能原则

功能非功能原则，讲的是技术原则，从大体上来说，分布式系统的架构设计都是围绕其功能与非功能的量化设计来进行的，非功能又可以一分为二，即：质量与约束，比如：

客户对产品质量的需求一般可以用四个字概括，即”多、快、好、省“，然而客户在产品交付的时间、质量与成本上的取舍，客户原来遗留的系统，当前国家的法律法规，市场上的技术趋势以及竞争对手与行业标准等都属于当前客户需要考虑的约束条件。

用户的产品质量需求一般称为使用质量需求，其一般包括：性能、可用性、可靠性、可伸缩性、韧性、可观测性、可服务性、安全性、易用性、可运维性等，而用户的约束需求包括 用户的业务环境、用户的能力以及用户群的特征等。

团队的质量需求指的是产品开发周期内的质量需求，高质量的代码几个最重要的要素有：可测试性、可维护性、可扩展性、可读性等，而团队的约束需求有：资源预算、上级要求、开发团队的能力、产品规划、此外还有信息安全以及产品运行环境 的约束等。

术：技能，是架构技能

术，技能，是架构技能，其可以分为需求分析、设计哲学定义、设计方法论定义、设计原则定义、架构制图、基础理论理解与应用、基础数据结构理解与应用、基础算法设计、基础组件设计、质量达标设计以及边界约束设计。即：

• 分布式系统的需求分析：这里可以依据需求分析公式：需求 = [客户，用户，团队] x [功能，质量，约束]，进行全面的架构需求分析。

• 分布式系统的设计思想：抽象、 分层、 解耦、 拆分 、聚合、治理、取舍、模型、质量、边界、演化

• 分布式系统的设计原则：最佳物种原则，功能非功能原则

• 分布式系统的架构视图：我们在学习画法几何或机械制图的时候，要描述一个物体可以采用视图法来表示，比如机械制图里要制造一个零件的时候，需要依据这个零件画出可以根据这个图形加工的视图，其通常采用正视图、俯视图、侧视图，加上额外的细节视图与质量指标、材料约束的方法。同样我们做软件架构设计的时候，也需要将具体的”软件体“抽象成视图来表示，同时也需要标记上质量与边界约束。

• 分布式系统的基础理论：CAP/PACELC、BASE、ACID、2PC、3PC、PAXOS、RAFT

• 分布式系统的基础数据结构：Array、List、Map、Hash、Tree，及其变种

• 分布式系统的基础算法：负载均衡算法（一致性 hash 算法、分区分配算法）、选主算法、心跳算法、集群视图变更算法、幂等算法、复制算法、缓存 MESI 算法

• 分布式系统的基础组件：服务提供(Restful 接口,SQL 接口,自然语言接口)、服务注册(zookeeper,etcd,consul,etc)、服务配置(zookeeper,etcd, consul,etc)、服务调用(brpc,netty,etc)、服务路由(一致性 Hash 算法、分区分配算法)、服务追踪（zipkin,pinpoint,skywalking,cat,etc）、服务监控(Metrics)、服务治理(容错、降级、限流、熔断、隔板)、服务编排（k8s、docker）、服务安全(keycloak,etc)

• 分布式系统的质量指标：性能指标：TPS、QPS、IOPS、Latency、ResponseTime、缓存抖动指标、缓存命中指标，可靠性指标: 6 个 9 企业级代表，可用性指标：6 个 9 企业级达标，数据一致性指标，可伸缩性，韧性，可观测性，可服务性，安全性，易用性，可运维性，可测试性，可维护性，可扩展性，可读性等，质量指标要能可度量化，可执行化

• 分布式系统的约束边界：其可以是资源容量约束：CPU、磁盘、网络、线程、文件描述符个数，也可以是客户的约束、用户的约束以及团队的约束

器：工具，架构设计用的工具

”器“是工具，是架构设计用的工具，”工欲善其事必先利其器“，常用的架构设计制图工具有 MS Visio、Draw.io，UML 制图用的 Enterprise Architect、starUML 等，当然组织提供的资源支持也可以算是工具之一。

界：是边界，是架构的约束

”界“是边界，是架构的约束限制，火箭架构思维模型里的三角形的三条边代表着“界” ，是技术边界、也是技术约束与技术限制，也是架构的取舍因素之一，是架构能做什麽不能做什麽的解读，对市场来说它是技术壁垒，对产品来说它是法律法规、是功能约束，对团队来说它是资源约束、是自我能力约束。

小结

本文讲述了分布式系统的架构思维模型，其目的希望以此架构思维模型应用于各种领域的分布式架构系统设计。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中国科学技术大学硕士研究生，深度学习首席软件主管工程师，前 EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、分布式中间件以及 Linux 内核。