前言
這是一本關於微服務架構設計方面的書，這是本人閱讀的學習筆記。首先對一些符號做些說明：
（）為補充，一般是書本里的內容；
[]符號為筆者筆注；
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和小而自治的團隊；
- 不要忘記採納微服務過程中的人性層面。你需要考慮員工的情緒才能成功轉換到微服務架構。
最後
