(第1章 逃離單體地獄)
前言
這是一本關于微服務架構設計方面的書，這是本人閱讀的學習筆記。首先對一些符号做些說明：
（）為補充，一般是書本裡的内容；
[]符号為筆者筆注；
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和小而自治的團隊；
- 不要忘記采納微服務過程中的人性層面。你需要考慮員工的情緒才能成功轉換到微服務架構。
最後
::: hljs-center
新人制作，如有錯誤，歡迎指出，感激不盡！
:::
::: hljs-center
歡迎關注公衆号，會分享一些更日常的東西！
:::
::: hljs-center
如需轉載，請标注出處！
:::