本文主要想談一談工作流在微服務系統中的使用以及工作流能夠為微服務系統帶來的好處。

    通過查詢資料可得，微服務的編排主要分為兩種形式，一種是“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）細化每一階段目標