微服務交易資料務求一致　編排機制演進迎刃而解(下)

上集文章探討了「微服務」實際運作時可能遭遇到諸多難題，並且說明了「傳統式交易」與「分散式交易」實務操作上所須解決的問題環節。延續相同主題，此下集文章將正式進入「服務編排」的介紹，透過圖文說明如何應對傳統「微服務」帶來的混亂。

微服務編排技術

對於簡單流程的編排案例，仍可以在程式碼中實作微服務編排，但是若涉及到狀態持久性、流程定義語言和流程分析等功能，就應該考慮採用框架或平台。目前開源或提供原始碼的微服務編排框架，包括Cadence（來自Uber，https://cadenceworkflow.io/）、Conductor（來自Netflix，https://conductor.netflix.com/）以及Zeebe（來自Camunda，https://camunda.com/platform/zeebe/）等，這些工具提供可擴展的編排框架，雖然簡化了微服務編排的實作，節省時間並降低風險，但隨之而來有安裝和管理編排元件或服務的額外工作。

除了自行安裝和管理編排框架之外，還可以使用微服務編排平台即服務（PaaS)，例如AWS Step Functions、Azure Durable Functions、Camunda Cloud、Orkes（Conductor商用版，https://orkes.io/）或Temporal（Cadence商用版，https://temporal.io/），使用編排PaaS平台可以避免複雜的安裝過程和維運管理的基礎工作，但可能會有網路延遲，並且完全倚賴PaaS雲供應商的穩定性。而微服務編排框架和平台的優勢包括：

‧針對現代化雲原生環境進行優化，例如容器和雲平台，支援部署多個微服務。

‧能夠處理高並發和高負載的流程使用量。

‧使用分散式資料庫來儲存，可最大幅度地減少狀態持久化所造成的效能瓶頸。

‧主要針對應用程式開發人員進行產品設計和優化，而不是業務分析設計人員或系統整合專家。

目前微服務編排框架的主要差異是規劃業務流程的設計方式，例如Zeebe使用BPMN 2.0，Cadence是使用Workflows DSL，而Conductor則提供基於JSON的定義函式庫。使用編排框架的目的是簡化和加速微服務編排開發設計的過程，所以需要將流程定義語言與業務分析師和開發人員的技能和偏好相匹配，如果微服務開發人員習慣使用Go語言，可能會發現他們更偏好Cadence或Temporal。但是，如果開發團隊主要使用Java語言，並且團隊成員包括業務分析師，傾向在實作服務編排之前先擬定流程圖，那Zeebe可能是更好的選擇。

Saga設計模式是目前普遍主流的微服務編排模式，可用來控制協調多組服務，以確保實現業務流程的一致性，Saga通常用來當作分散式交易的替代方案，因為主流的微服務框架和平台多數不支援兩階段提交，且Saga模式讓人們重新思考微服務編排中使用ACID和分散式一致性的必要性，因為在微服務編排技術尚未成熟前，開發微服務都是透過資料庫的交易一致性功能來實現，也造成資料庫效能及耦合問題，而兩階段提交也有交易阻塞和效能瓶頸的問題，故微服務設計就引入DDD（Domain-Driven Design）的設計方法，其中就包括重新審視業務流程，改用最終一致性來解決多個服務資料同步和狀態一致性問題，如圖1所示。

其實不單單只有微服務會遇到多個服務協調業務一致性問題，如上集文章中所示的電商購物結帳流程，旅行社線上訂房訂票預約系統都無法採用強一致性方式來實作，因爲很多服務都是外部供應商或合作夥伴的系統，除了無法直接存取資料庫，更無法保證外部服務的回應時間，2PC分散式交易容易造成延遲等待和死鎖問題，所以採用基於補償的Saga設計模式才能解決外部和雲服務、同質或異質資料庫的資料一致性。但Saga畢竟只是設計模式，實作仍須透過編排框架或平台，否則光是設計整個流程控制及觸發補償交易回溯資料（如圖2右邊顯示庫存、付款和回饋金補償回溯步驟）就耗費大量人力時間，早已無暇實作具業務價值的細部服務邏輯，因此導入支援Saga模式的服務編排技術是微服務能否平穩開發的成功關鍵，微服務編排控制API呼叫流程的示意圖如圖3所示。

新式BPM流程引擎

前面已介紹多種編排技術，經筆者研究評估後（表1），認為企業已廣泛使用的業務流程引擎（BPM Process Engine）是可以實現Saga設計模式，尤其是新一代BPM平台都支援BPMN 2.0圖形化流程設計，允許非開發人員（業務分析師）自行規劃設計業務流程，開發人員則專注在業務流程中的子任務模組實作，並透過端到端的流程藍圖來快速對焦業務流程設計和微服務串接驗證，而且在歐萊禮《Building Microservices, 2nd Edition》一書中（中文版，建構微服務｜設計細微化的系統 第二版），第六章工作流程中就提到BPM在微服務編排的應用方式，且實際上，流程編排就是BPM主要的使用情境。

在BPMN 2.0的流程設計，定義了四大組成元素，包括事件、閘道、活動和連接（圖4），詳細的BPMN使用及設計方式，將在之後的技術文章說明。BA/SA依照業務需求設計數位產品流程，完成後就可透過建模工具來模擬流程，確認每項業務情境是否都有涵蓋到，並且流程規則都是正確無誤，完成後就由開發人員接手設計每個活動的串接服務（微服務），而最關鍵的Saga設計模式，直接透過BPMN流程設計就可完成，因本身就有定義補償事件，只要有一個微服務發生錯誤，回覆給流程引擎就會觸發補償流程。

如圖5所示的旅行社自由行預約流程，活動一、預定汽車，活動二、預定旅館，活動三、訂機票，當其中一個服務發生錯誤時，下方閃電圖示的錯誤事件，就會觸發倒帶圖示的補償事件，所有預訂服務就開始實行取消任務，詳細實作內容，請參考Bernd Rücker（Camunda共同創辦人）的Github專案（https://github.com/berndruecker/trip-booking-saga-java）。

結語

微服務架構的最常見問題是每個服務開發團隊只專注於自己負責的服務，卻沒有人了解或熟悉端到端的業務流程，這會導致無法評估流程異動影響的範圍，流程修改所需的人力時間成本，也很難針對特定流程來進行測試和驗證。

實作編排流程本身就是一個API組合服務，如果遵循微服務設計原則，這API組合也會是一個微服務，這意味著編排流程服務有本身的開發生命週期、產品負責團隊和開發工作清單Backlog，並不是先完成底層微服務後才著手開發組裝，所以微服務編排框架或平台就會由這編排服務團隊來負責端到端流程的設計，包括跨單位流程定義和測試、流程更新和維護，以及在營運環境中解決與流程相關的疑難雜症，全由特定開發團隊負責，這就是中台開發團隊和中台架構策略。

使用微服務編排技術可帶來以下優點：

‧集中透明可視的流程定義、狀態和運作指標：編排框架可以擷取每個執行中的流程實例內的詳細訊息，並用於分析，這提供你回答有關特定流程的現況問題，如「某客戶訂單跑到哪個步驟？」，以及業務分析查詢，如「過去7天內新訂單的峰值是在何時？」。

‧與公司整體工作流程優化策略對齊：透過將應用系統程式建模成可視化流程圖，可以更輕鬆地了解微服務應用系統如何適應更高層次的企業業務流程，將多個微服務視為一套流程或軟體專案，可提升微服務設計在業務價值鏈中的定位和視野，在流程優化方面提供服務共用或服務拆分的依據。

‧雲原生服務編排的可擴展性：微服務編排框架針對各種公有雲SaaS服務和跨系統的流程狀態一致性和編排設計進行了大量優化。

‧以開發人員為中心的開發流程：微服務編排技術是專為開發人員使用所設計，適合現代化的軟體開發方法，包括持續整合╱持續交付（CI/CD）以及測試和部署自動化。

而採用微服務編排技術的缺點是：

‧建構和營運環境維護的必要成本：流程設計建置和後續管理會帶來無法避免的日常維運工作，如果只有編排設計少量流程，則不敷成本。

‧需要投入時間來學習使用和建置營運環境：必須具備微服務編排技術的開發設計知識，並花時間研究如何與目前營運環境整合，多數開源專案缺乏這些說明文件，以及維持穩定運行或企業等級安全性的支援服務。

‧編排技術仍在快速變化、尚未穩定：編排技術仍處於百家爭鳴的時期，使用情況及受歡迎程度正在變化，新一代編排框架可能會出現，提供更流暢的開發和操作體驗，目前Netflix Conductor和Uber Cadence框架熱度逐漸下降，但提供商業支援的新創公司Orkes和Temporal的出現又提高了人們對它們的興趣，故選擇成熟的編排框架或平台攸關微服務導入的成敗。

總結本篇文章談論到的一致性控制技術，包括底層資料複製同步Outbox模式，分散式交易2PC，和Saga服務編排的業務一致性控管，如圖6所示。後續將介紹BPM如何設計業務流程，應用到微服務設計實作，並部署到K8s容器平台。

＜本文作者：鄭淳尹，Docker.Taipei社群共同發起人，國泰金控技術架構師，曾任台北富邦銀行雲端系統部架構師、微軟MVP、momo購物網架構師、臺北榮民總醫院資訊工程師、玉山銀行資訊處專員、宏碁eDC維運工程師。開源技術愛好者，曾在多間大學資工系擔任Docker容器技術講師，並翻譯審閱多本容器技術書籍。＞