『李越Java』微服务进行编排来确定组合调用分析


微服务进行编排来确定组合调用分析一、 背景说明
对比于传统的单体架构 , 微服务下的架构必须通过各微服务之间的协作来进行一整套业务流程 , 为了解决这个问题 , 市面上有很多微服务编排框架来解决这一问题 。 比如基于docker的为服务容器化与编排 , 通过网关做服务编排 , 以及Netflix开源的微服务编排引擎Conductor , 类似于BPM的Zeebe微服务编排的开源工作流引擎 。
本文不会讨论具体的编排框架技术 , 只从技术分析上进行一定的引导 。 二、编制与编排
编制的概念 , 如图:
『李越Java』微服务进行编排来确定组合调用分析
本文插图
编制的概念是Orchestration , 本来含义是进行乐队的指挥协同 , 乐队让统一的指挥来进行指挥以及控制 。
编排的概念 , 如图:
『李越Java』微服务进行编排来确定组合调用分析
本文插图
编排本来是用来进行舞蹈编舞 , 舞蹈演员来进行对外部的感应进行响应 , 例如对于音乐的响应 , 并且必须和舞伴的行动和表情来进行配合 。
这编制和编排用于微服务 , 也有类似的含义:
『李越Java』微服务进行编排来确定组合调用分析
本文插图
微服务的编制说明的是采用可执行的中心流程协同内部与外部的服务交互 。 通过中心流程控制总体的目标 , 必要的操作 , 以及服务之间的调用顺序 。
微服务的编排说明的是协作 , 采用消息的互相交互的一个序列来进行控制各个部分资源的一个交互逻辑 。 采用交互的资源都是对等的 , 没有进行集中的控制 。
降到微服务之间的一个技术细节 , 避免不了下面的一些概念 , 首先分成几类:
(1)与外部有关的概念:注册、发现、监控(可以没有)
(2)与本身有关的概念:熔断、限流、降级、超时、重试、幂等(部分可以没有)
(3)与组合有关的概念:最终一致性、分布式事务、CAP、BASE、补偿、分布式锁
我们通过业务逻辑的交互式分析:我们目前没有注册、发现 , 不需要熔断、限流、降级 , 应用之间可能含有重试、幂等等要求 。
应用之间通用的互相关联的一些关系 , 总共必须2种原因 。 中间环节可以被中断 , 比如账户钱不够就中断到哪个状态 。 重新再支付再运行 。 因此这样也没有自动重试 , 用户可以进行参与 。 也有的应用之间可以是强关联的一些关系 , 订单支付成功和账户之间的金额会发生极大的变化 , 这里面两者必须通过最终一致 , 重试与幂等 , 中间不可能产生其他用户来进行参加的操作 。 对于用户来说 , 要么可以成功 , 要么进行失败 , 用户并不能知道中间的一个什么状态 。
再比如2个应用之间是弱关系 , 其中一个应用处于宕机 , 既然有用户来参与 , 所以不需要维护一致性的 。 如果后面是强关联关系 , 是必须来维护一致性的(自动或者人工后台来干预) 。 三、编排服务的适配
我们进行编排服务 , 整个流程编排完成之后 , 下一步就要进行适配了:
『李越Java』微服务进行编排来确定组合调用分析
本文插图
一个编排服务由a、b、c、d四个服务来进行编排而成 , 每个服务都会有自己的出参入参 , 适 配的环节就是在上下文中给入参赋值并将出参的结果写入上下文中:
『李越Java』微服务进行编排来确定组合调用分析
本文插图
编排服务执行到不同的阶段 , 组成上下文的模型也是不一样的 。 在最初的服务开始的时候 , 上下文中仅有系统级的参数和入参 。 在进行一个被编服务后上下文就会增加这个被编服务的出参 , 执行上下文是一个不断增大的过程 。


推荐阅读