监控近期同事Spring微服务技术架构网上APP应用出现服务拥堵、服务运行(业务进度)、需求变更困难、维护成本高等情况，回顾以往数据不一致等情况
1 .什么是微服务？ Wikipedia将其定义为面向服务的体系结构(SOA )的一种软件开发技术变体，它将APP应用程序构建为一组松散耦合的服务。 在微服务架构中，服务是细粒度的，协议是轻量级的。
微服务(或微服务体系结构)是云的本机体系结构方法，单个APP应用程序由许多小组件或服务组成，可以通过松散耦合独立部署。
微服务体系结构继承了服务体系结构，对单APP应用(monolith application )，其结构主要通过多层体系结构完成业务。 下图显示了典型的微服务技术体系结构。
该体系结构便于支持特定的业务，但遇到企业内的全生产流程、信息孤岛、数据管理等需求时，需要大量复杂的开发工作。 因此，我们将回到企业级服务架构。
2 .流程编排和服务编排对于服务编排和流程编排这两个概念，我们往往没有刻意加以区分，只是结合具体使用场合有个人的理解。 严密地组织服务应该是流程组织的子集，同时服务组织的设计类似于更多的组合服务。 流程组织旨在实现完整的业务流程自动化。
可以看到，完整的过程涉及的节点元素比服务组织更多。 例如，人工处理节点、通知类节点、规则处理和规则引擎、进程的串并回滚等处理等，往往不会出现在单纯的服务器组织中。 另一方面，服务编排是多个服务的组合，可以是串行组合，也可以是并行组合，形成新的组合服务能力。
说到流程组织，一般是指BPM业务流程管理、BPEL业务流程执行语言和建模设计器。 同时，我们也发现流程编排最终完成的是过程。 为了能够利用最终实现的流程，还经常涉及到设计具体的业务对象文档、设计前端接口的表示层等一系列工作。 只有这样，才能完成完整的业务人员可用的流程。 流程组织的结果可能是API服务接口或流程模板ID，但服务组织最终将是新的API服务接口，最终用户也将是开发人员，而不是用户。
无论是流程编制还是服务编制都可以看出，具备基本的流程定义、任务定义、连接定义、流程启动和任务日程监视等基础能力。 实现监控能力，以便在运行时动态、端到端地可视化组织的服务和流程。 流程启动后，可以访问监视界面来监视和调度控制流程的执行。
另一个是纯任务组织或调度系统，我们希望把多个工作任务连接起来形成一个任务链有序运行。 无论是DevOps内的配置流水线，还是运维工作内的多级自动化运维都满足了上述特点，实现这种任务调度系统也具备了流程定义、任务定义、任务调度监控等能力。 但是，实际的任务活动节点只是触发外部的脚本和接口，本身不是原子服务节点，不能说是组装服务之间的时间映射等复杂功能。
3 .微服务编排方式目前有三种常见的微服务编排方式，可以实现微服务的组合与协调，并根据开发项目的实际情况进行选择。
3.1. Orchestration (创建) Orchestration面向可执行进程，通过一个可执行进程与内部和外部服务交互，并在整个进程中控制目标、相关操作、服务调用顺序。
Orchestration与BPM、ESB的思想很相似，首先是流程控制服务，该服务接收请求，按照业务逻辑规则依次调用各个微服务，最终完成处理逻辑控制服务器可以看作BPM、ESB引擎、微服务器可以看作BPM、ESB的各种组件。
Orchestration的实现方案大多是同步的。
好处：
过程控制服务始终知道所有业务都进展到了什么程度，监控业务已经是一件相对简单的事情。
坏处：
1 )过程控制服务对业务逻辑控制过度，耦合过高，容易臃肿。
2 )单个微服务器退化为单纯的增删重审，失去自身价值。
上图所示的某商用微服务平台采用流程服务方式创建服务，提供服务运行监控能力。
3.2. Choreography (编排Choreography是面向合作的)通过消息的交互序列控制各部分资源的交互，参与交互的资源都是对等的，没有集中控制。
Choreography可以看作是一种消息驱动型，也可以看作是订阅/发布型，各业务到达后，监听各变更事件的服务可以自行获取、处理消息，并在需要时发布自己的消息不同的队列可以视为不同类型的消息，微服务器可以视为消息处理函数。
Choreography的实现方案往往是异步的。
好处：
结合度低，各项服务都能各尽其职。
坏处：
1 )业务流程采用subscription方式实现，难以直接监控每项业务的处理，因此很难调试。
2 )由于流程未事先定义，很难保证流程的准确性，基本上通过事后分析数据进行判断。
3 )一个业务流程被编入多个服务时，很难维护。
建议：
1 )小粒度的服务需要组合，服务粒度越小越需要组合。
2 )增加相应的监控系统，保证业务顺利进行。
p> 3.3. API网关API网关可以看作一种简单的接口聚合/拆分的方式：每笔业务到来后先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果。
API网关其实就是一个适配网关，比如对于Web端，可以一个页面同时发起几十个请求，而对于移动端，最好是一个页面就几个请求。而采用API网关，后面的微服务可以是相同的。
优点：
对外接口相对稳定。
缺点：
只适合业务逻辑较为简单的场景，业务逻辑过于复杂时，网关接口耦合度及复杂度会急剧升高，变得臃肿。
1、基本平台。数据存取方面的技术组件包括：缓存服务有JFS/Jimstore、图片服务JSS、即时服务JDW、索引服务Search、数据库服务DBS。
2、集成层。服务流程引擎PAF、服务中间件SAF、MQ服务JDMQ、数据库中间件JDAL、调度服务JDWorker、业务规则服务JDRules、配置服务JDCenter、推送服务JMP。
3、质量层。监控服务UMP、日志服务Loghub、风控系统JDriskM、应用管理jdcenter。
其它还包括治理层、虚拟平台、运营管理等等。
所谓的业务中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能最大程度地提升协作效率。
集中管控，分布式执行，构建业务中台的基共享服务体系：
回归SOA的本质一服务重用服务需要不断的业务滋养共享服务体系是培育业务创新的土壤赋予业务快速创新和试错能力为真正发挥大数据威力做好储备改变组织阵型会带来组织效能的提升 4.3. 人工智能中台我们可以把人工智能中台看成是基于 IaaS 基础上的人工智能 PaaS 平台。在人工智能中台上灵活搭建各种人工智能基础服务，如人脸识别算法能力、语义识别算法能力、语音合成算法能力、布局决策能力等。然后在这些基础人工智能能力之上，进行服务编排和组织，就可以形成语音转文本、文本转语音、智能推荐等带有业务色彩的人工智能服务。包装和组织这些带有业务色彩的人工智能服务，最后就能包装出各种垂直的人工智能解决方案。从 IaaS 到人工智能统一门户这几个层次，我们统称为人工智能中台。
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