Managing Distributed Workflow#
本章討論分散式架構中的 coordination（協調）：如何將兩個以上的服務組合起來，完成特定的領域工作。在分散式架構中，有三個交互影響的耦合力量：communication（通訊）、consistency（一致性） 和 coordination（協調）。
協調有兩種基本模式：orchestration（編排） 和 choreography（編舞）。兩者的核心差異在於 orchestration 使用一個中央協調器（orchestrator），而 choreography 則不使用。
Figure 11.1: The dimensions of dynamic quantum coupling
Figure 11.2: Orchestration versus choreography in distributed architectures
Orchestration Communication Style#
Orchestration pattern 使用一個 orchestrator（有時稱為 mediator）來管理工作流程的狀態、錯誤處理、通知等。其命名來自音樂管弦樂團——指揮家協調各個不完整的部分，創造統一的樂曲。
- 在微服務架構中，每個工作流程都有各自的 orchestrator，而非使用全域性的 orchestrator（如 ESB）
- 使用全域 orchestrator（如 Enterprise Service Bus）會產生不良的耦合點，違反微服務解耦的目標
- Orchestrator 負責管理 happy path 以及各種 error path 和 boundary condition
Figure 11.3: Orchestration among distributed microservices
Figure 11.4: A "happy path" workflow using an orchestrator to purchase electronics
錯誤處理範例#
以電子商務下單為例：
- 付款被拒：Orchestrator 通知 Email Service 告知客戶訂單失敗，並更新 Order Placement Service 的狀態
- 缺貨退訂：Orchestrator 必須退款（透過 Payment Service）並更新訂單狀態
Figure 11.6: When an item is back-ordered, the orchestrator must rectify the state
即使在最複雜的錯誤場景中，orchestration 不需要額外增加原本不存在的通訊路徑，這與 choreography 不同。
Orchestration 的優缺點#
| 優勢 | 劣勢 |
|---|---|
| Centralized workflow：統一的狀態與行為管理 | Responsiveness：所有通訊都必須經過 mediator，可能成為瓶頸 |
| Error handling：有集中的狀態擁有者協助錯誤處理 | Fault tolerance：orchestrator 是單點故障（可透過冗餘解決） |
| Recoverability：可加入重試邏輯 | Scalability：有更多協調點，限制平行化 |
| State management：工作流程狀態可查詢 | Service coupling：orchestrator 與領域元件間耦合較高 |
Choreography Communication Style#
Choreography 沒有中央協調器，每個服務像舞伴一樣與其他服務互動。動作事先由編舞者/架構師規劃，但執行時沒有中央協調者。
- 發起請求送到責任鏈中的第一個服務
- 每個服務完成自己的工作後，發送訊息給下一個服務
- 乍看之下較簡單（少了 orchestrator，只有簡單的事件鏈），但邊界條件和錯誤處理才是真正的挑戰
Figure 11.7: Purchasing electronics using choreography
錯誤處理的複雜度#
- 付款失敗：Payment Service 必須發送失敗訊息給 Email Service 和 Order Placement Service——新增了一條原本不存在的通訊路徑
- 缺貨退訂：每個服務必須實作自己的 compensating message，因為沒有 orchestrator 來協調，每個錯誤場景都會增加服務間的通訊連結
Figure 11.8: Error in payment in choreography
Figure 11.9: Managing the workflow error condition of product backlog
Figure 11.10: Error conditions in choreography typically add communication links
Semantic Coupling vs. Implementation Coupling#
- Semantic coupling（語意耦合）：問題領域中固有的耦合，無法透過實作消除
- Implementation coupling（實作耦合）：架構師建模互動時引入的耦合
架構師永遠無法透過實作減少語意耦合，但可能讓它變得更糟。
過去十年架構設計的重要教訓：讓工作流程的語意盡可能貼近實作。Domain partitioning（領域分區）比 technical partitioning（技術分區）更能對齊領域概念。
Figure 11.11: Technical versus domain partitioning in architecture
Figure 11.12: Catalog Checkout is smeared across implementation layers in a technically partitioned architecture
Workflow State Management#
在 choreography 中沒有明顯的狀態擁有者，常見的三種狀態管理方式：
1. Front Controller Pattern
- 將狀態責任放在責任鏈中的第一個服務
- 優勢：建立偽 orchestrator，查詢訂單狀態方便
- 劣勢：增加通訊負擔，該服務除了領域行為還要管理工作流程狀態，不利效能和擴展
Figure 11.13: In choreography, a Front Controller is a domain service that owns workflow state
2. Stateless Choreography
- 不保留任何暫態工作流程狀態，靠查詢各個服務來重建即時快照
- 優勢：極度解耦，高效能和擴展性
- 劣勢：重建狀態複雜且耗費資源，複雜工作流程難以管理
3. Stamp Coupling
- 將工作流程狀態儲存在服務間傳遞的訊息契約中
- 每個服務更新契約中屬於自己的部分，再傳給下一個
- 優勢：不需要 front controller 或額外查詢
- 劣勢：契約需變大以容納工作流程狀態，無法提供即時狀態查詢
Choreography 的優缺點#
| 優勢 | 劣勢 |
|---|---|
| Responsiveness：較少瓶頸，更多平行機會 | Distributed workflow：沒有工作流程擁有者，錯誤管理困難 |
| Scalability：缺少協調點，可獨立擴展 | State management：沒有集中狀態 |
| Fault tolerance：沒有單一 orchestrator 可成為故障點 | Error handling：領域服務必須了解更多工作流程知識 |
| Service decoupling：沒有 orchestrator 意味著更低耦合 | Recoverability：沒有 orchestrator 難以重試和修復 |
Trade-Offs Between Orchestration and Choreography#
沒有完美的解決方案，需要根據具體情況進行取捨。
State Owner and Coupling#
- 狀態擁有權通常存在於某處：orchestrator、front controller 或其他地方
- 在 choreography 中移除 mediator 會強制服務間更高層級的通訊
- 當工作流程複雜度上升，orchestrator 的需求也成正比增加
- 語意複雜度越高的工作流程，越適合使用 orchestrator
Figure 11.14: As the complexity of the workflow rises, orchestration becomes more useful
Choreography 的甜蜜點：需要高回應性和擴展性的工作流程，且錯誤場景簡單或不常發生。適用於 Phone Tag Saga、Time Travel Saga、Anthology Saga 等模式。
Orchestration 的甜蜜點：包含複雜邊界和錯誤條件的工作流程。雖然擴展性不如 choreography，但大幅降低複雜度。適用於 Epic Saga、Fairy Tale Saga、Fantasy Fiction Saga、Parallel Saga 等模式。
Sysops Squad Saga: Managing Workflows#
團隊討論主要的 ticket 工作流程，涉及四個服務：
客戶端操作：
- 客戶透過 Ticket Management Service 提交問題單
背景操作：
- Ticket Assignment Service 找到合適的 Sysops 專家
- Ticket Assignment Service 將問題單路由到專家的行動裝置
- 透過 Notification Service 通知客戶專家已出發
- 專家修復問題並標記完成，送到 Ticket Management Service
- Ticket Management Service 與 Survey Service 溝通，請客戶填寫問卷
Figure 11.15: Primary ticket flow modeled as choreography
取捨分析#
團隊建立了 orchestration 和 choreography 的比較表：
| 考量項目 | Orchestration | Choreography |
|---|---|---|
| Workflow control | 較佳 | - |
| State query | 較佳 | 較佳（兩者皆可） |
| Error handling | 較佳 | - |
最終決策#
團隊選擇使用 orchestration，因為：
- 問題單可能遺失或路由錯誤，需要更好的工作流程控制
- 業務需要隨時查詢問題單狀態
- 問題單可能被取消、重新指派，需要完善的錯誤處理
Figure 11.16: Primary ticket workflow modeled as orchestration
ADR: Use Orchestration for Primary Ticket Workflow
Context：主要 ticket 工作流程必須支援遺失訊息追蹤、優秀的錯誤處理、以及追蹤 ticket 狀態的能力。
Decision：使用 orchestration。
Consequences：ticket 工作流程可能在單一 orchestrator 周圍產生擴展性問題，若擴展需求改變應重新考慮。