《微服務設計》閱讀筆記（五）分解單塊系統
《微服務設計》，Building Microservices，作者Sam Newman，譯者崔力強、張駿，人民郵電出版社，2016年。
筆記中有些內容直接引用原書。
================================================================
第五章 分解單塊系統
1. 關鍵是接縫。Michael Feathers在《修改代碼的藝術》一書中定義了接縫的概念。從接縫處可以抽取出相對獨立的一部分代碼，對這部分代碼進行修改不會影響系統的其他部分。接縫即邊界，前面說的限界上下文就是一個比較好的接縫。
2. 分解MusicCorp。MusicCorp是書中舉的一個例子。根據業務識別出高層限界上下文。創建包結構表示這些上下文，把對應的代碼挪過去。分析包之間的依賴關係，要和組織架構相匹配。使代碼圍繞接縫組織起來。
3. 分解單塊系統的 原因。要考慮分解的速度、團隊結構、安全審計、某些特殊技術實現的功能單獨形成一個服務等因素。
4. 雜亂的依賴。
要使拉出來的接縫盡量少被其他組件依賴。
5. 資料庫。不要用資料庫集成。找到資料庫中的接縫，分離出來。
6. 找到問題的關鍵。把資料庫映射相關的代碼和功能代碼放在同一個上下文，根據業務來組織。另外，資料庫表和表之間有約束，可以通過工具來可視化這些約束，如SchemaSpy(http://schemaspy.sourceforge.net)。
7. 例子：打破外鍵關係。將對屬於其它上下文的表的訪問轉變為對其服務的訪問，放棄外鍵關聯，如果需要可以將約束從資料庫轉移到代碼。
8. 例子：共享靜態數據。像國家代碼這種存在資料庫的情況，可以用三種方法解決：每個包複製一份該表；這些共享靜態數據放入代碼（如屬性文件或一個枚舉），比資料庫修改簡單；靜態數據放入一個單獨的服務（有些極端）。推薦第二種。
9. 例子：共享數據。共享數據可以創建一個單獨的包，提供該共享數據的服務。業務概念顯性化了。
10. 例子：共享表。不同上下文的共享表按上下文實際需要的信息分開。
11. 重構資料庫。資料庫分離操作具體可參見Scott J. Ambler和Pramod J. Sadalage編寫的Refactoring Databases。推薦先分離資料庫，別先著急分離服務，觀察一下效果，再考慮是否分離服務。
12. 事物邊界。使用單塊表結構，可以通過事務來保證多個操作的全部完成或全部回退。但按服務分表之後，無法使用事務來提供保證了。那應該怎麼辦呢？
再試一次。可以把操作放在隊列或日誌中，之後再嘗試觸發。最終一致性。
終止整個操作。通過補償事務來抵消之前的操作，可能還需要重試補償事務。
分散式事務。手動編排補償事務會比較難，可以採用分散式事務，使用事務管理器來統一編配。處理分散式事務常用演算法：兩階段提交。投票，根據投票結果實施。不要自己實現，盡量使用現有實現。
應該怎麼辦呢。上述方法會增加複雜性。要考慮是否一定要一致性，還是最終一致性就能滿足業務需求。最終一致性的系統構建和擴展都更容易。如果一定要一致性，可以顯式創建一個概念來表示這個服務，這樣更容易實現補償事務等操作。
13. 報告。存儲分離後，需要考慮報告會出現的問題。
14. 報告資料庫。報告需要獲得各個部分的數據生出輸出。在單塊系統中，數據在一個資料庫中，報告所需要的數據容易獲得。
15. 通過服務調用來獲取數據。依賴API調用獲取數據只適合簡單報告系統。使用SQL介面的問題在於不同的微服務暴露的API不一定能夠很好適用於報告場景。緩存能夠加快訪問速度，但也會有無法命中的情況。可以通過提供批量API來簡化過程，批量請求變為一個資源，處理好後通過共享文件給調用系統獲取，減少HTTP開銷。不過作者認為應該有更簡單的方式。
16. 數據導出。使用一個獨立的程序直接訪問其他服務使用的資料庫，把這些資料庫導出到單獨的報告資料庫。雖然該程序成為了一個資料庫集成程序，違反了低耦合原則，但它使得報告很簡單，因此可以接受。可以通過維護團隊負責將服務資料庫的數據導出到報告系統資料庫，緩解耦合性。也可以通過資料庫技術，如使用視圖創建一個聚合，使得對於報告系統來說看到的是單塊數據表，但修改資料庫時會增加複雜性。還是建議數據導出方式。
17. 事件數據導出。對於服務發出的事件可以通過事件訂閱器導入到報告資料庫中，比周期導入更及時，而且能夠將服務內部實現和報告系統解耦。缺點是所需要的信息都要以事件形式廣播出去，數據量大時，不容易像數據導出那樣在資料庫級別進行擴展。
18. 數據導出的備份。Netflix使用Cassandra作為數據備份的標準方式，開源了Aegisthus項目（一個能夠處理大量數據的流水線）。
19. 走向實時。可以考慮將不同的數據按需路由到不同地方。
20. 修改的代價。做小的、增量的修改。可以用白板便于思考。可以用CRC（類-職責-交互）卡片幫助設計。
21. 理解根本原因。服務一定會慢慢變大，大到需要拆分。要及時發現需要拆分的時機。
BrianZhang：《微服務設計》閱讀筆記(一)微服務
BrianZhang：《微服務設計》閱讀筆記（二）演化式架構師BrianZhang：《微服務設計》閱讀筆記(三)如何建模服務BrianZhang：《微服務設計》閱讀筆記（四）集成BrianZhang：《微服務設計》閱讀筆記（六）部署BrianZhang：《微服務設計》閱讀筆記（七）測試BrianZhang：《微服務設計》閱讀筆記（八） 監控BrianZhang：《微服務設計》閱讀筆記（九）安全BrianZhang：《微服務設計》閱讀筆記（十）康威定律和系統設計BrianZhang：《微服務設計》閱讀筆記（十一）規模化微服務BrianZhang：《微服務設計》閱讀筆記（十二完結篇）總結軟體開發之路
推薦閱讀：
※過去365天，40篇不能錯過的工具類技術乾貨文章集錦
※《Cloud Native Go》筆記（十五）結論
※「演講復盤」技術沙龍(滬江網4月) - 我所遇見的微服務演進這十年
※微服務落地第三課-Spring Cloud Config Client搭建