從微服務遷移到工作流的經驗之談

Jet公司的訂單管理系統（OMS）負責處理很多業務功能，最初是由一系列微服務組成的。隨著公司的發展，這種架構所面臨的挑戰也越來越大，直到他們決定構建一個新的基於工作流的平臺。Jet工程師James Novino在一篇博文中介紹了舊系統面臨的挑戰、對新平臺的概述以及新平臺執行一年多後所總結的經驗。

OMS最初使用了釋出與訂閱、事件溯源和其他技術的組合。每個服務都使用相同的樣板實現，包含了三個步驟：

• 解碼——從輸入流中讀取領域事件，並將事件轉換為輸入型別。

• 處理——檢查輸入並獲取任何所需的資料。

• 解釋——執行副作用。

隨著公司的發展和需求的增長，架構的複雜性也在增加，使得維護系統變得更加困難。服務的數量也增加了，並且由於功能通常分佈在多個服務中，因此導致開發週期變得更長。Novino認為這是一個很複雜的過程，需要大量的樣板程式碼。他還指出，隨著系統的發展，構建和維護這種架構的複雜性對系統和團隊都帶來了負面影響。

因此，他們開始建立一個能夠以更有效的方式處理所有業務工作流的新平臺。他們決定設計和構建一個基於工作流的系統，其靈感來自Pat Helland和他的論文：Life Beyond Distributed Transactions。新系統的核心設計基於兩個保證：

• 冪等性——避免重複事件。

• 一致性——支援多個不同的儲存，但由於它們必須能夠讀取自己的寫入，因此儲存需要實現強一致性模型。

這些保證為系統帶來了多個特性，包括：

• 事件溯源——所有狀態變更都儲存在日記中。

• 簡單的實現，由工作流定義和相應的步驟組成。這樣有助於開發人員優先考慮業務流程並強制執行系統的模組化。

• 工作流的冪等性保證。

• 工作流版本控制，可以將變更部署到工作流中，而無需擔心當前正在執行的東西。

• 伸縮性——通過使用每個服務的多個例項，可以並行執行工作流。

Novino將新架構描述為其早期管道（解碼-\u0026gt;處理-\u0026gt;解釋）的抽象版本，並在每個操作之間具有明確的服務邊界：

• 工作流觸發器，對應於解碼；

• 工作流執行器，用於處理；

• 副作用執行器，相應的解釋。

為了定義工作流，他們建立了一個領域特定語言（DSL），用於定義所需的一系列執行步驟。他們還提供一個視覺化工具，可以顯示正在執行和已經執行過的工作流。

Novino指出，有一些現成的工作流編排和設計替代方案，但他們決定構建自己的方案，原因如下：

• 能夠為工作流事件維護單獨的資料儲存；

• 能夠在執行過程的任何時刻重放或視覺化狀態；

• 可擴充套件性和伸縮性。

在生產環境中執行了一年多後，它們建立了大約2200萬個日誌，完成了大約9300萬個工作流。

最後，Novino指出，從基於分散式微服務的架構遷移到基於工作流的架構，在設計、開發和支援過程中對其開銷產生了巨大影響。他還指出，使用DSL設計工作流並將其作為單個響應步驟實現的能力提高了他們構建複雜新系統的能力。在未來的文章中，他將更詳細地介紹他們的新設計。

檢視英文原文：https://www.infoq.com/news/2019/02/migrate-microservices-workflows