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

 

 

目录：

1. 编制、编排傻傻分不清楚

2. “编排”的关键在于流程+适配

3. “编排”中的分布式事务应知足最终一致性

4. “编排”须要更友好的运维工具支撑

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

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

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

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

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

编制的英文是Orchestration，本意是乐队指挥，在演出的时候，乐队由指挥来统一的进行指挥和控制。

编排的英文是Choreography，本意是舞蹈编舞，舞蹈表演一般是舞蹈演员对外部感应做出响应，好比音乐的响应，而且须要与舞伴的行动和表情进行配合。

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

微服务的编制强调的是经过一个可执行的中心流程来协同内部及外部的服务交互。经过中心流程来控制整体的目标，涉及的操做，服务调用顺序。

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

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

编制(Orchestration)就好像交通讯号灯，控制着车辆何时能够通行。而编排(Choreography)就好像是环岛，没有集中的控制，只有一系列的规则来指明车辆在接近十字路口的时候必需要等待，直到有空间进入环岛环绕系统，而后寻找适当的时候离开。

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

编排使一个业务流程会嵌入到多个服务中，维护会困难重重。

编排的对等特色，使得两端的服务强耦合，将表现为很难适应需求的变化。

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

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

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

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

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

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

编排包含3个基本的活动模型(赋值、invoke(调用)、空)和5个基本的控制模型(顺序、分支、异常抛出、异常捕获、并行)。

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

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

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

一样提到并行也必须考虑不一样的聚合方式，部分聚合?所有聚合?

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

一个编排服务(abcd)由a、b、c、d服务编排而成，每一个服务都会有本身的出参入参。适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中。 

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

因此适配不只仅存在与编排服务的入参和被编服务的入参之间，还存在于被编服务和在其以前的服务出参之间。 

最直接的莫过于依靠咱们勤劳的双手，完成点到点的映射赋值。只是吧，“勤劳”完了也是没有什么成就感的。

固然，咱们做为老师傅仍是有一些过人之处的，咱们有一种解放双手的武器。 

这个武器就是元数据，咱们经过使用元数据对全部的出参和入参标记着色，而后就能够自动完成一样颜色之间的自动映射。 

以前说到执行上下文的组成模型的时候还包括一个框架产生的部分，这一部分数据主要是流水号(id)和安全方面的考量。按照《基于微服务的企业应用架构设计范式》流水号的生成应该遵循GAIR模式。

globalId: 全局流水号，若是请求中的globalId为空，则编排服务生成;不然保持不变。

answerId: 响应流水号，服务提供者生成;能够做为提供者受理的凭证

inRequestId: 前台流水号，由前台生成

requestId: 请求流水号，编排服务的协调器生成;生成规则由服务提供者定义

能编排流程，能适配参数，这个编排框架已经具有运行的能力，后面咱们要考虑的就是事务的一致性问题。

3、“编排”中的分布式事务应知足最终一致性

依据CAP理论，必须在可用性(availability)和一致性(consistency)之间作出选择。若是选择提供一致性须要付出在知足一致性以前阻塞其余并发访问的代价。这可能持续一个不肯定的时间，尤为是在系统已经表现出高延迟时或者网络故障致使失去链接时。

依据目前的成功经验，可用性通常是更好的选择，可是在服务和数据库之间维护数据一致性是很是根本的需求，咱们的编排框架应该选择知足最终一致性。补偿模式就是就是一种很好的实现最终一致性的途径。 

咱们经过一个实例来讲明补偿模式，一家旅行公司提供预订行程的业务，能够经过公司的网站提早预订飞机票、火车票、酒店等。

假设一位客户规划的行程是，(1)上海-北京6月19日9点的某某航班，(2)某某酒店住宿3晚，(3)北京-上海6月22日17点火车。在客户提交行程后，旅行公司的预订行程业务按顺序串行的调用航班预订服务、酒店预订服务、火车预订服务。最后的火车预订服务成功后整个预订业务才算完成。

若是火车票预订服务没有调用成功，那么以前预订的航班、酒店都得取消。取消以前预订的酒店、航班即为补偿过程。

在补偿模式中，咱们要求参与补偿的微服务必须提供补偿操做，而且补偿操做必须是幂等的。补偿框架能够在异常时自动调用补偿操做完成补偿。

如今restful做为一个轻量级的rpc协议已经被普遍采用，能不能很好的支持restful服务的事务一致性也是衡量一个编排框架的是否成熟的一个标准。咱们公司的王博士设计了一套restful扩展规范来支持补偿模式的事务一致性。 

经过PATCH的HTTP Method来表示compensation操做，而且支持经过服务来查询编排服务执行的状态。

再说一个常见的坑： 

因为是经过rpc的调用，由于网络和调度的关系，可能出现补偿请求比原交易先到达的状况。这会致使补偿操做直接会失败，由于此时原交易还没有发生;最终原交易到达时会被成功的执行，最终就致使了事务不一致。

填这个坑的办法就是在编排框架发现补偿操做补偿的原交易不存在时，补记录一条原交易的流水，从而保证原交易晚到时会由于记录流水失败而不会成功。

关于事务一致性的更多内容能够参考以前的关于数据一致性的分享： 
《微服务架构下的数据一致性保证（一）》 
《微服务架构下的数据一致性保证（二）》 
《微服务架构下的数据一致性保证（三）》

4、“编排”须要更友好的运维工具支撑

在生产环境中，咱们须要经过查看日志来排除故障，应该有支持日志全路径回放的工具，来帮助咱们快速定位故障。

另外我所讲的编排实际是编制，是一种集中式的控制，也就意味着若是被编排的服务有响应缓慢的状况，可能会影响到其余服务。这时候咱们须要更快的监控来帮助咱们发现这类服务，从而尽早优化。

5、总结

最后，总结一下，服务编排有两种：编排和编制。编制是集中式控制，编排强调的是协做。在扩展性上和工程化上编制在必定程度上更优于编排，在一个业务域内编制更适用，而编排更适用跨业务域的流程。

考虑到服务编排的复杂性，咱们不能彻底依靠经验丰富的老师傅，使用编排框架能大大提供生产力。构造一个编排框架至少要支持3+5模型，应该采用元数据着色来自动适配服务参数的方法，更进一步要考虑事务(分布式)一致性，补偿模式一般是一种很好的保证事务一致性的方法。

关于做者

田向阳

现任普元解决方案中心架构师。曾就任于神州数码主持研发新一代自主渠道主线、中间业务平台。金融领域技术高手，操做系统、编程原理爱好者，喜欢问为何的工程师。