动机

依据李善友老师的定义“第一性原理思维 = 逻辑奇点 + 公理化方法”，逻辑奇点即基石假设。根据这个第一性原理思维 ，本文解读了tensorFlow 2.0的架构设计，其涵盖了tensorFlow2.0的第一性原理、设计原则以及架构视图，本文的动机是展示第一性原理的架构设计思想在分布式系统架构设计中的应用。

TensorFlow 的第一性原理

欲从本质上理解Tensorflow，那么就需要找出tensorflow的第一性原理定义，再依据演绎法，从这个公理性质的定义演化出tensorFlow的设计理念、设计原则以及功能实现。这里首先把tensorFlow概念化，找出它的公理化定义以及基石假设，即TensorFlow是什么的定义。

通过tensorFlow官网以及Google，得到的6条关于tensorFlow的定义：

1.A machine-learning library based on dataflow programming.

2.TensorFlow is a free and open-source software library for dataflow and differentiable programming across a range of tasks.

3.TensorFlow is an end-to-end open source platform for machine learning.

4.TensorFlow computations are expressed as stateful dataflow graphs.

5.TensorFlow is an end-to-end open source platform for machine learning. It has a comprehensive, flexible ecosystem of tools, libraries and community resources that lets researchers push the state-of-the-art in ML and developers easily build and deploy ML powered applications.

6.TensorFlow Enterprise incorporates: Enterprise-grade support, cloud scale performance，managed services

从这6个定义中，可以概括出tensoFlow的公理化定义：

TensorFlow is an scalable end-to-end machine-learning platform based on stateful dataflow graphs programming,it has a comprehensive, flexible ecosystem.

即

tensorFlow是一个可伸缩的端到端的面向有状态的数据流图编程的机器学习平台,其具有一个全面而灵活的生态系统。

以及两个基石假设，即逻辑奇点：

• 可伸缩(scalable)：可伸缩性是分布式的目的，分布式能力是TensorFlow的构建与运维能力，分布式能力是tensorFlow的隐性基石假设；
• 机器学习(machine learning)：机器学习是Tensorflow的领域功能，是tensorFlow的显性基石假设。

从这个公理化的定义以及两个基石假设里可以推导出设计tensorFlow的作者们的对tensorFlow的几条类似定理性质的设计理念：

• 机器学习(machine learning): 指的是功能领域定位，依据这个设计定位，因此tensorFlow提供的是机器学习相关的功能，其涵盖数据、模型、策略、训练、推理等核心功能。

• 分布式：分布式能力是tensorFlow的构建与运维能力，从抽象的技术实现视角来看tensorFlow就是分布式框架+机器学习的lib库；

• 端到端(end-to-end): 端到端指的是“全程都包”的一种设计理念，用户输入原始数据，经过tensorFlow处理即可以直接得到可用的结果，这个结果可以直接服务于用户，用户无需关注tensorflow的中间过程如何。在tensorFlow里端到端的设计理念体现在 “准备数据 、定义模型、 训练模型、 评估模型、 保存模型以及使用模型”这几个过程，用户只要输入数据即可以得到可用的结果模型。

• 平台(platfrom)：平台化，通常的软件平台指的是能够让用户自己在上面进行业务开发的软件系统，它将业务与技术解耦，用户可以基于这个平台开发自己的业务。其具有可用户自我定义的灵活性、用户可二次开发的开放性、以及接口标准化的特性。在tensorFlow里的平台化的设计理念体现在用户可以自由的定义自己的业务模型而无需关注里头的技术实现即可以得到想要的输出结果。

• 有状态（stateful）：状态是指事物处于产生、发展、消亡时期或各转化临界点时的形态，有状态是指

  “该服务的实例可以将一部分上下文的数据随时进行备份，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。”。

  有状态服务在功能上可以保证数据的恰好一次，可以保证数据服务的强正确性，但是有状态服务需要维护大量的信息和状态，因此又引入了数据存储的复杂性，并且多了数据存储加载的过程，在性能方面要弱于无状态服务。而无状态服务不能保证数据的恰好一次处理，但是易于处理实例规模的伸缩性。tensorflow是有状态的设计理念，表明了tensorFlow可以保证数据处理的恰好一次的强正确性，但是又引入了数据存储与IO性能上的复杂性，需要平衡有状态服务下的正确性与复杂性就需要针对数据存储进行专门的设计。

• 数据流图（dataFlow graphs）: 数据流图指的是用节点和有向边描述数学运算的有向无环图，其要素有数据源或宿、数据流、数据处理节点以及数据存储，其中节点代表数学运算等，而有向边代表节点之间的输入与输出关系、数据在边上流动。依据这个设计理念，TensorFlow依据下图的工作过程计算数据：

  

  在这个数据流图里，tensorFlow里需要事先准备数据，接着定义运算操作，然后计算单元被同步或者异步地分配到不同的计算设备上比如CPU、GPU、TPU进行计算，其在边上流动的数据叫tensors。

• 编程（programming）：可编程性，“编程就是指导计算机执行任务的行为”，编程是个动词，是为了让计算机干你想要干的事情。在面向对象编程里，程序=算法+数据结构+方法，依据这个设计理念，即用户可以依据一定的数据结构通过输入算法以及相应的工程方法，就可以指导tensorFlow执行用户想干的事情，其可以二次开发，具有灵活性以及开放性的特征。

• 生态系统（ecosystem）：生态化，指的是tensorFlow的产品商业模式理念，围绕tensorFlow为核心建立一个完整的工具、库以及社区资源生态系统。

通过以上的分析，可以得出tensorFlow的第一性原理，即：tensorFlow是一个端到端的面向有状态的数据流图编程的机器学习平台，自带完整的产品生态系统，其逻辑基石为“分布式及机器学习”。就是这么简单的一句话，但是却是tensorFlow作者们的设计理念，整个tensorFlow的所有设计理念、设计原则以及功能实现都是依据这一句话来做指导的。

TensorFlow的设计原则

从tensorflow的官网可以看到几个关键词“easy,robust,powerful,ecosystem”，这几个词即是temsorflow的设计原则，tensorFlow的设计原则是定理性质的定义，其也从tensorFlow的第一性原理定义中推导出来。“端到端”代表了易用性，“平台化”、“可编程”代表了功能强大，“分布式”代表可高可用性、高可靠性，另外tensorFlow还有一个生态化的运营理念，灵活、开放、完整。

易用（Easy）

易用性的设计原则体现在与用户打交道的API接口层、模型的使用以及分布式训练：

• 模型制作简单，API容易调用，TensorFlow 提供多个级别的抽象接口，可以使用高阶的 Keras API 轻松地构建和训练模型

• 开发过程可调试，支持Eager Execution 进行快速迭代和直观的进行调试

• 训练过程简单，可以使用 Distribution Strategy API 在不同的硬件配置上进行分布式训练而无需更改模型定义

可靠(Robust，鲁棒性、可靠)

• 支持随时随地进行可靠的机器学习生产。支持在本地服务器、边缘设备、云端、web端轻松地训练和部署模型，而无需关注开发语言。TensorFlow Extended (TFX)可用于生产型机器学习， TensorFlow Lite可用于移动设备和边缘设备的推断， 而 TensorFlow.js 支持在web端中训练和部署模型

强大（powerful）

• 架构简单而灵活，支持最先进的模型，并且可以保证性能。借助 Keras Functional API 和 Model Subclassing API 等功能，TensorFlow 可以灵活地创建复杂拓扑并实现相关控制。TensorFlow 还支持强大的附加库和模型生态系统，包括 Ragged Tensors、TensorFlow Probability、Tensor2Tensor 和 BERT。

生态化(ecosystem)

• 生态化是产品的商业模型，灵活、开放、强大，tensorFlow具有完整的一个生态环境，其拥有一个包含各种工具、库和社区资源的全面灵活生态系统，可以让研究人员推动机器学习领域的先进技术的发展，并让开发者轻松地构建和部署由机器学习提供支持的应用

从tensorFlow 1.0 到tensorFlow 2.0 的升级，涵盖了API的易用性升级，动态图的支持、算法的更新、功能迭代以及文档完善，其本质目的还是遵循这四个设计原则，即简单、可靠、强大、生态化。如果只是追寻tensorFlow的版本迭代而不理解其背后的设计理念、设计原则，只会疲于奔命、知其然而不知其所以然。

TensorFlow 架构视图

逻辑架构视图

TensorFlow的逻辑架构视图体现了tensorflow的功能需求，如下图，tensorFlow的功能可分为训练、部署、可视化以及模型仓库。

训练

• tf.data用于加载训练用的原始数据
• tf. Keras 或 Premade Estimators 用于构建、训练和验证模型
• eager execution 用于运行和调试
• distribution strategy 用于进行分布式训练，支持单机多卡以及多机多卡的训练场景
• SavedModel用于保存导出的训练模型，并且将训练模型标准化，作为 TensorFlowServing、TensorFlow Lite、TensorFlow.js、TensorFlow Hub 等的交换格式

部署

• TensorFlow Serving，即TensorFlow允许模型通过REST以及gPRC对外提供服务
• TensorFlow Lite，即TensorFlow针对移动和嵌入式设备提供了轻量级的解决方案
• TensorFlow.js，即TensorFlow支持在 JavaScript 环境中部署模型
• TensorFlow 还支持其他语言 包括 C, Java, Go, C#, Rust 等

可视化

• TensorBoard 用于TensorFlow可视化

模型仓库

• TensorFlow hub用于保存训练好的TensorFlow模型，供推理或重新训练使用

处理架构视图

TensorFlow的处理架构视图表明了数据处理的流程，其具有tensorFlow的运行期间的质量需求。

本图是分布式工作模式，“/job：worker / task:0” 和 “/ job:ps / task:0” 都是工作节点上执行的任务。“PS” 表示 “参数服务器”，负责存储和更新模型参数。

处理流程

1）客户端负责将整个计算过程转义成数据流图，并且启动计算发送到分布式主节点；

2）分布式主节点基于用户传递给的参数对整个完整的图形进行修剪，提取其中的子图，接着将子图拆分成不同部分，并将其分发到不同的进程和设备当中；

3）工作节点执行其收到的主节点分发给它的数据图片段，并且与其他工作节点 相互发送和接收计算结果；

4）内核计算单元，执行单个图形操作的计算部分。

数据处理期的质量与约束

TensorFlow分布式模式是构建在分布式之上的，其具有分布式系统自身的质量与约束需求：

• TensorFlow的质量需求：性能指标：TPS、QPS、IOPS、Latency、ResponseTime、缓存抖动指标、缓存命中指标，可靠性指标: 6个9企业级代表，可用性指标：6个9企业级达标，数据一致性指标，可伸缩性，韧性，可观测性，可服务性，安全性，易用性，可运维性等

• TensorFlow的约束需求：其可以是资源容量约束：CPU、磁盘、网络、线程、文件描述符个数，也可以是客户的约束、用户的约束等。

TensorFlow 2.0 的缺点

• 网络，开源的TensorFlow默认采用gRPC作为基础通信组件，违背“最佳物种”里的最佳原则设计哲学，机器学习本身是高吞吐量高性能要求的生产场景，而gRPC是基于HTTP2/Protobuf 协议通信的，而且发送接收都需要序列化，增加了网络传输的延时，并不是机器学习场景的最佳选择，但是好在TensorFlow也支持让你“DIY”的设计理念，例如在网络通信上支持GDP（GPU DIRECT）VERBS(IB,RDMA)以及MPI的扩展（“https://github.com/tensorflow/networking: Currently support building GDR, VERBS, and MPI extensions），这相当于把这一部分产品化的工作给了用户或者GPU、TPU之类的芯片原厂。优化手段：将PS算法、RING ALLREDUCE算法融合进MPI，再根据工程实践情况取舍“容错、可服务化、可运维化、智能化“的设计理念，抽象出一个新的分布式调度中间件以替换gRPC，目的是获取更好的性能、更高的GPU、TPU性价比。

• 计算，计算架构很有限还不能榨尽各种硬件的最佳性能。目前的分布式计算视图架构成熟的方案有：Parameter Server 架构以及Ring AllReduce架构，那么是否还有其它更好的架构，比如区块链的去中心化架构。

• 存储，存储应用容易被忽视，系统太过于复杂。TesnorFlow里涉及到存储的地方有：海量或非海量的原始数据存储、ETL好的数据的存储、PS架构中的训练参数以及模型的存储，训练好的模型的存储，如果这四个存储需求都是分散的存储系统，其实复杂度挺高，可以专门针对这种场景以及数据特性设计一个专门的机器学习存储系统，除了可以同时满足这四个场景的质量指标外，还将四个系统统一成一个，减少机器学习场景下的系统复杂度。

• 功能，功能的优化是无止境的，原则是要遵循客户需求适可而止。TensorFlow本质上也是分布式系统+机器学习领域的能力，除了机器学习的各种算法魔法的持续优化，分布式系统里的各种分布式算法也是适合迁移过来挖掘的，比如服务治理、路由负载均衡算法、集群视图变更、消息传输等。比如这么一个工程课题：“如何支持上万张训练卡的规模以及如何保证其质量可以达标？如何保证系统性能可以随着训练的卡数线性增长并且保证卡子的利用率在90%以上，同时可以保证训练过程的可靠性？”

• 产品，一个开源项目的功能特性大多是取舍的结果，就算是缺点往往也会很快演化迭代掉，因此从技术角度看待一个开源项目缺乏可持续性。但是从产品的角度来看，开源项目自带开源的先天弊端，其缺乏“价值与市场的锲合“度，这是开源项目的先天缺点，越成功的开源项目越无法避免，如果避免了这个缺点，开源项目反而是失败的，因为做的太好反而无法收费，团队没法存活，TensorFlow2.0开源版是一个开源的项目因此也逃脱不了这个缺点。从“项目与社区锲合”以及“产品与市场锲合”的角度来看，依据点赞数、fork数、下载量、用户使用量、社区文章阅读量这几个指标做度量，TensorFlow 2.0 开源版是一个非常成功开源的软件，但是从”价值与市场锲合“这个角度看，其离商业产品还是有一段距离。

  开源项目往往是靠一些增值功能、企业级特性以及服务的支持收费而存活，这些特性即为价值与市场的锲合点，是商业客户愿意买单的地方，是商业产品与开源项目差异化所在，这些特性有：更好的性能、更加易用的部署与升级功能，可运维化、更加易用的可视化功能、安全、可观测、质量的可度量性，此外客户往往需要的不只是一个产品，更进一步需要的是行业解决方案。例如，tensorFlow企业版就说明了支持企业级特性、可云端伸缩性能以及无缝管理的支持，而TensorFlow2.0 开源版只是一个开源项目，还没达到这个层度。

  因此，从产品的角度看，开源的tensorFlow2.0开源版只能算是一个成功的开源项目还不是商业产品以及解决方案，它只完成了“项目与社区锲合”以及“产品与市场锲合”这两个层次，因此商业化就要求我们需要把开源的tensorFlow2.0产品化、解决方案化。

小结

本文依据第一性原理架构设计思维模型解读了TensorFlow2.0。第一性原理思维模型我不是首创，分布式系统架构设计我不是首创，第一性原理思维模型在分布式系统架构设计中的应用我是首创。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

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

参考资料

[1] https://blog.tensorflow.org/2019/09/tensorflow-20-is-now-available.html

[2] https://github.com/tensorflow/tensorflow

[3] https://en.wikipedia.org/wiki/TensorFlow

[4] https://www.tensorflow.org/about

[5] https://tensorflow.google.cn/guide/?hl=zh-CN

版权申明

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

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

动机

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

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

架构思维模型

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

火箭架构思维模型

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

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

势：时势，是架构的方向

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

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

道：理念，是架构的认知

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

进行分布式系统的架构设计，首先我们要知道分布式系统的第一性原理是什么？即分布式系统的类似公理性质的定义，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法10项2原则“ 作为方法论。

9法

1
2
3

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

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

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

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

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

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

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

• 服务需治理：指的是分布式系统是由各种不同的组件进行组合连接而成，其需要服务治理设计，服务需治理背后的原因来源于分布式系统式搭建在网络上的，其继承了网络的毛病，背后的指导思想是“墨菲定律”，即“会出错的事总会出错”，服务治理的具体解决方案可分为容错、降级、限流、熔断、隔板这五个模式
• 数据保一致：要保证分布式系统对外提供的服务的数据的一致性，cache掉电会丢数据、网络不可靠会丢数据、磁盘电子不可靠会丢数据，计算丢请求会丢数据，各种场景下都需要保证数据的一致性，比如缓存的MESI算法保数据、掉电刷内存保数据、网络端到端的校验、磁盘扫描校验、数据副本保数据等
• 哪都不可靠：指的是磁盘不可靠、网络不可靠、计算不可靠、运维的人不可靠，何种场景都需要进行系统的韧性设计
• 事事慎权衡：指的是架构设计本身的设计方法论，即trade-off

10项

1
2

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

• 提供：即服务接入的提供，指的是对外提供restful 接口服务：权限、多组合、监控、审计、计费等，对外提供SQL服务接入接口服务、对外提供自然语言接入接口服务等
• 注册：即服务注册，将集群的工作负载注册到集群注册中心
• 配置：即配置管理，将集群的配置管理在配置中心；
• 调用，即服务调用，各种RPC调用，系统内的消息传递
• 路由：即服务路由，目的是集群的负载均衡与扩伸缩性
• 观测：指的是集群内部指标的可观测性，即监控、告警、追踪、日志
• 治理：指的是集群内部的服务治理：熔断、降级、限流、隔离、容错
• 编排：即服务编排，基于k8s+ docker，完成安装、升级、扩容、运维、调度等；
• 质量：指的是安装部署运维质量、客户质量、用户质量与开发质量
• 边界：指的是系统内的约束条件，涵盖 硬件资源、客户约束、用户约束以及团队约束

2原则：

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

最佳物种原则

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

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

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

功能非功能原则

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

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

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

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

术：技能，是架构技能

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

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

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

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

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

  

  如上图常用的4+1视图：物理视图、逻辑视图、处理视图、开发视图以及用例视图，其中与用例视图交叉的部分是描述共同的细节，同时每种视图中又有各自的需求，比如物理视图有安装、部署、升级、运维的需求，逻辑视图有功能需求，处理视图有非功能里的用户运行质量需求，开发视图有团队的开发质量需求。

• 分布式系统的基础理论：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等，当然组织提供的资源支持也可以算是工具之一。

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

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

小结

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

作者简介

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

版权申明

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

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

动机

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

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

分布式系统

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

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

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

前言

日拱一卒，功不唐捐，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计36式》，讲诉分布式系统里最重要的三十六个的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

“兵者，国之大事，死生之地，存亡之道，不可不察也”，这句话对企业来讲，兵即产品，国即企业，察即研究探讨，产品关系到企业的存亡，所以不可以不慎重地加以研究探讨。本文提出toB产品交付双轮驱动思维模型以探讨toB软件产品的交付方法论。

动机

架构设计人员是业务与技术之间的桥梁，其既需要保证产品需求合理，也要保证产品交付的功能是对客户、用户有用、有价值的。为了能够准确的落地业务需求同时又能保证产品按时交付，架构设计人员就需要一个可以量化执行的产品业务需求与产品交付的思维模型。

双轮驱动思维模型

受 《持续交付2.0》的启发这里提出toB产品交付之双轮驱动思维模型。双轮驱动思维模型以业务需求为出发点，探索业务真实有用的价值，以最节约的成本和最可控的风险，通过持续的业务价值探索和产品迭代交付快速交付价值与市场锲合的产品，其思维模型如下图所示：

总则

产品的交付的是价值，因此双轮驱动思维模型是一个产品价值交付模型，总的理念是以“真北业务价值”为导向，以“产品快速交付”为动力，将“业务价值”与“产品交付”双个环节紧密结合，前轮业务价值把握方向，后轮产品交付提供动力，从而驱动业务与产品一起前进。它以“产品价值与市场锲合”为指导思想，以“以客户为中心”为工作理念，以“指北需求”，“精简过滤”、“量化分解”、“快速反馈”和“演化迭代”为工作原则，是一套持续集成持续交付产品的思维模型。

• 产品价值与市场锲合，指的是客户需要什么以及你能提供什么的从而获得产品商业成功的问题。朴素的说法就是产品的价值是市场需要的，是客户的痛点、恐惧点、难点以及挑战点，是客户要什么你就给什么，而不是从自己的角度出发，自我感觉良好地强塞给客户什么，是自身提供的产品能否准确满足市场真实需求的问题，度量的指标是”客户是否愿意快速的为你的产品买单“。

• 以客户为中心，指的是“以客户需求为导向、为客户提供高质量低价格的产品、为客户提供满意的服务以及快速响应客户需求”，以客户为中心不是没有底线的跪添客户或者一些违法的行为，而是走正道为客户提供优质低价的产品或服务，快速响应客户的需求，帮助客户取得商业上的成功的问题。

• “指北需求”，“精简过滤”、“量化分解”、“快速反馈”和“演化迭代”，指的是挖掘客户的真需求，需要对客户的需求精简过滤、去伪存真，再通过量化分解客户的需求为可落地执行的行为，这样才能快速交付产品、快速验证、迭代演进。

价值轮

价值轮是一个理解真北需求、去伪存真的过程，具体包括以下四个环节：

• 需求：通过”客户、用户、团队“三个维度收集需求，将收集到的业务需求信息输入到价值轮；

• 确定：针对输入的需求去伪存真、去粗存精确定真北需求，识别客户的痛点、难点、恐惧点以及挑战点；

• 探讨：团队讨论，深入理解需求，拿出可行的解决方案以及实现方案；

• 精炼：为了节约团队资源，不是所有的方案都需要传递给产品交付环去执行，因此需要精炼过滤这些方案，有些通过常识就可以判断不合理的方案就不需要往交付轮传递，其次要进行价值优先级评估，筛选出最有价值的需求与方案，以作为交付轮的输入，并等待交付轮的交付与反馈。

交付轮

产品或服务在被客户买单之前都是成本，只有被客户采购并且最终能够买单或者被用户使用并且最终兑现，才能证明其价值的存在。因此在价值轮达成共识后要借助“交付轮”快速交付，才能将其传递到客户或用户手中，从而得到真实且可靠的反馈以验证之。

交付轮它也包含四个环节，分别是（1）开发；（2）测试；（3）运维；（4）反馈：

• 开发：指以及价值轮的输入需求以及精简过的方案，依据质量要求进行软件架构设计以及进行软件开发并且达到可运行要求；

• 测试：指的是测试以及验证设计开发阶段交付的软件是否达到功能、质量与约束的要求；

• 运维：指的是将开发以及测试好的软件包部署到生产环境中运行或交付给客户为客户提供生产服务；

• 反馈：指的是监测生产运行情况以及收集用户使用情况与反馈的信息，再将收集到的信息反馈给价值轮，作为业务参考以便做出下一步的业务决策与判断。

小结

本文讲述”toB产品交付双轮驱动思维模型“，日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这几个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

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

版权申明

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

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

参考资料

[1]《持续交付2.0 - 业务引领的DevOps精要》 乔梁著

分布式计算中间件之信息分析基础

构建与领域设计

通常分布式计算中间件可以从两个层面进行划分：

1，构建与运维 ： 分布式功能的设计与实现

2，领域设计 ： 具体领域相关功能的设计与实现

• 数据计算与分析中间件，实现数据计算与分析领域功能，比如 Flink, Spark, elasticsearch等
• 深度学习计算中间件， 实现深度学习领域功能，比如 tensorflow, caffe等；

信息分析基础

信息分析基础：下图从功能，质量、模型、定义、本质、视角、职责、相关性、难题以及Lucene 等方面归纳了检索与分析技术领域基础10项。

作者简介

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

版权申明

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

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

参考资料

[1]《信息检索导论》

前言

日拱一卒，功不唐捐，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计36式》，讲诉分布式系统里最重要的三十六个的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临只见“点与线”而不见“面与体”的难题 。本系列中的思维模型章节主要是为了解决分布式系统设计中的“面与体”的难题，它包括：需求分析思维模型、 技术思维模型、产品思维模型、创新思维模型以及商业思维模型，依据这些模型往上套就可以从“点、线、面、体”这四个层面系统性的设计一个分布式系统。

如果说技术是分布式系统工程师的一根DNA螺旋线，那么“产品、创新、商业”等就是DNA的另外一根螺旋线，只有两根螺旋线俱全并且不停的演化才能进化出新物种，本文将讲述思维模型里的 “需求分析思维” 模型。

需求分析思维模型

架构师是业务需求与产品落地之间的桥梁，因此准确地理解业务需求也是架构师必备的一个基本能力，准确地理解业务需求需要从理解业务愿景、策略与执行以及软件需求开始。理解业务愿景需要理清楚业务目标与产品的技术目标，理解策略与执行需要看清楚企业的战略方针、团队定位以及执行方法论，再次才是理解软件的产品需求。

业务愿景

1，业务目标

业务目标是很粗略的业务描述，比如需要提供物联网数据的存储服务或者比如给深度学习框架提供专门的训练芯片等.

2，技术目标

技术目标分为功能目标与非功能目标，功能目标是跟业务需求强相关的软件功能需求，比如提供原生的时序数据存储功能，还比如分布式计算功能。非功能目标可以分为质量目标与约束目标，比如性能质量、可用质量以及系统硬件规格约束等，对于产品来说质量与约束都需要可度量化、可验证化。

策略与执行

1, 战略方针

产品的战略意味着方向、资源以及取舍，方针是如何打造出这么一款产品的策略，一开始从全方位复制再处处差异化竞争也是一个思路，比如全面复制市场上已有的产品，再从产品、技术、销售、服务、运营、客户定位等方面处处差异化竞争。

2, 团队定位

团队文化即产品文化，打造一款产品需要一个团队，组织文化也深刻的影响着产品，团队不同意味着不同。国内一些企业团队复制国外产品的时候，往往有其形而无其神，原因之一往往是团队定位以及企业文化的不同。

通常来讲团队可以用四种类型来类比：海盗、特种兵、军队以及警察。海盗团队求生存，特种作战团队求根据地，军队团队求统一全国，警察团队求维稳。采用不愁吃喝的警察维稳的思路开发一款新产品又怎么能跟需要打下根据地的特种作战部队一样呢，跟需要求生存的海盗部队更不一样。

3, 执行策略

执行策略是指产品落地的方法论，持续交付2.0的方法论就很类似火箭思维，采用火箭思维意味着先开工再在过程中矫正，先确保大方向正确，开工过程中矫正直至准确命中目标。

软件需求

架构师需要能准确理解业务愿景、产品策略，将抽象的愿景、目标、策略等分解成可量化的、可执行的具体任务，从而准确实现业务到产品的落地。

从业务到产品的过程中，能够准确的理解业务的软件需求也是一个非常重要的思维能力，这样可以保证大方向的正确性，这里提出一种从业务到产品的需求分析模型，以准确的理解软件需求，从而保证软件产品的落地方向的准确性。这里我提出一个公式：

软件需求 = [客户，用户，团队] x [功能，质量，约束]

依据这个公式我提出“三三制需求分析思维模型”以抛砖引玉，如下图：

“大”客户

这里的“大”字有两个层面的意思，首先是范围上的”大“，三三制模型里的客户不只是狭义上的产品的客户，还包括整个产品利益链上的客户，比如客户的客户，因此这里称之为 “大“客户。第二这里的”大“字是规模上的大，从商业的角度来看大订单客户理应获得更大的关注。

功能

客户关注的功能即为业务目标，比如获取商业上的成功、业务难点、恐惧点、挑战点以及压力点等。对架构师来说 “以客户为中心”导向的业务功能目标不只是提供“高质量、低成本、服务好、响应及时”的基本产品或服务需求，还包括帮助客户获取商业上的成功，帮助客户解决难点、痛点、恐惧点、挑战点以及压力点。

质量

客户对产品质量的需求一般可以用四个字概括，即”多、快、好、省“，当然从软件工程的角度来说，四个方面全满足是极其困难的，因此应该根据实际情况合理取舍，对客户的需求需要进行合理的”过滤“，去粗存精，去伪纯真。

约束

对于客户的需求只关注功能和质量而忽视约束也是不够全面的。客户在产品交付的时间、质量与成本上需要取舍，客户原来遗留的系统以及资产，当前国家的法律法规，市场上的技术趋势，以及竞争对手与行业标准等都属于当前需要考虑的约束需求。

”大“用户

这里的”大“用户的”大“字，也分为两个层面的意思，一是范围”大“，不只是当前产品的用户，还包括用户的用户以及整个产品使用链上的所有用户，二是规模”大“，主流用户的需求更应该第一时间满足，有限的资源应该在第一时间满足主流用户的需求。

功能

功能需求指的是满足用户对业务的需求，用户需要什么就提供什么，而不是我有什么就非要给用户什么，以”用户“为中心的思路也是正确的。

质量

用户的产品质量需求一般称为使用质量需求，可以从以下几个维度进行分析：

• 合适的性能（Performant），性能指标一般包括 TPS, QPS, Latency, IOPS， response time等，这里用”合适的性能“作为表达，指的是性能合适即可、够用即可，高性能当然好，但是高性能也意味着更高的成本，有些场景高性能反而是一种浪费行为，性能需求需要理解业务场景适可而止；

• 可用性(Availability)，可用性指的是系统长时间可对外提供服务的能力，通常采用小数点后的9的个数作为度量指标，按照这种约定“五个九”等于0.99999（或99.999％）的可用性，默认企业级达标的可用性为6个9。但是当前从时间维度来度量可用性已经没有太大的意义，因为设计得好的系统可以在系统出现故障得情况下也能保证对外提供得服务不中断，因此，当前更合适得可用性度量指标 是请求失败率；

• 可靠性(Reliability)，可靠性一般指系统在一定时间内、在一定条件下可以无故障地执行指定功能的能力或可能性， 也是采用小数点后的9的个数作为度量指标，通常5个9的可靠性就可以满足企业级达标；

• 可伸缩性(Scalability)，是指通过向系统添加资源来处理越来越多的工作并且维持高质量服务的能力；

• 韧性(resilience)，通常也叫容错性（fault-tolerant），也就是健壮和强壮的意思，指的是系统的对故障与异常的处理能力，比如在软件故障、硬件故障、认为故障这样的场景下，系统还能保持正常工作的能力；

• 可观测性(Observability)，是一种设计理念，包括告警、监控、日志与跟踪，可以实时地更深入地观测系统内部的工作状态；

• 安全性（security），指的是阻止非授权使用，阻止非法访问以及使用，保护合法用户的资产的能力；

• 易用性（usability），指的是软件的使用难易程度，对于产品的易用性来说， 易用性不仅仅 是软件使用角度的易用，还包括安装、部署、升级上的易用,升值还包括硬件层面的易用，比如产品的外观，形状等；

• 可运维性（operability），可运维性指的是运维人员对系统进行运维操作的难易程度，主要包含以下几个方面的难以程度： 系统的部署、升级、修改、监控以及告警等。

约束

用户的约束需求包括 用户的业务环境，用户的能力以及用户群的特征等。

”大“团队

这里的大团队的”大“指的是范围上的大，不只是直接开发人员，还包括跨职级、跨部门的利益相关人员。

功能

软件功能需求从产品的角度来说可以分为五种，即：

• 基本功能，这是在产品概念阶段就必须实现的功能也是在产品的第一个发布版本中必须提供的功能，比如数据处理产品的”读与写“；

• 核心功能，核心功能是产品的主要功能，扩展了基本功能的外延，比如为了保证性能达标的缓存功能、分布式功能等；

• 增值功能，这里指的是一些产品差异化的能力，比如安全、监控、告警、日志、升级、部署等；

• 可有可无功能，有些特性存在还是不存在不影响产品的使用也不会带来产品的优势，只起到锦上添花的作用，因此属于可有可无的功能；

• 有害无益功能，指的一些功能不只没用还有害，没有识别出来消耗了团队资源不说还对产品有拉后腿的作用。

质量

团队的质量需求，指的是产品开发周期内的质量需求，高质量的代码几个最重要的要素有：

• 可测试性（ testability），指的是单元测试，集成测试，打桩测试等的难易；

• 可维护性（Maintainability）， 指的是代码升级，部署，定位bug，添加功能的难易；

• 可扩展性（ extensibility）， 指的是未来增加新的功能与模块的难易；

• 可读性（ readability），指的是代码的易理解程度。

约束

几个中药得团队的约束需求有：

• 资源预算，产品的质量与功能以及发布周期受限于预算；

• 上级要求，上级的要求相当于客户要求也是非常重要的约束条件；

• 开发团队的能力，开发团队的能力组成、知识结构组成决定了产品是否能够交付以及能否高质量的交付；

• 产品规划，产品规划得进度是产品的交付周期以及开发进度得约束条件；

• 此外还有信息安全以及产品运行环境 的约束。

小结

本系列文章讲述了五个思维模型： “需求分析思维模型、技术思维模型、创新思维模型、商业思维模型以及产品思维模型”，再结合分布式流存储做了简单的举例分析。本文讲述”需求思维模型“，日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这几个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

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

版权申明

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

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

参考资料

[1]《软件架构设计》 温昱著

进EMC马上两年，12月份里程碑两件。

一是硬技能，项目里个人提交的代码突破6万行，产品第一个版本月底发布；

二是软技能，专利公司内过审3个，写文章推广产品以及提升团队的技术影响力获得公司副总裁认可给了个奖。

代码行数突破6万行

专利过三

GEEK BANG 技术文章活动奖

前言

日拱一卒，功不唐捐，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计36式》，讲诉分布式系统里最重要的三十六个的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

“兵者，国之大事，死生之地，存亡之道，不可不察也”，这句话对企业来讲，兵即产品，国即企业，察即研究探讨，产品关系到企业的存亡，所以不可以不慎重地加以研究探讨。

我们知道一个产品的成功不只是技术的成功，它还包括商业、创新、管理、资本、运营以及销售等的成功。当打造一个产品的时候，通常来说工程人员往往会比较关注技术层面的东西： 方案、功能、难点、亮点以及如何实现等，深度有余但高度与广度往往不足 。一般有点经验的工程人员都可以从点或线的层面考虑一个产品的实现，但往往缺乏从面及体的层面看待一个产品的能力。

因此，如果说技术思维是架构师的一根DNA螺旋线，那么产品思维、创新思维以及商业思维等就是架构师的另外一根DNA螺旋线，只有两根DNA螺旋线俱全才能有机会进化出新物种。

动机

人的知识与能力可以从“时空”这两个角度进行评价，其可分为四个维度：深度、广度、高度以及跨度。空间角度指的是深度、广度、高度，时间角度指的是跨度。深度靠专研，广度靠学习，高度靠抽象，而跨度靠长久地积累经验。这四个维度组合成了一个人的知识与能力的时空度。

万事万物逃脱不出“不易、简易、变易”这三个层次，金庸先生的《天龙八部》里少林寺有72技，其每一技又千变万化，想要样样精通，今生无望，然而练就“小无相功”却可以以这功法催动不同的“技”，甚至可以比原版更具威力，以“不易 简易”之功施展“变易”之术。那么对于技术开发人员来说技术也是“变易”的，更新快，领域多，复杂度高，样样精通也是今生无望，那么需要的就是找出适合自己的“功”，技术思维模型、产品思维模型、创新思维模型、商业思维模型就是这样的“功”。

因此本系列文章提出了技术、产品、创新与商业这四个思维模型，这一系列文章不是为了解决具体的某个分布式系统设计里的难题，它提出了一种思维框架，从技术、产品、创新以及商业的角度，给工程人员以一种系统性的分析分布式系统设计难题的模型，这也是一种系统思维的体现。

产品思维模型

最后一个思维模型是产品思维模型，它是以上三个思维模型的组合与新生，如下图：

产品思维模型灵感来自于阿基米德的一句话:”给我一个支点,我可以撬起地球。“，因此定义它为阿基米德产品思维模型。

如上图所示，在产品思维模型里产品被看作是一个圆，在圆之外还有一个杠杆、一个支点以及一个作用力。在产品圆里除了技术火箭六元组、产品创新奇点、五看三定六要素之外还补充了 产品价值网，企业文化、企业制度以及组织结构这三个要素。

价值网

产品价值网指的是产品所在的市场，是产品需要去匹配的市场，也是产品的市场天花板，市场空间的大小意味着产品的增长局限性，它可以是10倍增长的、缓缓增长的或者存量市场等。一个自我快速膨胀的市场空间里往往可以事半功倍，比如2000年后的互联网市场。

价值网是产品所在的市场，通常采用三个指标来描述产品是否适合价值网：技术-产品匹配，产品-市场匹配以及价值-市场匹配。

技术-产品匹配（Technology-Product Fit）

TPF这个概念是我新提出的，做工程不同做研究，工程当中技术取舍的关键在于适合即可，技术超前于产品是优势但是也是成本，技术落后于产品，缺乏创新，也容易被市场淘汰。技术于产品锲合度的度量在于满足客户需求即可，包括核心需求与增值需求。

产品-市场匹配（Product-Market Fit）

产品-市场匹配的意思指的是产品确定是可以满足市场真正的需求的，并且产品可以从客户那边获取生存下来。

产品-市场匹配度的度量标准有： 客户的下载数量、客户付费数量、客户求购的数量、客户愿意付钱。

价值-市场匹配（Value-Market Fit）

价值-市场匹配指的是产品所提供的价值是真正满足市场需求的，从软件的角度来说可以匹配的价值有：产品质量、性能、可扩展性、可靠性、可视化、安全、审计、辅助工具以及各种插件等。

企业文化、企业制度以及组织结构

产品也是受企业文化、企业制度以及企业组织结构影响的，对于”这三要素如何影响产品？“这一主题没有研究过，这里不敢展开讲。但是可以确定的是“诚信 以人为本”的企业比“KPI导向 利益驱动”的企业更能出现优秀的作品。

支点

支点即关键着力点，它是撬动产品的着力点，它也可以是”以客户为中心，为客户创造价值“的理念，也可以是关键资源、战略投入等，最适合自己的、自己最拿手的要素就是支点。

杠杆

杠杆可以是创新，也可以是资本，是撬动产品从而获得10倍增长效应的关键要素，关键时刻需要对产品启动杠杆效应以获取大规模爆发机会。

关键能力

一个企业的能力包括：技术，产品，渠道、市场、资源，资本，管理，运营，人力，销售，财务等，这里的关键能力，指的是最拿手的一个或几个能力， 选出最适合自己的， 比如技术领先的能力、打造产品的能力等，当然也可以认为是管理能力或财务能力，然后作为驱动产品的杠杆作用力。

分布式流存储所在的市场是物联网以及IT运维这样的高速增长市场，产品的支点是”以客户为中心，为客户创造价值“这样的理念，同时在关键能力上，团队组成、企业的存储基因等都是关键能力。

小结

本系列文章讲述了四个思维模型： “技术思维模型、创新思维模型、商业思维模型以及产品思维模型”，再结合分布式流存储做了简单的举例分析。本文讲述”产品思维模型“，日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这几个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

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

版权申明

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

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

参考资料

[1]《第二曲线创新》 李善友

[2]《如何在一分钟内用5个问题讲清你的商业模式》 中欧商业评论，关苏哲

[3] Pravega.io