背景
四季度選了《微服務架構設計模式》，但是狀態不怎么樣，一個月過去了，才看了個開頭，博客也好久沒更新了，正好有小伙伴想換作業要學習，又激勵了我一下，一起學習！選這本是因為公司也正在使用微服務的架構，Spring Cloud，Eureka，平時都在用，但是原理不太懂，出現點不常見的例外（百度不到的那種），就很懵*了，不知道要怎么解決，全靠猜（竟然也解決了，離譜.....）
第1章 逃離單體地獄
單體架構的優點
- 開發簡單
- 易于對應用程式進行大規模的修改
- 測驗相對簡單直觀
- 部署簡單明了
- 橫向擴展不費吹灰之力
單體地獄
即單體架構的局限性在業務快速發展后不斷顯現，并且越來越難以維護
-
過度復雜
-
開發速度緩慢（協同作業問題）
-
代碼提交到部署周期很長，且容易出現問題
-
難以擴展
-
交付可靠性是一個挑戰
-
需要長期依賴某個可能已經過時的技術堆疊
微服務架構
- 架構的重要性在于影響了應用的“非功能性需求”，比如 影響交付速度 的可維護性、可擴展性、可測驗性
- 擴展立方體和服務
- 微服務的定義：把應用程式功能性分解為一組服務的架構風格，每一個服務都是由一組專注的、內聚的功能職責組成，
- 微服務架構作為模塊化的一種形式：一般的大型應用會拆分為模塊，而微服務架構即使用服務作為模塊化的單元，服務可以進行獨立部署和擴展，
- 每個服務都擁有自己的資料庫
- 微服務與SOA的異同【沒太看懂】
- 微服務架構的好處
- 使大型復雜應用可以持續交付和部署
- 每個服務都相對較小并且容易維護
- 服務可以獨立部署和擴展
- 微服務架構可以實作團隊的自治
- 更容易實驗和采納新技術
- 更好的容錯性
- 微服務架構的弊端
- 服務的拆分和定義是一項挑戰
- 分布式系統帶來的各種復雜性，使開發、測驗、部署變得更困難
- 當部署跨越多個服務的功能時，需要謹慎地協調更多開發團隊
- 開發者需要思考在什么階段使用微服務架構
微服務架構的模式語言
- 架構設計的核心是決策
微服務架構并不是“銀彈”
- 光環曲線使用5個階段描述新興技術的發展：過熱期（期望釋放的頂峰，代表了對新技術的迷戀和崇拜）-> 谷底期（失望的谷，嘗試之后對新技術的失望）-> 成熟期（生產高地，理解了新技術的優缺點后開始理性地使用）【果然科學的盡頭是哲學】
模式和模式語言
- 沒太理解，但是不影響往后看🐶
微服務架構的模式語言概述
主要的模式：
- 服務拆分的相關模式
- 通信相關的模式：通信風格、服務發現、可靠性、事務性訊息、外部API
- 實作事務管理的資料一致性相關模式
- 在微服務架構中查詢資料的相關模式
- 服務部署的相關模式
- 可觀測性的相關模式
- 健康檢查API
- 日志聚合
- 分布式追蹤
- 例外追蹤
- 應用指標
- 審計日志
- 實作服務自動化測驗的相關模式
- 解決基礎設施和邊界問題的相關模式
- 安全相關的模式
微服務之上：流程和組織
第2章 服務的拆分策略
第3章 微服務架構中的行程間通信
第4章 使用Saga管理事務
第5章 微服務架構中的業務邏輯設計
第6章 使用事件溯源開發業務邏輯
第7章 在微服務架構中實作查詢
第8章 外部API模式
第9章 微服務架構中的測驗策略（上）
第10章 微服務架構中的測驗策略（下）
第11章 開發面向生產環境的微服務應用
第12章 部署微服務應用
第13章 微服務架構的重構策略
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/195394.html
標籤：其他