分布式系统架构设计 – 第0式 - 设计总决

|

动机

在“不易、简易、变易”这三个范畴里，技术是属于“变易”范畴的，其千变万化；“方法论”是属于“简易”范畴的，其具有领域普适性的指导能力；而架构设计总决属于“不易”的范畴，其具有第一性原理的本质指导能力。本文的目的之一即是挖掘出分布式系统架构设计的第一性原理，使其可以应用于千变万化的不同的技术领域。

架构是由人设计出来的，其与设计的人的架构理念强相关，欲彻底了解一个产品的架构必须要能量化它的设计理念，从而才能更好的由现象到本质了解一个技术，因此本文的目的之二即是量化人的架构设计理念。

分布式系统

软件设计的第一性原理是“定义问题，分析问题，过滤问题以及解决问题。”，其最重要的第一步是“定义问题”，问题定义的准确与否直接决定了后面的分析问题，过滤问题以及解决问题的方向与准确性。那么，什么是分布式系统？各种论文以及书籍都有过自己的定义，比如《分布式系统原理与范型》定义分布式系统为：

1
分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。

还有Google出来的定义：

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

这是分布式系统理论的第一性原理，不同于这些从理论角度的定义，这里，我从工程实现的角度给分布式系统一个新的定义，即：

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

从工程的角度来看，这个定义是分布式系统实践的第一性原理，分布式系统都是围绕着集群状态表来进行编程的，集群状态表是分布式系统的核心功能中的核心。因此本系列分布式系统文章都是依据理论结合实践的原则，从工程交付的角度来看待分布式系统的。

设计哲学

什么是分布式系统的设计哲学？首先这里的设计哲学不是产品的设计哲学，它是一种工程哲学，是分布式系统架构设计原则以及设计方法论的指导思想，是架构师的内功。其目的是为了指导架构设计的过程，克服架构设计难题从而达到最终的架构设计目标。不同的架构师有自己不同的设计哲学观，这里我提出分布式系统架构设计哲学9式，即：

1
抽象 分层  解耦 拆分 聚合 治理 模型 取舍 质量、边界 演化

这9个词每个词展开来讲都可以是一篇大论，不同的架构设计师有自己不同的设计哲学观，也就形成了不同的架构设计原则以及设计方法论，并不存在一个普适的、统一的架构设计哲学，适合自己的才是最好的，每个人的领悟不同，因此这里也就不展开来讲。

设计原则

同设计哲学一样，不同的架构设计师有着自己不同的设计原则观，在这里，我认为最合适的分布式系统的架构设计原则有二，即：

  • 最佳物种原则
  • 功能非功能原则

最佳物种原则

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

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

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

功能非功能原则

功能非功能原则，讲的是技术原则，架构的目的是提供该领域的功能，然而功夫却是体现在非功能。比如常见的几个深度学习框架在功能上都具有深度学习训练与推理的能力，但是让用户决定是否选择这个框架的主要决定性因素却体现在其非功能，比如性能、可用性、可靠性、易用性、服务支持以及版权等。

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

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

用户的产品质量需求一般称为使用质量需求，其一般包括：合适的性能（Performant）、可用性(Availability)、可靠性(Reliability)、可伸缩性(Scalability)、韧性(resilience)、可观测性(Observability)、可服务性（Serviceability）、安全性（security）、易用性（usability）、可运维性（operability）等，而用户的约束需求包括 用户的业务环境、用户的能力以及用户群的特征等。

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

设计方法论

同设计哲学与设计原则一样，不同的架构设计师有着自己不同的设计方法论，在这里，我认为分布式系统的架构设计方法论可以总结成以下口诀，即分布式9法10功能口诀，如下：

分布式9法：

1
2
3
4
5
6
7
8
9
少读少写少依赖
业务拆业务合
功能拆性能聚
时空换同异换
硬件顺天性
服务需治理
数据保一致
哪都不可靠
事事慎权衡

分布式10项:

1
2
提供 注册 配置 调用 路由
观测 治理 编排 质量 边界

在分布式系统里几乎所有的功能与设计思路都可以用这个“9法10项”口诀来解读，例如：

1，“业务拆业务合”，其理论依据来源于“康威定律”，即：

1
2
> 设计系统的组织其产生的设计等价于组织间的沟通结构。
>

软件架构的拆合关系来源于团队的组织结构。

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

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

小结

本文讲述了分布式系统架构设计总决，其可分为设计哲学、设计原则以及设计方法论，从而可以依据这三个方面量化人的设计理念。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，DELL EMC 资深首席工程师，曾就职于Marvell、AMD，主要从事Linux内核以及分布式产品的交付、架构设计以及开发工作。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。