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

    通过查找资料可得，微服务的编排主要分为两种形式，一种是“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）细化每一阶段目标