《微服務架構設計模式》讀書筆記【TBC】
2020-10-28 15:00:43
背景
四季度選了《微服務架構設計模式》，但是狀態不怎麼樣，一個月過去了，才看了個開頭。部落格也好久沒更新了，正好有小夥伴想換工作要學習，又激勵了我一下，一起學習！選這本是因為公司也正在使用微服務的架構，Spring Cloud，Eureka。平時都在用，但是原理不太懂，出現點不常見的異常（百度不到的那種），就很懵*了，不知道要怎麼解決，全靠猜（竟然也解決了，離譜.....）
第1章 逃離單體地獄
單體架構的優點
- 開發簡單
- 易於對應用程式進行大規模的修改
- 測試相對簡單直觀
- 部署簡單明瞭
- 橫向擴充套件不費吹灰之力
單體地獄
即單體架構的侷限性在業務快速發展後不斷顯現，並且越來越難以維護
-
過度複雜
-
開發速度緩慢（協同工作問題）
-
程式碼提交到部署週期很長，且容易出現問題
-
難以擴充套件
-
交付可靠性是一個挑戰
-
需要長期依賴某個可能已經過時的技術棧
微服務架構
- 架構的重要性在於影響了應用的「非功能性需求」，比如 影響交付速度 的可維護性、可延伸性、可測試性
- 擴充套件立方體和服務
- 微服務的定義：把應用程式功能性分解為一組服務的架構風格。每一個服務都是由一組專注的、內聚的功能職責組成。
- 微服務架構作為模組化的一種形式：一般的大型應用會拆分為模組，而微服務架構即使用服務作為模組化的單元，服務可以進行獨立部署和擴充套件。
- 每個服務都擁有自己的資料庫
- 微服務與SOA的異同【沒太看懂】
- 微服務架構的好處
- 使大型複雜應用可以持續交付和部署
- 每個服務都相對較小並且容易維護
- 服務可以獨立部署和擴充套件
- 微服務架構可以實現團隊的自治
- 更容易實驗和採納新技術
- 更好的容錯性
- 微服務架構的弊端
- 服務的拆分和定義是一項挑戰
- 分散式系統帶來的各種複雜性，使開發、測試、部署變得更困難
- 當部署跨越多個服務的功能時，需要謹慎地協調更多開發團隊
- 開發者需要思考在什麼階段使用微服務架構
微服務架構的模式語言
- 架構設計的核心是決策
微服務架構並不是「銀彈」
- 光環曲線使用5個階段描述新興技術的發展：過熱期（期望釋放的頂峰，代表了對新技術的迷戀和崇拜）-> 谷底期（失望的谷，嘗試之後對新技術的失望）-> 成熟期（生產高地，理解了新技術的優缺點後開始理性地使用）【果然科學的盡頭是哲學】
模式和模式語言
- 沒太理解，但是不影響往後看🐶
微服務架構的模式語言概述
主要的模式：
- 服務拆分的相關模式
- 通訊相關的模式：通訊風格、服務發現、可靠性、事務性訊息、外部API
- 實現事務管理的資料一致性相關模式
- 在微服務架構中查詢資料的相關模式
- 服務部署的相關模式
- 可觀測性的相關模式
- 健康檢查API
- 紀錄檔聚合
- 分散式追蹤
- 異常追蹤
- 應用指標
- 審計紀錄檔
- 實現服務自動化測試的相關模式
- 解決基礎設施和邊界問題的相關模式
- 安全相關的模式
微服務之上：流程和組織
