前篇
上篇將微服務的理念、架構、參考等關鍵環節進行了總結，如下將對微服務化架構建設後，數據的分散或分佈造成的數據冗餘、割裂、事務完整性等闡述解決方案。
分佈式數據管理
拆解造成的最大問題就是數據被分散了，不僅僅是原來有關聯的表級的拆解，更關鍵的是數據庫的拆解，乃至使用完全不同的數據存儲和數據訪問層實現。
所以如何在分佈式數據庫、微服務應用架構體系之下，管理好分佈乃至離散的數據，不僅僅是技術問題，或框架需要解決的問題，更關鍵是架構理念的變化及對於數據事務及ACID的權衡。
典型的2PC事務保障
可參考Wiki百科上的描述和介紹。這個是所有事務管理的基礎。
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
分佈式數據管理 / 分佈式事務
在微服務架構體系實現中，為了維護數據的一致性，傳統的2PC方式無能為力。同時大量的查詢類型的操作，需要讀取不同業務領域的數據，這對於訪問層的實現也帶來了難度。
所以一般通過如下兩種方式解決分佈式數據和事務的管理：
- 通過Sagas維護數據一致性：其本質是服務邏輯之間的跨域直接調用及同步，且需要補償的實現。即強耦合的服務編排。
- 通過CQRS視圖實現事務統一視圖：充分利用冗餘數據及分佈式消息驅動的理念實現的“讀寫”分離。即松耦合的服務編制。
分佈式數據管理 – ACID的實現
分佈式數據管理的管理目標就是數據的完整性，即ACID。在微服務架構體系之下，對於其實現，概念的邏輯如下：
- 步驟一：主域數據提交併發送業務數據變更事件。
- 步驟二：從域數據訂閱並消費業務數據變更事件，並記錄事件日誌，同時發送消費回執事件。
- 步驟三：主域訂閱並消費回執事件，同步回執狀態到自身數據領。
Atomicity的實現
然而為了原子性的最終實現，避免數據交易的完整性（至少在本域內是完整的），則需要考慮如下幾種方案：
- 方案1:通過本地事務發佈事件
通過業務層，將主域數據寫入與發佈事件日誌保持在統一事務之內，並實現數據發佈，即業務層代碼的FR和NFR的混雜及強耦合。
- 方案2:通過數據庫交易記錄
基於Binlog的CDC、Data Replication、Data Bus等實現，即數據庫日誌方式。無損的從數據庫層面捕獲並分發業務數據變更。即依賴於數據庫中間件，例如同步、CDC等的數據庫服務支撐。
- 方案3:通過事件溯源
事件溯源（Event Sourcing） - 以一連串事件的方式來持久化聚合，完全獨立於各個業務領域的單獨應用系統。即全部以消息隊列方式串聯的數據寫入和業務事件關聯記錄，松耦合的全新實現理念。
事件溯源 – 2PC vs Saga
如選用Saga方式，則需要通過回調或補償接口實現狀態更新，即必須額外開發回調接口和實現對接。
事件溯源 – CQRS（ Command Query Responsibility Segregation ）
為解決Saga的強耦合和額外補償機制的開發，以及服務編排的劣勢，則通過CQRS架構方式來實現，即：Command-Side處理CUD，Query-Side通過來自於訂閱的消息隊列的數據視圖來處理R。
- 事件溯源 – CQRS概念架構
如下是一個典型的邏輯架構，其本質上講寫入和查詢割裂，通過消息隊列串聯寫入時的數據複製。
- CQRS業務交易提交方案
然而其需要以消息隊列作為中間件的強力支持：一體方式 & 全後臺消息驅動。
- CQRS流程
如下是一個典型流程。在大型企業和項目中，Event Aggregator將是整個系統的核心和重要技術實現的投入。同時需要明晰的定義業務數據訂閱及消費的流轉流程和處理關係。更同時，由於其將是整個系統協同的關鍵骨架，IT設計上需要投入更多的精力去保障其高可用等NFR的屬性。
- CQRS案例
https://github.com/cer/event-sourcing-examples，是一個典型且開箱即用的CQRS應用案例，對於小型項目和初始項目可以直接複用。後續大型項目和項目的深入也可以直接使用，但是需要的就是兩點：1) 消息中間件的NFR設計，2) 消息驅動的消息載體定義及治理。
TCC
TCC是一種比較成熟的分佈式事務解決方案，可用於解決跨庫操作的數據一致性問題；TCC是服務化的兩階段編程模型，其Try、Confirm、Cancel 3個方法均由業務編碼實現；其中Try操作作為一階段，負責資源的檢查和預留，Confirm操作作為二階段提交操作，執行真正的業務，Cancel是預留資源的取消；如下圖所示，業務實現TCC服務之後，該TCC服務將作為分佈式事務的其中一個資源，參與到整個分佈式事務中；事務管理器分2階段協調TCC服務，在第一階段調用所有TCC服務的Try方法，在第二階段執行所有TCC服務的Confirm或者Cancel方法。
雖然TCC是成熟的分佈式事務解決方案，同時也有穩定的開源架構支撐。但是其需要的是額外引入架構體系，同時對現有業務層代碼進行介入式開發及改造。關鍵其本質也沒有要解決系統的解耦和集成。其只關注分佈式事務。
所以推薦如果不是在老系統上進行改造或特定場景，對於微服務架構的分佈式數據及事務管理，推薦使用CQRS的以Event-Driven方式的全解耦理念。
總結
微服務架構不是完美的，也不是輕量化的，其不僅僅需要架構理念，更需要基於業務的分析及治理能力，並利用DDD的思路進行業務到數據的分割，同時將Event-Driven用到極致。
閱讀更多 AirlineDataPlus 的文章
