微服务核心研究之--编排

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

一、微服务编排的必要性
二：3种常见的微服务编排方式
1、Orchestration（编制）
2、Choreography（编排）
3、API网关
三、微服务编排的框架（Orchestration方式）
1、流程编排的思路
2、流程编排的模型
3、适配参数
4、流水号
5、调用链分析
四、微服务编排的事务一致性
五、微服务编排的监控工具支撑

一、微服务编排的必要性

微服务是目前流行的一种新兴的软件架构风格，在微服务体系结构中，可以将应用分解为多个更小颗粒度的服务, 各个服务可以由不同的团队并行独立开发、部署。

以一个出租车调度软件为例，最开始是一个单体应用，应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。随着时间增加，功能逐渐增多，代码越来越多，这个软件就会越来越难维护。这时使用微服务架构就是不错的选择。一个微服务一般完成某个特定的功能，比如定单管理、客户管理等等。每一个微服务都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个微服务实例可能是一个Docker容器。

《The Art of Scalability》(中文书名：架构即未来) 一书介绍了一个应用横向扩展所需要遵守的AKF扩展模型。根据AKF扩展模型，横向扩展实际上包含了三个维度，而横向扩展解决方案则是这三个维度上所做工作的结合。X轴表示水平复制，Y轴表示应用功能拆解，Z轴表示按数据拆分。微服务架构模式对应于代表可扩展模型的Y轴。

二：3种常见的微服务编排方式
目前有3种常见的微服务编排方式，实现微服务的组合与协调，可根据开发项目的实际情况进行选择。

1、Orchestration（编制）
Orchestration面向可执行的流程：通过一个可执行的流程来协同内部及外部的服务交互，通过流程来控制总体的目标、涉及的操作、服务调用顺序。

Orchestration和BPM、ESB的思想很相似，首先要有一个流程控制服务，该服务接收请求，依照业务逻辑规则，依次调用各个微服务，并最终完成处理逻辑。可以把控制服务视作BPM、ESB引擎，微服务视作BPM、ESB的各种组件。

Orchestration实现方案多是同步的。

优点：
流程控制服务时时刻刻都知道每一笔业务究竟进行到了什么地步，监控业务成了相对简单的事情。
缺点：
1）流程控制服务很容易控制了太多的业务逻辑，耦合度过高，变得臃肿。

2）各个微服务退化为单纯的增删改查，失去自身价值。

2、Choreography（编排）
Choreography面向协作：通过消息的交互序列来控制各个部分资源的交互，参与交互的资源都是对等的，没有集中的控制。

Choreography可以看作一种消息驱动模式，或者说是订阅发布模式，每笔业务到来后，各个监听改事件的服务，会主动获取消息，处理，并可以按需发布自己的消息。可以把不同队列看作不同种类的消息，微服务看作消息处理函数。

Choreography实现方案多是异步的。
优点：
耦合度低，每个服务都可以各司其职。
缺点：
1）业务流程是通过订阅的方式来体现的，很难直接监控每笔业务的处理，因此难于调试。
2）由于没有预定义流程，所以很难在事前保证流程正确性，基本靠事后分析数据来判断。
3）当一个业务流程会嵌入到多个服务中时，维护会很困难。
建议：
1）小粒度的服务需要组合，服务的粒度越小，越需要组合。
2）增加相应的监控系统，来保证业务顺畅进行。

3、API网关

3、API网关
API网关可以看作一种简单的接口聚合/拆分的方式：每笔业务到来后先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果。

API网关其实就是一个适配网关，比如对于Web端，可以一个页面同时发起几十个请求，而对于移动端，最好是一个页面就几个请求。而采用API网关，后面的微服务可以是相同的。

优点：
对外接口相对稳定。
缺点：
只适合业务逻辑较为简单的场景，业务逻辑过于复杂时，网关接口耦合度及复杂度会急剧升高，变得臃肿。

三、微服务编排的框架（Orchestration方式）
对编排流程、适配参数、调用链分析等方面思路的考量，构成微服务编排的框架思路在invoke（调用）的时候我们知道有同步和异步的区别。同步实现起来简单，但是在多级级联编排的时候要避免因为某个服务的长响应时间导致雪崩效应，一般可以通过设置合理的超时时间限流和服务熔断策略来避免；同样，在异步调用的时候，应该能自动缓存上下文和避免缓存爆掉，能自动建立异步响应和请求之间的关联。同样，提到并行也必须考虑不同的聚合方式，比如是部分聚合还是全部聚合。（如下图）

2、编排流程的模型
活动模型。例如（赋值、invoke（调用）、空）
控制模型。例如（顺序、分支、循环、异常抛出、异常捕获、并行）
当然，有很多编排框架提供了更多方便的活动，比如普元的编排框架提供了本地调用、rest调用、webservice调用等活动，从而在使用上更加的方便，有了这些基本的模型，我们就能方便的编排出复杂的业务流程。（如下图）

3、适配参数
流程编排完成之后，我们还需要给每个被编的服务提供正确的参数，是一个适配的过程。
一个编排服务（abcd）由a、b、c、d服务编排而成，每个服务都会有自己的出参入参。适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中。（如下图）

小结

Jetty 代码的分析：

参考资料和推荐阅读

1.链接: 参考资料.