《微服務架構設計模式》 學習總結03

2021-10-24 20:19:56 字數 1411 閱讀 2595

本篇主要總結第三章:微服務架構中的程序間通訊

在不討論訊息具體實現的情況下,作者從不同維度先對程序間通訊的互動方式進行了分類和歸納。

客戶端與服務的互動方式(維度二)

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先生關於微服...

微服務軟體架構設計

在軟體內部經過綜合各種因素考量 權衡,選擇特定的技術,將系統劃分為不同的部分並使用這些部分相互分工,彼此協作,為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式,每個服務執行在單獨的程序,一般採用輕量級的通訊機制互聯,...