微服务进行编排来确定组合调用分析
2020-03-02 03:04:22   来源：东方头条   

微服务进行编排来确定组合调用分析一、 背景说明

对比于传统的单体架构，微服务下的架构必须通过各微服务之间的协作来进行一整套业务流程，为了解决这个问题，市面上有很多微服务编排框架来解决这一问题。比如基于docker的为服务容器化与编排，通过网关做服务编排，以及Netflix开源的微服务编排引擎Conductor，类似于BPM的Zeebe微服务编排的开源工作流引擎。

本文不会讨论具体的编排框架技术，只从技术分析上进行一定的引导。二、编制与编排

编制的概念，如图:

编制的概念是Orchestration，本来含义是进行乐队的指挥协同，乐队让统一的指挥来进行指挥以及控制。

编排的概念，如图:

编排本来是用来进行舞蹈编舞，舞蹈演员来进行对外部的感应进行响应，例如对于音乐的响应，并且必须和舞伴的行动和表情来进行配合。

这编制和编排用于微服务，也有类似的含义:

微服务的编制说明的是采用可执行的中心流程协同内部与外部的服务交互。通过中心流程控制总体的目标，必要的操作，以及服务之间的调用顺序。

微服务的编排说明的是协作，采用消息的互相交互的一个序列来进行控制各个部分资源的一个交互逻辑。采用交互的资源都是对等的，没有进行集中的控制。

降到微服务之间的一个技术细节，避免不了下面的一些概念，首先分成几类:

(1)与外部有关的概念：注册、发现、监控（可以没有）

(2)与本身有关的概念：熔断、限流、降级、超时、重试、幂等（部分可以没有）

(3)与组合有关的概念：最终一致性、分布式事务、CAP、BASE、补偿、分布式锁

我们通过业务逻辑的交互式分析:我们目前没有注册、发现，不需要熔断、限流、降级，应用之间可能含有重试、幂等等要求。

应用之间通用的互相关联的一些关系，总共必须2种原因。中间环节可以被中断，比如账户钱不够就中断到哪个状态。重新再支付再运行。因此这样也没有自动重试，用户可以进行参与。也有的应用之间可以是强关联的一些关系，订单支付成功和账户之间的金额会发生极大的变化，这里面两者必须通过最终一致，重试与幂等，中间不可能产生其他用户来进行参加的操作。对于用户来说，要么可以成功，要么进行失败，用户并不能知道中间的一个什么状态。

再比如2个应用之间是弱关系，其中一个应用处于宕机，既然有用户来参与，所以不需要维护一致性的。如果后面是强关联关系，是必须来维护一致性的(自动或者人工后台来干预)。三、编排服务的适配

我们进行编排服务，整个流程编排完成之后，下一步就要进行适配了:

一个编排服务由a、b、c、d四个服务来进行编排而成，每个服务都会有自己的出参入参，适 配的环节就是在上下文中给入参赋值并将出参的结果写入上下文中:

编排服务执行到不同的阶段，组成上下文的模型也是不一样的。在最初的服务开始的时候，上下文中仅有系统级的参数和入参。在进行一个被编服务后上下文就会增加这个被编服务的出参，执行上下文是一个不断增大的过程。

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

最直接的方法是进行点对点的映射赋值。

我么可以通过元数据对所有的入参和出参标记着色，就可以完成同样颜色之间的自动映射。四、编排服务的一致性

编排在一起的服务，采用强组合。可能通过一些应用发起，对调用法只返回结果，内部来保证采用最终一致性。这里并没有中心，是完全去中心化的。并且这些强组合进一步编排成更大的弱业务流程，中间可以正常中断，此时就需要一个总控，来显示强组合的状态，这些状态的用户来介入的操作，将启动强组合的业务逻辑。

这样，我们要合理划分业务流程中的各服务之间的编排关系。数据库中主业务数据表的状态有一个总控状态，只记录在弱组合中的结果状态。服务强组合编排之间进行超时、重试，幂等，回退等，只有整体成功与失败。

服务会有一定的强组合，就是最终一致性，而整体的业务会串起单一的或者组合编排的服务。强组合内不存在用户可介入的分支(如果重试、超时、意外的不一致，由后台管理介入)。

我们的业务是整体的由中心控制的编制，与局部无中心化的编排的复杂的结合。五、总结

微服务之间是采用高内聚、低耦合的形式来设计的。高内聚的服务就应该采用编排，一致性，分布式锁等。而低耦合的微服务就是要进行编制。