最近，同事Spring微服务技术架构网上应用出现了服务堵塞，监控不到服务运行（业务进展情况），以及需求变更困难、维护成本高等情况，再回顾以前数据不一致等情况，通过讨论分析发现系统架构中没有使用流程方法的服务编排。

1. 什么是微服务？

维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。
微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

微服务架构继承了服务架构，是与单体应用（monolith application）相对的，其构成主要是通过多层架构完成业务，如下图所示典型微服务技术架构。

这种架构支撑完成某些具体业务还是很方便的，如果遇到企业内部全生产流程、信息孤岛、数据治理等需求时，就显得力不从心了，需要大量、复杂的开发工作。因此，又回到企业级服务体系架构。

2. 流程编排与服务编排

对于服务编排和流程编排这两个概念，很多时候我们并没有刻意的去区分，但是还是结合具体的使用场景做下个人的一些理解。严格来将服务编排应该是属于流程编排的一个子集，同时服务编排更多的有点类似于组合服务的设计。而流程编排则面向一个完整业务流程的自动化实现。

那么可以看到一个完整的流程里面涉及的节点要素就比服务编排要多的多。比如人工处理节点，通知类节点，规则处理或规则引擎，流程的串行并行回退等处理等，这些往往在简单的服务编排里面并不会出现。而服务编排更多就是多个服务的组合，可以是串行组合，也可以是并行组合，然后形成一个新的组合服务能力。

当说到流程编排的时候，一般都会说到BPM业务流程管理和BPEL业务流程执行语言和建模设计器，同时也可以看到流程编排往往最终完成的是一个流程，为了最终实现的流程可用，往往就还涉及到具体的业务对象单据的的设计，前端界面展现层设计等一系列的工作。只有这样才能够完成一个完整的业务人员可用的流程。流程编排完成的结果可以是一个API服务接口，也可以就是一个流程模版ID，而服务编排则最终形成的一定是一个新的API服务接口，最终的使用方也不是用户而是开发人员。

不论是流程编排还是服务编排可以看到，都具备了基本的流程定义，任务定义，连接定义，流程启动和任务调度监控等基础能力。以实现对于编排完成的服务或流程能够在运行的时候能够实现动态，端到端可视化监控能力。在一个流程启动后，我们就可以进入到监控界面对流程执行进行监控和调度控制。

还有一类就是纯粹的任务编排或调度系统，即我们希望将做的多项工作任务连接起来形成一个任务链条有序的执行，不管是DevOps里面的部署流水线，还是运维工作里面的多步骤自动化运维都符合上面的特征，这种任务调度系统的实现也具备了流程定义，任务定义，任务调度监控等能力。但是实际上的任务活动节点仅仅是触发外部的脚本或接口，其本身并不是一个原子服务节点，也谈不上编排服务间的时间映射等复杂功能。

3. 微服务编排方式

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

3.1. Orchestration（编制）

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

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

Orchestration实现方案多是同步的。

优点：
流程控制服务时时刻刻都知道每一笔业务究竟进行到了什么地步，监控业务成了相对简单的事情。
缺点：
1）流程控制服务很容易控制了太多的业务逻辑，耦合度过高，变得臃肿。
2）各个微服务退化为单纯的增删改查，失去自身价值。

如上图所示的某商用微服务平台，以流程服务方式编制服务，以及提供服务运行监控能力。

3.2. Choreography（编排）

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

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

Choreography实现方案多是异步的。

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

3.3. API网关

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

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

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

4. 案例分析

4.1. 京东商城技术架构总览

1、基本平台。数据存取方面的技术组件包括：缓存服务有JFS/Jimstore、图片服务JSS、即时服务JDW、索引服务Search、数据库服务DBS。

2、集成层。服务流程引擎PAF、服务中间件SAF、MQ服务JDMQ、数据库中间件JDAL、调度服务JDWorker、业务规则服务JDRules、配置服务JDCenter、推送服务JMP。

3、质量层。监控服务UMP、日志服务Loghub、风控系统JDriskM、应用管理jdcenter。

其它还包括治理层、虚拟平台、运营管理等等。

4.2. 阿里业务中台技术架构

所谓的业务中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能最大程度地提升协作效率。

集中管控，分布式执行，构建业务中台的基共享服务体系：

• 回归SOA的本质一服务重用
• 服务需要不断的业务滋养
• 共享服务体系是培育业务创新的土壤
• 赋予业务快速创新和试错能力
• 为真正发挥大数据威力做好储备
• 改变组织阵型会带来组织效能的提升

4.3. 人工智能中台

我们可以把人工智能中台看成是基于 IaaS 基础上的人工智能 PaaS 平台。在人工智能中台上灵活搭建各种人工智能基础服务，如人脸识别算法能力、语义识别算法能力、语音合成算法能力、布局决策能力等。然后在这些基础人工智能能力之上，进行服务编排和组织，就可以形成语音转文本、文本转语音、智能推荐等带有业务色彩的人工智能服务。包装和组织这些带有业务色彩的人工智能服务，最后就能包装出各种垂直的人工智能解决方案。从 IaaS 到人工智能统一门户这几个层次，我们统称为人工智能中台。

5. 微服务编排组件

1、zeebe-io/zeebe

Zeebe是一个用于微服务编排的工作流引擎。Zeebe是一个免费的、源代码可用的微服务编制工作流引擎，它提供：

• 对公司端到端的工作流状态的可见性，包括正在运行的工作流的数量、平均工作流持续时间、工作流中的当前错误，等等。
• 根据工作流的当前状态编制工作流;Zeebe将“命令”作为事件发布，可以由一个或多个微服务使用，确保工作流按照其定义进行。
• 监视超时或其他流程错误，以及配置错误处理路径的能力，例如有状态重试或向能够手动解决问题的团队升级，确保工作流始终按计划完成。

Zeebe被设计用来解决非常大规模的微服务编排问题，为了实现这一点，它提供:

• 横向可伸缩性，不依赖于外部数据库;相反，Zeebe直接将数据写入部署它的服务器上的文件系统，并且可以轻松地跨计算机集群分发处理，从而提供高吞吐量。
• 通过易于配置的复制机制实现容错，确保Zeebe可以从机器或软件故障中恢复，而不会造成数据丢失和最小的停机时间。
• 一种消息驱动的体系结构，其中所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导出到外部系统进行长期存储，以提供一个完整的工作流审计日志。
• 发布-订阅交互模型，它允许连接到Zeebe的微服务在提供处理反压力机制的同时保持高度的控制。
  在iso标准BPMN 2.0中建模的可视化工作流，使得技术和非技术涉众可以用一种公共语言协作进行工作流设计。
• 与语言无关的客户机模型，使得用组织用来构建微服务的几乎任何编程语言构建Zeebe客户机成为可能。
  
  2、netflix/conductor

来自netflix 的为微服务编排引擎，支持的功能很丰富，同时文档也比较全

Netflix Conductor开源微服务编排框架并不满足我们前面描述的微服务编排场景，如果要实现服务和服务之间的编排，实际上对该开源软件的定制和改造工作量相当大。因此在我们实现微服务编排的时候并不建议选择该开源软件。其次，在整个微服务架构体系中，也不建议采用Netflix Conductor，至少在前期的改造过程中使用的场景很小，完全可以用其他方式来替代。【12】

3、uber/cadence

Cadence 是 Uber 开发的一个分布式，可扩展，持久且高度可用的编排引擎，以可扩展和弹性的方式执行异步长期运行的业务逻辑。

业务逻辑被建模为工作流和活动。工作流程是协调逻辑的实现。其唯一目的是协调活动执行。活动是业务逻辑中特定任务的实现。工作流和活动实现在工作进程中托管和执行。这些工作人员长期轮询Cadence服务器以执行任务，通过调用工作流或活动实现来执行任务，并将任务结果返回给Cadence服务器。此外，工作人员可以实现为完全无状态的服务，这反过来允许无限制的水平扩展。

Cadence服务器代理并持久保存在工作流执行期间生成的任务和事件，这为工作流执行提供了某些可伸缩性和可靠性保证。单个活动执行不具有容错能力，因为它可能由于各种原因而失败。但是，确定在哪种顺序以及如何（位置，输入参数，超时等）活动被执行的工作流程保证在各种故障条件下继续执行。

其他还有Activiti、JBPM等，以及很多商用工作流或BPM标准的业务流程工具。

6. 总结

微服务做为服务架构家族的一员，是构建服务架构中一种方法，服务的粒度不仅仅是技术的问题，更多的是业务问题，我们需要把服务粒度放到全业务流程环境中去解耦，按业务流程解耦服务、编排服务，在数据隔离、服务隔离的条件下，还要避免产生新的信息孤岛，共享是未来的主题。

参考：

【1】ccww，微服务中的编排，具体指的是什么？ ，知乎，2019.11
【2】人月神话的博客，服务编排和流程编排(7.5)，新浪博客，2019.07
【3】沉落的星星，微服务核心研究之–编排 ，简书，2019.07
【4】rongfengliang-荣锋亮，几个微服务编排工具，博客园， 2019.02
【5】intelligentx，【BPM技术】Zeebe是一个用于微服务编排的工作流引擎，首席架构师，2020.06
【6】纯洁的微笑，一文读懂 Spring Boot、微服务架构和大数据治理三者之间的故事，2018.05
【7】鹿鸣天涯，淘宝技术架构变迁，CSDN博客，2019.07
【8】nicholas.wu，京东架构专家分享京东架构之路，CSDN博客，2018.04
【9】技术领导力，京东商城，超大型电商系统架构设计原则与实践！8页ppt详解，CSDN博客，2020.03
【10】火雨_Nick，淘宝网技术架构介绍，CSDN博客，2015.12
【11】博文视点Broadview，人工智能工程化丨中小企业AI中台落地指南，知乎，2020.10
【12】人月神话的博客，微服务编排NetflixConductor(7.4)，新浪博客，2019.07
【13】java圈，微服务编排引擎Cadence简介，CSDN博客，2020.11

cs