转载

服务都微了，编排怎么整？

转载本文需注明出处：EAii企业架构创新研究院（微信号：eaworld），违者必究。如需下载此文PPT，加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号：“加群姓名公司职位微信号”。

相对于传统架构，微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程，可以说服务编排是微服务架构下的必备技能。但是，编排涉及到RPC、分布式事务等等，编排的质量不能仅仅取决于老师傅的手艺，需要有完善的编排框架来支撑。

首先作一点说明，我们认为流程有长流程和短流程之分，长流程是指包含人工活动的流程，流程的完成时间因为人的因素会在一个较大范围内波动；短流程指的是不包含人工活动的流程，在流程启动后会在一个较短的预期时间内完成。

相对于长流程，短流程会更关注与响应时间和tps等指标，也更关注自动保证事务一致性的能力。所以在技术设计上长流程和短流程会有较大的区别，今天本文主要介绍的是短流程相关的那些事儿。

一、编制、编排傻傻分不清楚

说到编排，不得不提两个概念：编制和编排。

服务都微了，编排怎么整？编制的英文是Orchestration，本意是乐队指挥，在演出的时候，乐队由指挥来统一的进行指挥和控制。

编排的英文是Choreography，本意是舞蹈编舞，舞蹈表演通常是舞蹈演员对外部感应作出响应，比如音乐的响应，并且需要与舞伴的行动和表情进行配合。

这两个词用在微服务下，也有类似的含义：

服务都微了，编排怎么整？微服务的编制强调的是通过一个可执行的中心流程来协同内部及外部的服务交互。通过中心流程来控制总体的目标，涉及的操作，服务调用顺序。

微服务的编排强调的是协作，通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。

可能还是不太好理解，借一个现成的例子：

服务都微了，编排怎么整？
编制（Orchestration）就好像交通信号灯，控制着车辆什么时候可以通行。而编排（Choreography）就好像是环岛，没有集中的控制，只有一系列的规则来指明车辆在接近十字路口的时候必须要等待，直到有空间进入环岛环绕系统，然后寻找适当的时候离开。

编制初看起来好像没有编排自由，灵活。但是编排也有不完美的地方：

编排使一个业务流程会嵌入到多个服务中，维护会困难重重。
编排的对等特点，使得两端的服务强耦合，将表现为很难适应需求的变化。

在扩展性上和工程化上编制在一定程度上更优于编排，在一个业务域内编制更适用，而编排更适用跨业务域的流程。

后面要分享的内容，实际上是编制的模式，所以在小节标题上甚至都加了引号。仍然使用编排是因为：第一，他已经太深入人心了，几乎没有听到服务编制的说法。第二，我认为刻意的区分“编制”与“编排”并没有多大价值，重要的是保证各参与方对所用的术语有共同的理解。

二、“编排”的关键在于流程+适配

前段时间我参加了一个devops的项目，其中有一部分是这样子的：

服务都微了，编排怎么整？
在这短短的120行代码中，有25行注释，12行空行，83行功能，包括12次参数校验，18此Rpc（包括14次写操作），包括6大业务步骤，主要功能是实现添加一个用户。但是啊但是，这里面绝大部分是没有事务控制的，可想而知，当真的出现数据不一致的时候我们修复的过程是有多头疼。

我们不能把代码质量完全寄托于老师傅的手艺，编排完全是有章可循的。结合我们自己的产品经验，来说一说要构建一个编排框架要做些什么事儿，这里不可能覆盖所有的细节，所讲的都是个人认为比较重要的。

服务都微了，编排怎么整？
编排包含3个基本的活动模型（赋值、invoke（调用）、空）和5个基本的控制模型（顺序、分支、异常抛出、异常捕获、并行）。

当然很多编排框架提供了更多方便的活动，比如普元的编排框架提供了本地调用、rest调用、webservice调用等活动，从而在使用上更加的方便。

有了这些基本的模型，我们就能方便的编排出复杂的业务流程。

作为一个老师傅，在invoke的时候我们知道有同步和异步的区别，同步实现起来简单，但是在多级级联编排的时候要避免因为某个服务的长响应时间导致雪崩效应，一般可以通过设置合理的超时事件和服务熔断策略来避免；同样在异步调用的时候，应该能自动缓存上下文和避免缓存爆掉，能自动建立异步响应和请求之间的关联。

同样提到并行也必须考虑不同的聚合方式，部分聚合？全部聚合？

流程编排完成之后也仅仅是走完了第一步，我们还需要给每个被编的服务提供正确的参数，是一个适配的过程。

服务都微了，编排怎么整？
一个编排服务（abcd）由a、b、c、d服务编排而成，每个服务都会有自己的出参入参。适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中。

服务都微了，编排怎么整？
编排服务执行到不同阶段，组成上下文的模型也是不一样的。从最初服务的开始执行的时候，上下文中只有系统级的参数和入参（请求报文）。到执行完一个被编服务后上下问就会增加这个被编服务的出参（响应报文），执行上下文是一个不断增大的过程。