本篇主要總結第三章:微服務架構中的程序間通訊。
在不討論訊息具體實現的情況下,作者從不同維度先對程序間通訊的互動方式進行了分類和歸納。
客戶端與服務的互動方式(維度二)
2.api的變更:微服務架構中,api一旦確定就下來,在更新api時必須確保舊新版本api的相容性。因此,引入api版本控制——語義化版本控制。
語義化版本控制,由3部分組成:major.minor.patch。遞增版本號規則:
3.後向相容的更改
在微服務架構中對api盡量只進行後向相容的更改:
4.非後向相容的更改
如果必須進行非後向相容的更改,需要同時支援新舊版本的api,直到所有客戶端都公升級到新的api。可以通過以下方式實現:
訊息的格式可分為兩大類:文字和二進位制
二進位制
作者主要介紹了rest和grpc,感覺作者更傾向於grpc。
bad
grpc
bad同步通訊必須處理區域性故障以提高可用性,作者介紹了斷路器模式。
斷路器:乙個遠端過程呼叫的**,在連續失敗次數超過指定閾值後的一段時間內,這個**會立即拒絕其他呼叫。同時分享了netflix的經驗,同步呼叫乙個服務時,客戶端需要這樣的機制增加健狀性:
在使用同步遠端過程呼叫中,必須使用服務發現機制,以獲取需要呼叫服務的網路位置。作者介紹了服務發現的分類,並推薦使用平台層服務發現模式。
應用層服務發現模式
平台層服務發現模式
部署平台為每個服務提供dns名稱、虛擬ip位址和解析為vip位址的dns名稱。客戶端向dns名稱和vip發出請求,部署平台自動將請求路由到其中乙個可用服務例項。
訊息傳遞
傳送方將訊息寫入通道,接收方從通道讀取訊息。
訊息通道
訊息**
服務的非同步api規範必須指定訊息通道的名稱、通過每個通道交換的訊息型別及格式。
事件發布
訊息**的好處和弊端
good
bad
處理併發和訊息順序
處理重複訊息
事務性訊息是指在更新資料庫的事務中發布訊息:更新資料庫和訊息發布必須以原子方式進行,否則系統可能昝於不一致狀態。
使用事務日誌拖尾模式發布事件:通過拖尾事務日誌發布對資料庫所做的更改。
程序間通訊機制與系統可用性之間的關係。同步機制的可用性相對較低,應該盡可能選擇非同步通訊機制來處理服務之間的呼叫。
消除同步互動
整章學習下來,感覺作者比較推崇基於訊息**的非同步通訊模式。主要原因是提高系統的可用性,降低通訊過程中的耦合度。
《微服務架構設計模式》 學習總結06
本篇主要總結第六章 使用事件溯源開發業務邏輯 將類對映到資料庫表,將類的字段對映到資料表中的列,類的例項對映到資料表中的行。比較成熟的orm,像mybatis jpa等。缺乏聚合歷史 實施審計功能將非常煩瑣且容易出錯事件發布凌駕於業務邏輯之上 事件溯源將每個聚合作為一系列事件來持久化儲存,每個事件代...
微服務架構設計模式綜述
隨著微服務的大量應用,在實踐中也會遇到很多之前單體架構所沒有的問題,微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式,我將其歸納整理如下表,以饗讀者。後面會陸續出關於微服務架構設計模式的文章,更加深入的闡述richardson先生關於微服...
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡,選擇特定的技術,將系統劃分為不同的部分並使用這些部分相互分工,彼此協作,為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式,每個服務執行在單獨的程序,一般採用輕量級的通訊機制互聯,...