微服務的流程編排將成為下一個要解決的大問題。在撰寫本文時，有幾種解決方案試圖在該領域競爭，主要是構建自己的（文本）領域特定語言來描述業務流程。在我看來，編排應該改為在BPMN 2.x中表達，因為它是為此目的而精心設計的，易於理解且成熟的語言。
類似於SOA的編排
SOA專注於圍繞業務功能構建的服務之間的遠程通信。中央流程引擎同步地遠程調用分布式服務。集成在狀態處理過程引擎和無狀態服務之間執行。
此類同步系統有兩種不同的實現方式。
- Connector連接器風格的集成模式：如果處理引擎使用所選擇的協議（通常HTTP）直接調用服務（S1，S2，S3）。
- RPC集成模式：如果引擎調用的本地代表這些設備通過選擇的協議（HTTP，Java RMI的或任何其它同步協議）調用遠程服務（S1，S2，S3）。
在這兩種情況下，集成都需要引擎和服務同時在線。引擎可能知道服務的位置，或者使用註冊表或代理（記住 Webservice三角 ）來解決此問題，並且服務使用面向調用的實現來代表流程引擎執行工作。
消息驅動編排
代替同步調用，中央引擎可以將消息發送到隊列或主題，而無狀態服務訂閱這些消息。不需要同時提供引擎和服務。結果，服務使用面向訂閱的實現來代表流程引擎執行工作。
根據所使用的消息傳遞抽象，有兩種實現類型：
- 消息傳遞基礎結構可能是提供隊列（Q1，Q2，Q3）概念的中間件（例如，使用中央消息傳遞總線）。引擎使用隊列將異步消息發送到服務（S1，S2，S3）。
- 代替使用隊列，過程引擎可以將信息發布到預定義的主題（T1，T2，T3）。主題訂閱可以是流程引擎的一部分（也就是上面顯示的外部任務模式），也可以位於集中式消息中間件上。
分布式編排
業務流程本身是分布式的。服務不會變為全狀態引擎和無狀態服務之間的分離，而是變為全狀態（並獲得自己的狀態處理方式，例如使用業務流程），並且在業務流程之間進行集成（例如，在流程引擎PE1，PE2，PE3中運行） ）。
Camunda BPM的外部任務模式
外部任務模式是Camunda BPM在7.4版中引入的，它是打破工作流整體走向分布式工作流編排的最重要功能之一。最初，它旨在提供與面向調用相反的面向訂閱的服務任務實現。也就是說，如果引擎執行服務任務，則它不是在調用委託來調用（遠程）服務，而是創建外部任務記錄，並等待（遠程）外部任務工作者獲取並執行它。
end：如果你覺得本文對你有幫助的話，記得關注點贊轉發，你的支持就是我更新動力。