微服务与工做流

     本文主要想谈一谈工做流在微服务系统中的使用以及工做流可以为微服务系统带来的好处。

    经过查找资料可得，微服务的编排主要分为两种形式，一种是“choreography”，有人将其翻译成微服务的编排；另外一种是“orchestration”,有人将其翻译成微服务的编制。二者的差别很简单，前者是点对点交互，没有一个中心流程来协同各服务的交互（服务注册不考虑在内），例如，如今的REST-API调用，dubbo框架、hsf框架都是基于此种设计模式；后者是基于总控系统，经过总控系统协调各服务的交互，例如，例如事件总线，消息队列等。其具体结构如图1.1所示。

                                      

                                                

                                                               图1.1 编排vs编制，来源: www.thoughtworks.com

   

   目前而言，"编排"风格的微服务架构设计有以下缺点：

    （1）"编排"使得一个业务流程分散到多个微服务中，这样使得整个流程不可见。

    （2）因为"编排"的点对点特性，使得两端的服务强耦合，于是很难适应需求的变化。

    但是，基于“编制”架构风格的设计也并不是银弹。虽然基于事件通知能够下降服务之间的耦合，而且处理起来很是简单。可是，基于消息命令，不易获命令背后的业务逻辑，所以这种方式也不易察觉出业务的流程。

    那么，该如何有效的察觉出业务的流程呢？我想，可使用基于“编制”风格的微服务+工做流。

    下面，以一个你们常见的场景进行描述：提交订单——>支付订单——>扣减库存——>派送商品——>交易完成。

    基于“编制”风格的事件流程处理如图1.2所示：

                                        

                                                                            图 1.2 基于“编制”风格的购买商品业务流程

 

 

      咱们将上述购买商品的业务流程构建成为工做流中的bpmn模型，具体如图1.3所示：

                                               

     经过在微服务编排中引入工做流引擎，经过工做流对分散于各微服务中的业务进行整体的控制，可得以下好处： 

    （1）可见性。经过可视化方式使不易肯定的业务流程变得清晰可见

    （2）状态处理。因为工做流可以存储每一个具体流程的状态，所以一个订单能够对应于一个流程实例

    （3）状态的透明化和可视化处理。经过可视化方式查看或者变动某一流程实例的状态。例如，将某一订单回退到上一个环节。

       

      接下来的工做：

    （1）实验论证其观点

    （2）细化每一阶段目标