微服务端点之间的通信（1）— 编制和编排

本章将会覆盖下列主题：

微服务间应该如何通信；

编制（orchestration）和编排（choreography）；

同步通信和异步通信；

使用消息代理的事件驱动微服务；

财务微服务的开发。

3.1 微服务间应该如何通信

在当今的软件系统中，一个安卓应用的页面或者一个网页就可以展示大量不同种类的数据。如果后台是基于微服务的，那么这些不同种类的数据不可能是由单一微服务生成的，一般需要多个微服务协同才能产生这些不同种类的数据。要实现多个微服务协同工作就免不了需要微服务间的频率通信。在处理单体应用时，整个代码库都是同一种语言并放在一个地方的。单体应用中各个模块之间通过函数和方法调用来进行通信。但是，在微服务架构中，这是行不通的，因为每一个微服务都是一个单独运行的进程，各个微服务的上下文也完全不同，甚至可能连运行的硬件环境都有所不同。我们可以从不同的视角解读微服务之间的内部通信模式。如果从控制流和通信流的视角来看，微服务之间的通信可以分为编制和编排两种。

3.2 编制和编排

假设有一个团队，大家有一个共同的目标。这个时候可能的情形有两种：第一种情形是团队中有一个领导，他是团队的核心大脑，他对整个团队的能力非常了解，团队中每个个体的工作都由这个领导来分工协调。如果两个工作有依赖关系，就由这个领导来负责在被依赖的工作完成时再开始安排后续工作；另外一种情形是团队中每个人都是自组织的，相互之间有需要的时候自行沟通（通过电子邮件、电话、即时聊天或者其他媒介），并不需要一个专门的领导来安排。在第一种情形下，你需要专门雇一个领导来管理团队，某些时候找个适合团队的领导也挺难的，而且还必须为这个领导支付一笔可观的工资。第二种情形也有一些劣势，例如，你在做完某件事之后，需要广而告之让所有人

都知道。在第一种情形中，要知道团队的进度可以随时问领导，但是在第二种情形中，你需要与每一个团队成员交流才能知道整个团队的确切状态。这两种情形对应的模式分别称为编制和编排，下面我们来深入讨论这两种模式。

3.2.1 编制

orchestration（编制）这个词又指管弦乐编曲，编制这种模式是从管弦乐队的指挥这种角色衍生而来的。指挥的工作是通过一些标志来安排各个微服务的工作，每个微服务会相应地做出回应。我们可以类比成一个音乐家团队，团队中的每个人都知道自己要做的事，也能做得很好。但是这些音乐家是如何知道应该按照什么节奏和曲调演奏，以及在什么时候开始自己的表演呢？这都是通过指挥挥舞指挥棒来控制的，通过某些约定的手势，每位音乐家就知道什么时候演奏哪个乐器，最终完成一次完整的演出，如图3-1所示。

在微服务模式中也使用了同样的概念。微服务中需要一个调度服务来扮演管弦乐队（这里类比的是多个微服务组成的团体）中指挥的角色。这个调度服务会触发并请求各个微服务开始相应的动作。这个时候所有的微服务都服务于这个单一的业务目的。这个中间微服务通过给相应微服务发送消息的方式来进行调度。这些消息既可以通过HTTP请求发起也可以通过套接字请求发起。需要指明的一点是，这里的请求既可以是同步的，也可以是异步的。一般来说，这种模式中个体微服务是不会相互通信的。这种模式下修改工作流会比较简单。在编制模式中，协议类型是不受限的，调度服务能够支持多种不同服务需要的多种不同协议。例如，服务A的通信协议是HTTP，服务B的协议是XML/RPC

等。在第2章中探讨的智能API网关模式就可以起到这里调度服务的作用。这种方式也是很有挑战的，这种模式下调度服务的权力过于集中，所有服务的启动都始自这个中心调度服务。这种较为集中的调服服务的存在并不是一个很好的微服务设计。调度服务中的逻辑增加了很多务之间的依赖，例如，假设调度服务有一个职责是在服务A响应之后开始调用服务B，那么这个时候服务B其实是依赖于服务A的。

在下面的例子中，调度服务首先会检查消费历史和银行明细，然后请求决策服务做出决策，如图3-2所示。这个时候很容易可以知道其贷款的申请进度，但是由于核心逻辑现在都放在贷款服务（也就是调度服务）中，随着系统的逐渐扩展，这个起调度作用

的贷款服务会对整个系统产生影响。

运行和维护这样一个调度服务是有很高成本的。另外一个问题是，这种调度服务自然而然就成了整个架构中单点故障的隐患。当然单点故障也可以使用一些更好的工具和基于云的方法进行化解，如自动扩容、集群等。此外在一个复杂的领域中，编制模式的实现是很有难度的。对于这样的调度控制器，是很难做好分布式设计的。

3.2.2 编排

与编制模式不同的是，编排模式中，每个组件按照各自预先定义的任务来相互协作。我们可以将其类比成一个舞蹈团，每个人按照预先定义好的步骤跳舞即可，某些时候舞者需要相互配合，某些时候大家都是同步的（如图3-3所示）。

在编制模式中，由调度服务负责调遣所有的服务，而在编排模式中，各个微服务都是相互协同工作的，在交互中会涉及每一个微服务。

在编排模式中，每个服务在做完其工作之后与其他服务进行交互，某些时候是在其自身的工作做到一半时需要触发或初始化下一个服务的工作。该模式中的沟通方式可以是一对一的也可以是一对多或者多对多的。与编制方式类似的是，编排方式可以是同步的也可以是异步的。理想情况下，在编排模式中，各个服务之间会使用一种通用协议进行通信。编排模式中倾向于使用异步通信方式，因为没有中心调度服务的存在，每个组件只需要在完成各自任务的时候广播事件即可，此种方式下各个服务之间实现了解耦和独立。每个组件只需要监听一个特殊的事件或者消息，然后在其他组件发出这种事件或者消息时做出响应即可。

在编排模式中，服务之间通过消息、订阅渠道或者主题来观察其系统环境。在基于消息的通信中，编排模式会非常有用。使用编排方式时，对微服务进行解耦以及添加新服务和移除老服务都非常简单。此种方式可以将系统从编制模式中可能出现的依赖泥潭中解救出来。毫无疑问，编排模式增加了系统的复杂性，每个服务都在运行时产生和消费消息。因此，没有太好的办法能识别事务的确切状态。服务需要有其自己的专门实现才能观察到整个系统的当前状态。这就是这种模式的一些弊端。

在这里的两种模式中，没有哪一种是明显优于另外一种的。在选择的时候要具体问题具体分析。而且在某些系统中，这两种方式都存在。例如，分析大数据的事件流可以使用编排模式，系统内部的主业务可以使用编制模式。下面我们会从另外一个角度来看一下微服务中这些不同的模式。

从另外的一个角度来看，微服务之间的数据流和通信的方式也可以分为同步和异步两种。

原文网址：https://www.epubit.com/book/detail/27566

内容来源：异步社区；版权属【人民邮电出版社 异步社区】所有，转载已获得授权；未经授权，不得以任何方式复制和传播本书内容，如需转载请联系异步社区。