前言
這是一本關於微服務架構設計方面的書，這是本人閱讀的學習筆記。首先對一些符號做些說明：
（）為補充，一般是書本里的內容；
[]符號為筆者筆注；
1. 邁向單體地獄的漫長旅程
在書中，作者以Food to Go（下簡稱FTGO）業務分析單體應用程序的優缺點。
1.1 FTGO應用程序單體架構
1.2 單體架構的好處
- 應用開發簡單；
- 易對應用程序進行大規模修改；
- 測試相對簡單直觀；
- 部署簡單明了；
- 橫向擴展不費吹灰之力；
1.3 FTGO應用程序單體地獄
1.4 什么是單體地獄
- 過度復雜性會嚇退開發者；
- 開發速度慢；
- 從代碼提交到實際部署的周期很長，容易出問題；
- 難以擴展；
- 交付可靠的單體應用是一項挑戰；
- 需要長期依賴某個可能已過時的技術棧；
2. 為什么本書與你有關
什么人適合閱讀：軟件開發人員、架構師、CTO或工程研發副總裁；或者所負責的應用程序超出單體架構所能支撐的范圍。
2.1 閱讀門檻
- 三層架構；
- Web應用程序設計；
- 使用面向對象設計來開發業務邏輯；
- 關系型數據庫：SQL和ACID事務的概念；
- 使用消息代理和REST API進行進程間通信；
- 安全，包括身份驗證和訪問授權；
- Spring框架；
3. 你會在本書中學到什么
讀完本書能理解與掌握的知識點與技術點。
3.1 需要重點關注的知識
- 微服務架構的基本特點，它的好處與弊端，以及在什么時候使用微服務架構；
- 分布式數據管理的架構模式；
- 針對微服務架構應用程序的有效測試策略；
- 微服務架構應用程序的部署方式；
- 把單體應用重構為微服務架構的策略；
3.2 其他技術
- 使用微服務的架構模式來設計應用程序的架構；
- 為服務開發業務邏輯；
- 使用Saga在進程間維護數據的一致性；
- 實現跨服務的數據查詢；
- 更高效地測試服務架構應用程序；
- 開發生產環境就緒的應用程序，實現安全性、可配置性和可觀測性；
- 把現有的單體應用重構為服務；
4. 拯救之道：微服務架構
主要介紹人微服務架構的一些定義與基本特性。
4.1 擴展應用程序的三個維度（擴展立方體）[微服務的定義]
- X軸擴展：在多個實例之間實現請求的負載均衡，[簡單來說就是Ctrl CV]；
- Z軸擴展：根據請求的屬性路由請求，（用於應用程序需要處理增加的事務和數據量時），[流量分區擴容]；
- Y軸擴展：根據功能把應用拆分為服務，（亦稱為功能性分解），[一般先進行Y軸擴展，再采用X、Z軸擴展]；
4.2 微服務的基本特性
- 擴展立方體；
- 模塊化，[指開發人員無法繞開服務的API訪問內部組件]；
- 每個服務擁有自己的數據庫；
4.3 FTGO的微服務架構
將Y軸分解應用於FTGO應用程序，將得到下圖：
可以看出該模型的特點有：
- 每個服務API清晰定義；
- 每個服務可以獨立開發、測試、部署和擴展；
- 模塊化；
4.4 微服務架構與SOA的異同
相似點：
- 都是特定的風格架構；
- 都以一系列服務方式組織系統；
不同點：
- 完全不同的技術棧（微服務架構采用輕量級、開源技術以及啞管道通信）；
- 處理數據方式不同（微服務架構有自己的數據庫）；
- 服務尺寸、規模不同（微服務架構中的服務相對較小）；
5. 微服務架構的好處與弊端
5.1 微服務架構的好處
- 使大型的復雜應用程序可以持續交付和持續部署，[支持自動化測試、獨立部署、開發團隊自主且松散耦合]；
- 每個服務都相對較小並容易維護；
- 服務可以獨立部署；
- 服務可以獨立擴展；
- 微服務架構可以實現團隊的自治；
- 更容易實驗和采納新技術；
- 更好的容錯性；
5.2 微服務架構的弊端
- 服務的拆分與定義是一項挑戰；
- 分布式系統帶來各種復雜性，使開發、測試和部署變得困難；
- 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊；
- 開發者需要思考到底應該在應用的什么階段使用微服務架構；
6. 微服務架構的模式語言
一個用來表述多種架構設計的選擇方案，並且可用來改進決策的方式，就是使用模式語言。微服務架構的模式是微服務架構設計的重難點，也是后續章節的重難點。
6.1 一些概念（模式、模式語言等）
- 模式：針對特定上下文中發生的問題的可重用解決方案；
- 模式語言：解決特定領域內問題的相關模式的集合；
- 軟件模式：通過定義一組互相協作的軟件元素來解決軟件架構或設計問題；
6.2 常用的模式結構包括三個重要部分
- 需求（Forces）：必須解決的問題；
- 結果上下文（Resulting context）：采用模式后可能帶來的后果（包含好處、弊端、問題）；
- 相關模式（Related patterns）：5種不同類型的關系（前導、后續、替代、泛化、特化）；
6.3 微服務架構模式語言
上圖有四個模式組：
- 應用程序架構模式組：最左邊，分為單體架構模式與微服務架構模式；
- 應用相關模式組：解決開發人員面對的具體技術和架構問題；
- 應用基礎設施相關模式組：解決應用層面的基礎設施相關問題；
- 基礎設施相關模式組：解決通常在開發環節跟基礎設施有關的問題；
6.4 微服務的主要幾組模式【重點】
服務拆分相關模式：
【第2章重點介紹】將系統拆分本質上是一門藝術，但可以有一定策略，如下圖所示：
通信相關模式：
【第3與第8章介紹】進程間通信（IPC）是分布式系統的重要組成部分，其包括：
- 通信風格：使用哪類進程間通信機制；
- 服務發現：客戶端如何獲取服務具體實例的IP地址；
- 可靠性：在服務不可用情況下，如何確保服務間的可靠通信；
- 事務性消息：如何將消息發送、事件發布這樣的動作與更新的業務數據的數據庫事務集成；
- 外部API：應用程序的客戶端如何與服務進行通信；
實現事務管理的數據一致性相關模式：
【第4~6章介紹】使用Saga模式確保數據一致性，而不是兩步式提交（2PC）方式。下圖展示數據一致性相關模式：
在微服務架構中查詢數據的相關模式：
【第7章介紹】可以使用API組合模式，逐一調用服務的API，然后將所有的返回聚合在一起，如下圖所示：
服務部署相關模式：
【第12章介紹】往往需要一個高度自動化部署的基礎設施，一個部署平台（可以是UI圖形化界面、命令行等），如下圖所示：
可觀測性相關模式：
【第11章介紹】指弄清應用在運行時的一些行為，同時根據錯誤的請求或高延遲等故障進行診斷排錯。以下模式可用來設計具備可觀測性的服務：
- 健康檢查API：可以返回服務健康狀態的API；
- 日志聚合：把服務產生的日志寫入一個集中式的日志服務器，這個服務器可以提供日志搜索，也可以根據日志情況觸發報警；
- 分布式追蹤：為每一個外部請求分配一個唯一的ID，用於在各個服務之間追蹤外部請求；
- 異常跟蹤：把程序異常發送到異常跟蹤服務，這個服務會排除重復異常，給開發者發送報警並且跟蹤每一個異常的解決；
- 應用指標：供維護使用的指標，如計數器等，導出到指標服務器；
- 審計日志：記錄用戶的行為；
實現服務自動化測試的相關模式：
【第9~10章介紹】需要注意測試不同服務是否協同工作。以下通過單獨測試服務簡化測試的模式：
- 消費者端驅動的契約測試：驗證服務滿足客戶端所期望的功能；
- 消費端契約測試：驗證服務的客戶端可以正常與服務通信；
- 服務組件測試：在隔離的環境中測試服務；
解決基礎設施和邊界問題的相關模式：
【第11章介紹】每個服務都必須實現許多跟基礎設施相關的功能，此外必須實現外部化配置模式。在開發新服務時可以使用微服務基底模式解決一些基礎設施的相關問題。
安全相關模式：
【第11章介紹】在用戶身份驗證工作中常用訪問令牌模式，用戶信息傳遞后的服務可以驗證令牌獲取用戶信息。
7. 微服務之上：流程和組織
架構不是唯一需要關注的領域，還必須思考流程與組織。
7.1 架構、流程與組織間的關系
8. 本章小結
- 單體架構模式將應用程序構建為單個可部署單元；
- 微服務架構模式將系統分解為一組可獨立部署的服務，每個服務都有自己的數據庫；
- 單體架構是簡單應用的不錯選擇，微服務架構通常是大型復雜應用的更好選擇；
- 微服務架構使小型自治團隊能夠並行工作，從而加快軟件開發的速度；
- 微服務架構不是銀彈：它存在包括復雜性在內的諸多弊端；
- 微服務架構模式語言是一組模式，可幫助你使用微服務架構構建應用程序。它可以幫助你決定是否使用微服務架構，如果你選擇微服務架構，模式語言可以幫助你有效地應用它；
- 你需要的不僅僅是通過微服務架構來加速軟件交付。成功的軟件開發還需要DevOps和小而自治的團隊；
- 不要忘記采納微服務過程中的人性層面。你需要考慮員工的情緒才能成功轉換到微服務架構。
最后
