微服務的流程編排將成為下一個要解決的大問題。在撰寫本文時，有幾種解決方案試圖在該領域競爭，主要是構建自己的（文字）領域特定語言來描述業務流程。在我看來，編排應該改為在BPMN 2.x中表達，因為它是為此目的而精心設計的，易於理解且成熟的語言。

類似於SOA的編排

SOA專注於圍繞業務功能構建的服務之間的遠端通訊。中央流程引擎同步地遠端呼叫分散式服務。整合在狀態處理過程引擎和無狀態服務之間執行。

此類同步系統有兩種不同的實現方式。

1. Connector聯結器風格的整合模式：如果處理引擎使用所選擇的協議（通常HTTP）直接呼叫服務（S1，S2，S3）。
2. RPC整合模式：如果引擎呼叫的本地代表這些裝置通過選擇的協議（HTTP，Java RMI的或任何其它同步協議）呼叫遠端服務（S1，S2，S3）。

在這兩種情況下，整合都需要引擎和服務同時線上。引擎可能知道服務的位置，或者使用登錄檔或代理（記住Webservice三角）來解決此問題，並且服務使用面向呼叫的實現來代表流程引擎執行工作。

訊息驅動編排

代替同步呼叫，中央引擎可以將訊息傳送到佇列或主題，而無狀態服務訂閱這些訊息。不需要同時提供引擎和服務。結果，服務使用面向訂閱的實現來代表流程引擎執行工作。

根據所使用的訊息傳遞抽象，有兩種實現型別：

1. 訊息傳遞基礎結構可能是提供佇列（Q1，Q2，Q3）概念的中介軟體（例如，使用中央訊息傳遞匯流排）。引擎使用佇列將非同步訊息傳送到服務（S1，S2，S3）。
2. 代替使用佇列，過程引擎可以將資訊釋出到預定義的主題（T1，T2，T3）。主題訂閱可以是流程引擎的一部分（也就是上面顯示的外部任務模式），也可以位於集中式訊息中介軟體上。

分散式編排

業務流程本身是分散式的。服務不會變為全狀態引擎和無狀態服務之間的分離，而是變為全狀態（並獲得自己的狀態處理方式，例如使用業務流程），並且在業務流程之間進行整合（例如，在流程引擎PE1，PE2，PE3中執行） ）。

Camunda BPM的外部任務模式

外部任務模式是Camunda BPM在7.4版中引入的，它是打破工作流整體走向分散式工作流編排的最重要功能之一。最初，它旨在提供與面向呼叫相反的面向訂閱的服務任務實現。也就是說，如果引擎執行服務任務，則它不是在呼叫委託來呼叫（遠端）服務，而是建立外部任務記錄，並等待（遠端）外部任務工作者獲取並執行它。

點選標題了解詳細。