目錄
三、管理事務邊界：微服務架構中推崇打破事務邊界實現數據弱一致性
一、管理服務的依賴關係：構建無環依賴關係
依賴關係主要有三種基本表現形式：直接依賴、間接依賴和循環依賴，我們需要根據無環依賴原則知道在系統設計中不應該存在循環依賴，三種依賴關係如圖所示：
我們需要消除循環依賴，基本思路是通過在兩個相互依賴的組件之間添加中間層，變循環依賴爲間接依賴。有三種方式可以做到這一點，分別是上移、下移和回調。
我們以具體例子講解下，如下圖是一個循環依賴，User對象可以創建Order對象並保存Order對象列表，而Order對象需要用到User對象來進行打折discount信息計算Order金額，顯然User對象和Order對象循環依賴。
1.上移切入點：交互部分抽離
思想試將兩個相互依賴的組件中的交互部分抽象出來形成一個新的組件，而新的組件包含原來兩個組件的引用，即將循環依賴關係剝離出來並上升到一個更高層次的組件中。
對User對象和Order對象循環依賴進行上移，引入一個新組件Mediator，並提供一個payOrder（）方法對循環關係進行剝離，方法中使用User和Order作爲參數，實現Order中根據User的打折信息進行金額計算的業務邏輯。
2.下移切入點：依賴關係轉移重構
將依賴關係進行重構，重構抽象一個Calculator組件專門包含打折信息和金額計算，該Calculator由User創建，並注入到Order的pay方法中。
3.回調切入點：接口或抽象類
回調本質上就是一種雙向調用模式。在面向對象的語言中，回調通常通過接口或抽象類的方式來實現。
我們抽象出一個Calculator接口用於封裝金額計算邏輯，該接口與Order處於同一個層次，User實現該接口，這樣一來，原關係轉變爲了間接依賴。通過依賴注入機制，很容易實現Order和User之間的有效交互。
二、管理服務數據
任何業務都需要使用某個數據容器作爲持久化的機制或數據處理的媒介，所謂的數據容器，不僅僅指關係型數據庫，而是泛指包括消息隊列、搜索引擎索引以及各種NoSQL在內的數據媒介。
1.微服務中的數據管理策略
集中式數據管理方式有明顯有點，可由專業的DBA或系統管理員來規劃、實施以及優化。
但微服務崇尚把數據嵌入到微服務內部，這樣就涉及數據相關的關係型數據庫、各種NoSQL存儲、搜索引擎索引等將成爲微服務自身的一部分。如下圖，將數據完全嵌入到微服務看上去很完美，但實際存在兩大問題：（1）大多數微服務而言，爲每個服務匹配獨立的數據存儲容器顯然是一種浪費，因爲多數服務比較簡單；（2）對於由很多微服務構成的系統而言，搜索引擎等工具同樣存在很多實例，會給運維帶來巨大挑戰。
一個微服務並不一定需要獨立去包含自身所需要的數據，也可以採用集中式的數據管理方式在一定程度上實現數據獨立性，對於數據媒介而言可以設置命名空間的概念，可以針對每個微服務規劃專屬於它的表空間，從而在邏輯上與其他微服務進行隔離。
注意，對於一些業務比較獨立且數據訪問存在瓶頸的微服務而言，在設計時就將數據進行物理隔離自然是最佳實踐。
2.數據管理嘗試策略：CQRS模式及與領域驅動相結合
CQRS模式。即命令查詢的責任分離，是一種架構體系模式，能夠改變模型狀態的命令和模型狀態的查詢實現分離。
數據操作的基本表現爲CRUD，可以簡單分爲讀R和寫CUD，對應可分爲Query模式和Command模式。
在設計接口時，如果可能，應該儘量使接口單一化，嚴格保證方法的行爲是命令或查詢，這樣一來，查詢方法不會改變對象的狀態，沒有副作用，而會改變對象狀態的方法不應有返回值。
將其與領域事件結合起來使用，可構建高度低耦合系統，也是目前互聯網系統中非常常見的一種架構設計方法，即某一個微服務負責產生和維護數據。這些數據以事件作爲表現形式並通過消息傳遞系統發送到搜索引擎中，而另一個微服務則專門負責查詢搜索引擎中的數據進行進一步處理。
使用CQRS模式實際上與數據去中心化是一種互補的關係，把各個微服務所依賴的數據統一存儲到專門用於查詢的中央創庫是一種最佳實踐。
三、管理事務邊界：微服務架構中推崇打破事務邊界實現數據弱一致性
在微服務架構中，傳統分佈式事務並不是實現數據一致性的最佳選擇，在微服務架構中，我們推崇的是打破事務的邊界，實現數據的弱一致性，微服務架構裏面建議“兜底”思維，即不管實現方案是否完美，最後都要有一個備選方案，備選方案不一定滿足日常業務場景，但當出現異常情況時，可通過備選完成正常業務的閉環。具體在後面進行分析。
參考書籍、文獻和資料：
【1】鄭天民. 微服務設計原理與架構. 北京：人民郵電出版社，2018.