對微服務實現工作流自動化的一些注意點

banq發表於2018-11-18
微服務

您的公司可能希望採用微服務架構並應用工作流自動化。我在這篇部落格文章中沒有深入探討一些注意點：
您會遇到以下問題：
  • 範圍和邊界（“您希望自動化什麼工作流程以及如何將其對映到您的環境中的多個微服務或有界上下文”）。
  • 堆疊和工具（“我可以使用哪種工作流引擎？”）
  • 架構（“我是否將工作流引擎集中或分散？”）
  • 治理（“誰擁有工作流模型以及如何部署？”）
  • 操作（“我如何控制？”）

在這篇博文中，我給出了一些關於你必須做出的核心架構決策的指導。我將提供簡化的答案，以幫助您開始並獲得關於這個複雜主題的第一個方向。
由於所有理論都是灰色的，我想使用易於理解和遵循的具體業務示例來討論某些方面。使用這個我按順序檢查以下幾個方面：
  • 跟蹤或管理  - 編排或編排？
  • 3通訊備選方案：使用命令和事件的非同步通訊，RPC-ish點對點通訊，使用工作流引擎的工作分配
  • 中央或分散的工作流引擎
  • 工作流模型的所有權


案例
我在本文中使用的示例是一個簡單的訂單履行應用程式，可作為在GitHub上使用原始碼的流動零售示例應用程式。流動零售的一個很酷的事情是，它實現了不同的架構選擇，並提供不同程式語言的樣本。所有示例都使用工作流引擎，Camunda BPM或Zeebe。

跟蹤還是管理？orchestration 或choreography？
是orchestration 還是choreography？後者通常被視為更好的選擇（基於Martin Fowler的微服務文章）。這通常與事件驅動的體系結構相結合。
在這樣一個精心設計的架構中，您會發出某些所謂的域事件，每個感興趣的人都可以對這些事件採取行動。這是一個廣播。這個想法是你可以簡單地新增新的微服務來監聽事件而不改變任何其他事情。這樣的工作流程無處可見。
但隨著一系列事件被髮送而演變，危險在於你忽略了更大規模的流量，在我們的例子中是訂單履行。

跟蹤
一個簡單的解決方法是至少跟蹤事件流。根據具體的技術架構，您可能只需新增一個工作流引擎來讀取所有事件，並檢查它們是否可以與跟蹤流相關聯。
Flowing-retail顯示了使用Kafka和Kafka-Connect的實現示例：

https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/choreography-alternative/zeebe-track 和https://github.com/berndruecker/kafka-connect-zeebe.

管理journey 
這是非侵入性的，因為您不必更改架構中的任何內容。但它可以讓您立即開始做事，通常，這會導致從簡單跟蹤流程到真正管理流程的過程。

orchestration 或choreography
良好的架構通常是orchestration 和choreography的混合體。公平地說，沒有一些經驗就很難平衡這兩種力量。但我們看到很多證據表明這是正確的方法，所以絕對值得投入時間。（banq注：混合使用帶來複雜性）

工作流引擎的作用 - 三種架構替代方案
如何使用工作流引擎建立架構以實現這種平衡？可以替代下面三種架構：

  • 透過命令和事件進行非同步通訊（通常使用訊息或事件匯流排）
  • 請求/響應（通常是REST）的點對點通訊
  • 按工作流引擎分配工作到微服務


透過匯流排ESB實現命令和事件進行非同步通訊
該架構依賴於用於非同步通訊的中央匯流排。不同的微服務連線到該匯流排。編排邏輯和相應的編排流程由微服務擁有。工作流程可以向匯流排傳送新命令（“嘿付款，請為我取回一些錢”）或等待事件發生（“誰有興趣，我查到了O42的付款”）。

  • 典型匯流排ESB工具：Kafka，RabbitMQ（AMQP），JMS。 
  • 工作流引擎的作用：超時處理，管理活動鏈/流，支援有狀態的企業整合模式，如聚合器或重定序器，一致性和補償處理，又稱Saga模式
  • 實現示例：https：//github.com/berndruecker/flowing-retail/tree/master/kafka/java
  • 優點：微服務的時間解耦; 適用的事件驅動架構可以減少耦合; 許多失敗場景（例如缺少的響應訊息）對開發人員是透明的，因此他正確地考慮了這些情況。
  • 缺點：需要訊息或事件匯流排作為中心元件，這不容易操作。大多數開發人員對非同步通訊並不熟悉。


透過請求/響應進行點對點通訊
在這種架構中，您只需主動呼叫其他微服務，最常見的是以同步阻塞方式。最常見的方法是REST。通常從登錄檔中檢索端點。工作流引擎可以協調REST呼叫，也可以幫助解決遠端通訊的挑戰：



根據工作流引擎分配工作驅動微服務

在這種架構中，工作流在微服務之間分配工作，這意味著它本身就成為某種匯流排。微服務可以訂閱工作流的某些工作，並透過某種佇列獲取任務。 

  • 典型工具：外部任務（Camunda BPM）或Workers（Zeebe）。
  • 工作流引擎的作用：溝通渠道，超時處理，管理活動鏈/流程，一致性和補償處理。
  • 實現示例：https：//github.com/berndruecker/flowing-retail/tree/master/zeebe
  • 優點：易於設定; 良好的操作工具。
  • 缺點：工作流引擎成為架構的核心部分，需要適當地執行; 僅透過工作流程在微服務之間進行通訊 - 或者需要建立第二種通訊方式（例如REST或訊息傳遞）。


結論
如果客戶對Kafka或Messaging沒有任何經驗，那麼很難在旅途中確定這一點。因此，他們可能更善於使用基於REST的架構，特別是如果他們深入瞭解Spring Boot和Spring Cloud，那麼一些挑戰就相對容易解決。
如果客戶已經接受了域驅動設計（DDD）和事件，甚至利用了像Akka或Axon這樣的框架，那麼包含工作流引擎的事件驅動方法可能是最佳選擇。
（banq注：基於EventSourcing的工作流引擎目前還沒有，建議自己實現，參考：

從微服務到工作流：Jet訂單系統演變過程分享，另外該文提到將工作流引擎納入微服務內部，那麼微服務就不是微服務了，而是單體服務了，因為其內部包含了一個複雜的流程。）

相關文章