下载掌阅APP，畅读海量书库
立即打开
架构编排涵盖了业务架构、应用架构、数据架构、技术架构的设计，以及非功能性需求设计，涵盖了诸多架构技术与方法。之所以将这么多知识统一在架构编排的概念下，主要是考虑普适性，一旦掌握了架构编排的内核，就能够用类似的方法来处理所有相关领域问题。
本章将深入探讨架构编排的内核，并从编排的角度分析2.2节提及的3种系统模型的元素类型及其关系。最后，以高并发和高可用场景为例，介绍如何使用架构编排的方式分析具体的场景设计问题。
“编排”的含义非常类似“组织”的动词含义。因此，在深入探讨架构编排之前，我们仍以社会组织进行类比。
人类早在狩猎文明时代，就懂得了组织的重要性。只是当时的组织方式相对简单，主要是一群人合作打猎，共同抵挡外来动物的攻击等。但也恰恰是这种简单而有效的组织方式，让人类开始脱颖而出，站在了大自然生态链的顶端。
实际上，我们现在已经知道很多动物的群体内部也具备类似的组织方式，例如蚁群、蜂群、大猩猩群体等，但是它们为什么没有发展出类似人类的群体社会特性呢？
答案就在于组织的规模大小。不论蚁群、蜂群还是大猩猩群体，它们的组织多限于一个有血缘关系的家族内部，无法扩展到陌生人层面。而人类则具备了更高级别的社会结构，从而可以实现更大规模的组织形式，这一点从人类跨入农业时代开始就已经变得非常明显。一个国家能有效地运转起来，这一切都得益于有效的大规模组织工作。
然而，不论时代如何发生变化，但社会的组织工作内核一直没有改变，可以用下面的公式表示：
社会组织=社会实体+社会规则
其中，社会中组织的形态有很多种，比如国家、企业、家庭等，根据组织形态不同，组成的实体和规则也不同。例如，在国家这个社会组织中，实体是社会成员，规则是法律；而企业这类社会组织，实体包括部门、员工、机器等，规则是公司法等；以家庭为单位的组织，家庭成员作为实体，并以亲情关系作为规则。
接下来将公式中的3个部分拆开，分别讨论随着时代的演进，它们发生变化的情况。
在组织形态方面，狩猎文明时代主要以家庭和部落为单位进行协作；而在农业文明时代，又出现了国家、城市等各种新型组织形态。到了工业和信息化时代，则涌现出一系列工厂、协会等。可见，随着社会复杂性的增加，组织的形态也越来越丰富。
实体隶属于不同的组织形态。下面从实体类型和实体规模两个方面来简要介绍一下社会实体。
随着时代的发展，尤其是科学技术的发展，在大部分组织形态中，实体已不再限于人类自身，以企业这个组织形态为例，大规模生产流水线、计算机终端、软件系统、数字人等已慢慢成为企业的重要实体。
在大多数组织形态中，实体规模已不受数量的限制。例如，在互联网连接和全球化市场经济的作用下，几乎可将世界上所有人都组织起来。
简单来说，规则可将组织中的实体有序联结起来，比如国家法律。这里不再讨论具体层面的规则，而是讨论一些在不同组织形态中通用的规则。
时间规则是指根据时间因素将不同实体有序地组织起来。比如，在工厂的生产流水线中，工人们需要按照一定的时间先后顺序进行操作；在学校里，上课铃声可以将学生们组织到一起学习。此外，不同实体之间的因果关系也属于时间规则范畴。
空间规则是指根据空间因素将不同实体有序地组织起来，这种空间因素可能包括空间中的位置、层次等。例如，在空间位置方面，随着火车、邮寄服务、互联网等通信工具的陆续出现，各类组织的范围已经扩展到全球，甚至已经向宇宙延伸。又如，在空间层次方面，通常一个复杂的组织形态内部都有分层。例如，企业组织内部有岗位分层、学校组织内也有高低年级分层等。
架构的目标是将复杂系统进行落地实现，因此编排的内涵也非常广泛。本节将架构编排使用以下公式描述：
架构编排=架构元素（或实体）+架构规则
接下来将公式中的3个部分拆开，分别讨论随着架构的演进，它们发生变化的情况。
在本书中，架构编排的形式指的是某一类别的架构知识，例如微服务、DDD、PaaS等均属于某一类架构形式。而且随着时间的推移和系统复杂度的提高，在架构的许多领域，其形态也变得越来越多样化。下面来看一些比较典型的例子。在语言形态方面，我们经历了面向过程、面向对象以及面向函数等不同形态；在服务形态方面，则经历了由单体到SOA，再到微服务的转变；在平台方面，接连出现了IaaS、PaaS、SaaS和中台等不同类型的平台；在模型方面，陆续涌现出DFD、用例图、类图、时序图，再到业务架构中的价值链、价值流、业务流程、服务蓝图等；在架构方法方面，从最初的RUP到业务架构、应用架构、数据架构和技术架构，以及DDD、TOGAF等；在中间件方面，陆续涌现出数据库中间件、消息中间件、大数据中间件等。这里仅列举其中一些，在架构的其他维度中也均存在着各种不同类型的架构编排形态。
可以发现，我们将架构领域中的许多知识都归类到架构编排的范畴内，主要由于它们均可运用架构编排公式中的二元组来表示和分析。
在每一个架构编排的形式中，都可以使用架构元素和架构规则二元组来进行拆分。下面先从元素类型和元素规模这两个维度来介绍一下架构元素。
元素类型指的是某一架构编排形式是由哪些元素组成的。以软件系统为例，它可能是由微服务、服务器、浏览器、中间件、接口、高可用节点等组成的，这些元素通过交互规则连接在一起，最终形成一个有序运行的系统。此外，每一元素可能又由更细分的元素组成，比如微服务包括服务、注册中心、配置中心、网关等。同时，同一架构编排形式随着技术演进，元素类型也可能变得更加丰富。以架构模型为例，随着架构方法论的发展，新的模型不断被提出，元素类型也多了对象、价值等类型。再如，出现服务网格技术之后，服务治理又增加了控制平面和数据平台等元素类型。
随着信息技术的不断发展，可供数亿人同时使用的微信、抖音、淘宝等超大型App已成为现实。不仅用户规模变大，系统自身的规模也随之变大。例如，在单体架构时代，整个系统运行的代码都可以打包在一个文件中进行部署。但是到了微服务时代，一个复杂系统所需的微服务元素数量可能高达成千上万个。
在架构编排中，规则指的是将架构编排形式中的元素有序融合在一起。同时，架构元素之间也存在着一些规则。下面通过两个典型案例讨论具体的规则，再讨论时间、空间这种具有通用性的架构规则，希望给读者带来一些启发。
1） SOA与微服务 。SOA和微服务中都有存在“服务”这一概念。虽然两者非常类似，但SOA中对各种服务之间的通信协议（或规则）进行了明确约束。相反，微服务出于对灵活性与可扩展性的考量，放开了对通信协议（或规则）的限制。实际上，也正是由于微服务中交互规则的“多样性”有效支撑了复杂系统的规模性增长，而非SOA中的“单一性原则”。所以，可以说通信协议是服务之间的规则。
2） 面向过程与面向对象编程。 面向过程编程的主要元素是过程（即函数），而过程之间的交互规则也比较简单，就是调用或反调用。而在面向对象编程中，它的主要元素是对象。相比之下，对象之间的交互规则也要复杂一些，包括依赖、关联、继承、聚合、组合等。
时间规则指的是根据时间因素将架构中不同元素有序地编排起来。比如，不论是RUP中的4个阶段、DDD中的战略和战术设计或是TOGAF中的ADM方法，都是按照时间来串联的。此外，在许多模型图中，如类图、微服务交互图、业务流程等，都有元素之间的调用、依赖或交互关系，这些关系都遵循时间规则。相比传统瀑布方法，敏捷方法也是改变了开发方式的时间规则。
空间规则指的是根据空间因素将不同元素有序地编排起来，空间因素可能包括空间位置和层次等，来看几个例子。在空间位置方面，最典型的例子是物理部署图中不同元素间的空间拓扑关系，不同元素可能分散在不同的城市、园区或网络区域中。IaaS、PaaS、SaaS等平台也隐含了与业务逻辑的远近空间关系。在空间层次中，一个复杂的架构编排通常都有分层，例如应用架构中有分层；DDD设有领域、子领域、限界上下文、聚合的分层等。
可以发现，架构编排与社会组织是非常相似的。同时需要注意的是，尽管架构编排的核心组成部分是固定的，但是随着架构的发展演进，编排形态、元素和规则的具体内容都在不断发生着很大变化。在学习架构的过程中，我们要深刻理解架构编排的这种变与不变。
3.4节、3.5节和4.4节将分别介绍高并发、高可用和可演进的架构编排。4.1节和4.2节将介绍敏捷和DevOps的架构编排。第7章将介绍应用架构、数据架构和技术架构的编排方式。希望读者能从中领悟到架构编排的本质，并可以灵活运用。
本节将从架构编排的角度进一步剖析功能模型、结构模型与行为模型，以及它们的“架构元素+架构规则”具体包含哪些内容。
功能模型用于描述系统“干什么”。具体来说，功能模型又分为两类：一类是针对客户的外部功能，另一类是系统实现的内部功能。
在外部功能中，架构元素一般包括客户和系统两类，它们之间的关系就是系统可以提供给客户什么功能。例如，我们在面向对象分析时常用的用例图就是这样一种功能模型，如图2-5所示。
在内部功能中，架构元素是一个过程，这里的过程通常采用“动词+名词”的形式表示。而元素之间的关系主要依赖对象、数据或控制变量等的传递。例如，汽车加速（外部功能）对应的内部功能模型如图3-1所示。
图3-1 汽车加速的内部功能模型
结构模型主要用于描述系统“是什么”。其中，架构元素通常用一个名词来表示，而架构规则大多情况下表示的是一种连接关系或空间拓扑关系。
例如，应用交互关系图是一种结构模型，它的架构元素是应用，通过连接关系展示应用之间的数据或交互接口。
类图也是编程中常见的一种结构模型，它的架构元素是类，并且类之间的关系比较多样化。比如包含关系是一种空间拓扑关系，而继承和泛化关系则是一种连接关系等。
此外，在系统上线时所用的物理部署图也是一种结构模型，它将服务节点视为架构元素，而服务节点之间的关系既代表了一种连接关系，也代表了一种空间拓扑关系。
行为模型主要用于描述系统“怎么干”。行为模型中的架构元素一般包含两大类：一类是行为的发起者，称作行为体；另一类是实体，可以包括系统、角色、对象等，实体之间通常通过动作建立关系，而多个动作和相应的实体按照先后顺序串联起来，就形成了行为模型。
举例说明，在业务架构建模阶段绘制的业务流程图是一个行为模型，它是一个端到端的流程，因此，它的架构元素包括流程的发起者（即行为体），以及其他参与流程的角色，而角色之间通过动作的先后顺序进行关联。
此外，时序图也是一个典型的行为模型。它主要针对对象的行为建模，其架构元素包括行为发起者（用户或系统）与其他对象，对象之间主要通过消息的交互进行关联。
至此，我们主要在架构编排理论层面阐述。而在实践中，架构编排的应用场景非常广泛，接下来以高并发和高可用为例，讨论一下如何运用架构编排的核心思想来分析、解决相关的设计问题，以便读者对架构编排有更深入的理解。
本节先以都江堰水利工程作为类比探讨一下高并发系统的核心设计原则。为什么选择都江堰作为案例呢？大家可以想象一下，当一个软件系统面临大量用户访问时，是不是与洪水冲过来的场景有些类似。在治水方面，我们国家有着几千年的经验，都江堰至今仍然在发挥巨大作用，这说明了这些经验是非常珍贵的。接下来先看一下都江堰是如何控制水流的“高并发”的。
在都江堰中，主要有3个地方用于防洪，如图3-2和图3-3所示。第一个地方是鱼嘴分水堤，在枯水期，即水流量小时，大部分水会流往内江；而在汛期，即水流大时，就会分流到外江；第二个地方是飞沙堰，当水流量较大时，就是从飞沙堰这里分流到外江；第三个地方是宝瓶口引水口，大家可以看到这个地方很窄，这样水流量很大时就起到了限流的作用。
可以看出，都江堰解决防洪的措施有两种：一种是分流，另一种是限流。相似的是，高并发系统设计的核心思想同样是分流和限流。
图3-2 都江堰示意图
图3-3 都江堰实图
图3-4是一个典型的高并发系统架构图。其中，CDN、双园区设计、应用服务器集群、Nginx中的多进程和多线程、数据库分库分表、分布式缓存等本质上都属于分流技术；而限流技术的范畴更广一些，像F5、Nginx、应用服务器等都具备一定的限流能力。
按照架构编排中“架构元素+架构规则”的二元组，高并发系统架构元素可以包括线程、进程、容器、服务节点等。但是，能否提炼出一些典型的架构规则呢？接下来主要从元素的空间位置、空间层次，以及个体策略维度进行讨论。
首先，高并发系统中的架构元素主要是通过请求串联起来的，属于连接关系，并且这种连接关系从整体上呈现出一个明显的特征，即连接数量呈现出“倒三角”的形态。也就是说，越靠近请求方的节点，其连接数量越多；而越位于下游的节点，其连接数量逐渐减少。举例来说，可以将图3-4所示架构划分为六层：CDN、GTM、F5、应用服务器、分布式缓存和数据库服务器。假设从请求方到达CDN时的连接数为10万个，那么到达F5时可能减少至6万个，并最终在数据库服务器处可能不超过1000个，甚至更少。基于高并发系统架构编排的“倒三角”特征，分别探讨分流和限流的通用规则。
图3-4 高并发系统架构典型示例
在分流的实现上，通常架构元素之间遵循以下架构规则。
一是空间位置方面，越靠近请求方的元素，越应承担更大的分流力度。在实践中，应将适合处理高并发的元素（如CDN、缓存等）尽可能放置在靠前的位置。
二是空间层次方面，如果请求过多，可以考虑增加更多层次进行分流，这样可以有效降低每个元素节点所承受的负载（压力）。
三是个体策略方面，优先利用节点内部的线程和进程进行分流操作。只有当这些资源不足时，再考虑扩展节点来满足需求。
在限流的实现上，架构元素之间通常遵循以下架构规则。
一是空间位置方面，越靠近请求方的元素，其限流的作用往往越关键。因此，应将限流机制尽可能放置在像F5等元素上，而不是放在后端的应用服务器或数据库服务器上。
二是空间层次方面，每一层都应为下一层设置合理的限流数目，以确保每一层都能为下一层提供适当的保障。这样可以避免后端系统过载，从而提高系统整体稳定性。
三是个体策略方面，通常情况下，各个元素自身负责提供限流能力。这种能力可以通过直接拒绝请求或将请求放入等待池中来解决。选择合适的方式取决于具体需求和架构设计。
绝大多数自然界生物具备出色的“高可用”能力。总结起来，动物主要用3种高可用方式保护自己。
第一种也是最常见的方式——冗余设计。不仅人类如此，很多动物都采取了重要器官的双备份设计，例如两只眼睛、两只耳朵、两条腿等。
第二种方式是快速自我修复能力。例如，蜥蜴和其他爬行动物在失去尾巴后可以迅速再长出新的尾巴；章鱼在失去一只触角后也会快速重新长出新触角等。
第三种方式是通过交互合作机制实现高可用性。群居性动物（如蚂蚁和蜜蜂）就依靠集体策略来确保整体的稳定性不受影响。当一个个体遇到问题时，其他个体会迅速补充进来，以维持整体稳定。
实际上，高可用系统所采用的机制与自然界中的高可用机制非常相似。来看一张典型的高可用系统架构图，如图3-5所示。
其中，Nginx的主备高可用采用了冗余设计；虽然在PaaS云平台中部署的应用服务器没有准备冗余服务器，但是PaaS平台具备服务的自愈能力。当服务节点发生故障失效之后，可以快速调度另一个服务节点来替代，这是一种快速的自我修复能力。
图3-5 高可用系统架构典型示例
此外，分布式缓存Redis Cluster的高可用实现中既有冗余的设计方案，又有基于交互合作机制实现的高可用方案。在冗余的设计方案中，Redis Cluster的每个主节点都会有一个或多个从节点。当主节点接收到写入操作请求时，它会将数据同步到所有的从节点上。另外，Redis Cluster还使用了选举机制，每个节点都可以成为主节点或从节点，并通过选举过程确定新的主节点来接管失效节点的工作，这属于通过交互合作机制实现高可用性。
总体而言，我们发现高可用系统的架构设计与自然界生物所采用的高可用规则基本一致，它们都依赖于冗余设计、快速自我修复能力和交互合作机制来实现高可用性。接下来探讨高可用系统中架构编排方式的“架构元素+架构规则”，可以将它们看作二元组。
对高可用系统来说，这些架构元素之间又有哪些典型的架构规则呢？我们从元素间的关系、空间位置、空间层次，以及个体策略维度进行讨论。
一是元素之间的关系方面，元素之间的关系不再是通过请求串联起来的连接关系，而更多表现为一种空间拓扑关系。
二是元素的空间位置方面，通常对高可用的要求越高，元素之间的空间拓扑关系越加复杂。例如，像银行中的核心系统通常会设置3个异地备份，通过尽可能扩展空间来减少可能出现的风险。
三是元素的空间层次一般采用两层结构。除了元素自身之外，至少还需要另外一个能够监控元素状态的元素，在元素失效的情况下及时进行备份元素的切换。不论是冗余方式、自愈方式还是集体合作方式，通常都需要这类监控元素的存在。
四是元素的个体策略方面，往往高可用的要求越高，所需的实体数量也会越多。例如，一般集群模式下，至少需要3个实体来确保集群发生故障失效时仍能正常工作；若希望提供更好的保障能力，则可能需要5个或更多实体。
在上述讨论中，我们仅仅通过元素间的关系、元素的空间位置、元素的空间层次，以及元素的个体策略4个维度进行了分析，在生产实践中，编排包括的维度肯定更多，笔者抛砖引玉，希望能引发读者进一步的思考。
由于架构编排是用于解决信息交换之后的具体设计问题，因此在架构知识模型的3个维度中，架构编排涵盖的范围最广。
本章以社会组织作为类比，深入探讨了架构编排的内核：架构元素+架构规则。接着以高并发和高可用两个常见场景的设计问题为例，讨论了如何运用架构编排思想去分析和解决同一类问题。