摘要：微服務(wù)去中心化治理上圖中外部服務(wù)和內(nèi)部服務(wù)屬于網(wǎng)關(guān)所有的服務(wù)由統(tǒng)一的網(wǎng)關(guān)進(jìn)行管理比如外部應(yīng)用要調(diào)用服務(wù)就會(huì)經(jīng)過(guò)網(wǎng)關(guān)外部服務(wù)內(nèi)部應(yīng)用也是一樣的如果服務(wù)要調(diào)用服務(wù)則也需要通過(guò)網(wǎng)關(guān)進(jìn)行調(diào)用這樣看起來(lái)很規(guī)范但是每個(gè)用戶請(qǐng)求時(shí)只要有服務(wù)之間的交互則都

上圖中, 外部服務(wù)和內(nèi)部服務(wù)屬于 API 網(wǎng)關(guān), 所有的服務(wù)由統(tǒng)一的 API 網(wǎng)關(guān)進(jìn)行管理.

比如外部應(yīng)用要調(diào)用服務(wù)1, 就會(huì)經(jīng)過(guò) API 網(wǎng)關(guān)(外部服務(wù)), 內(nèi)部應(yīng)用也是一樣的. 如果服務(wù)N要調(diào)用服務(wù)2, 則也需要通過(guò) API 網(wǎng)關(guān)進(jìn)行調(diào)用.

這樣看起來(lái)很規(guī)范, 但是每個(gè)用戶請(qǐng)求時(shí)只要有服務(wù)之間的交互, 則都會(huì)從 API 網(wǎng)關(guān)進(jìn)行路由, 業(yè)務(wù)量增大后, 在很大程度上增加了 API 網(wǎng)關(guān)的調(diào)用 TPS, API 網(wǎng)關(guān)很快就遇到了性能瓶頸.

微服務(wù)倡導(dǎo)去中心化的治理,　不推薦每個(gè)服務(wù)都使用相同的標(biāo)準(zhǔn)和技術(shù)來(lái)開(kāi)發(fā)和使用服務(wù). 也就是說(shuō)你可以使用 C++ 開(kāi)發(fā)一個(gè)服務(wù), 來(lái)對(duì)接 Java 開(kāi)發(fā)的另一個(gè)服務(wù).

對(duì)于異構(gòu)系統(tǒng)之間的交互標(biāo)準(zhǔn), 可以使用 Thrift 遠(yuǎn)程調(diào)用框架使用中間語(yǔ)言 (IDL) 來(lái)定義接口, 中間語(yǔ)言是獨(dú)立于任何語(yǔ)言的, 并提供了工具來(lái)生成中間語(yǔ)言, 以及在中間語(yǔ)言與具體語(yǔ)言之間的代碼轉(zhuǎn)換.

最后談下微服務(wù)架構(gòu)是否就一定是去中心化的, 如果一個(gè)微服務(wù)架構(gòu)沒(méi)有使用微服務(wù)網(wǎng)關(guān)那它一定是去中心化的, 如果使用了微服務(wù)網(wǎng)關(guān)就需要進(jìn)行判斷.

微服務(wù)網(wǎng)關(guān)是否只提供了類似Dubbo服務(wù)注冊(cè)和發(fā)現(xiàn)能力, 實(shí)際訪問(wèn)仍然是點(diǎn)對(duì)點(diǎn)的服務(wù)調(diào)用, 如果是這種模式也可以理解為整個(gè)微服務(wù)架構(gòu)是去中心化的. 如果一個(gè)微服務(wù)網(wǎng)關(guān)提供了完全的對(duì)被調(diào)用系統(tǒng)的安全隔離, 包括提供了對(duì)每次消息調(diào)用的日志追溯能力, 那么微服務(wù)網(wǎng)關(guān)就是一個(gè)不可繞過(guò)的中心節(jié)點(diǎn), 整個(gè)微服務(wù)架構(gòu)也不再是去中心化的架構(gòu).

讀者容錯(cuò)模式指微服務(wù)化中服務(wù)提供者和消費(fèi)者之間如何對(duì)接口的改變進(jìn)行容錯(cuò). 也就是說(shuō), 消費(fèi)者獲取到提供者返回的數(shù)據(jù)時(shí), 無(wú)論這個(gè)數(shù)據(jù)如何變化, 我們只需要從中獲取到我們想要的數(shù)據(jù), 可以忽略新的消息項(xiàng)、可選的消息項(xiàng)等不需要的數(shù)據(jù).

只有當(dāng)消費(fèi)者不能完全識(shí)別接收到的消息, 或者無(wú)法通過(guò)識(shí)別的信息繼續(xù)處理流程時(shí), 才拋出異常.

在微服務(wù)領(lǐng)域, 微服務(wù)之間的交互通過(guò)定義良好的接口來(lái)實(shí)現(xiàn), 不允許使用共享數(shù)據(jù)來(lái)實(shí)現(xiàn).

在實(shí)踐的過(guò)程中, 有些方案的設(shè)計(jì)使用緩存或者數(shù)據(jù)庫(kù)作為兩個(gè)服務(wù)之間的紐帶, 在業(yè)務(wù)流程的處理過(guò)程中, 為了處理簡(jiǎn)單, 前一個(gè)服務(wù)將中間結(jié)果存入數(shù)據(jù)庫(kù)或緩存, 下一個(gè)服務(wù)從緩存或數(shù)據(jù)庫(kù)中拿到數(shù)據(jù)繼續(xù)處理. 如下圖:

這種交互流程的缺點(diǎn)如下:

使得微服務(wù)之間的交互除了接口契約, 還存在數(shù)據(jù)庫(kù)存儲(chǔ)契約.

上游的數(shù)據(jù)庫(kù)格式發(fā)生變化時(shí), 可能導(dǎo)致下游的處理邏輯出現(xiàn)問(wèn)題.

多個(gè)服務(wù)共享一個(gè)資源服務(wù), 對(duì)資源服務(wù)的運(yùn)維難以劃清職責(zé)和界限.

在做雙機(jī)獨(dú)立部署時(shí), 需要考慮服務(wù)和資源的路由情況, 跨機(jī)房的服務(wù)調(diào)用不能使用獨(dú)立的資源部署模式, 因此難以實(shí)現(xiàn)服務(wù)自治.

因此, 在設(shè)計(jì)微服務(wù)架構(gòu)時(shí), 一定不要共享緩存和數(shù)據(jù)庫(kù)等資源, 也不要使用總線模式, 服務(wù)之間的通信和交互只能依賴定義良好的接口, 通過(guò)使用 RESTful 樣式的 API 或透明的 RPC 調(diào)用框架.

消費(fèi)者驅(qū)動(dòng)契約模式用來(lái)定義服務(wù)之間交互接口改變的規(guī)則. 分為: 提供者契約、消費(fèi)者契約、消費(fèi)者驅(qū)動(dòng)的契約.

提供者契約: 提供者提供了什么功能和消息格式, 各消費(fèi)者不論實(shí)際需要多少功能都要無(wú)條件地遵守這些約定.

消費(fèi)者契約: 是對(duì)某個(gè)消費(fèi)者的需求進(jìn)行更為精確的描述, 在一次具體的服務(wù)業(yè)交互場(chǎng)景下, 代表消費(fèi)者需要提供者提供功能中的哪些部分?jǐn)?shù)據(jù). 消費(fèi)者契約可以被用來(lái)標(biāo)識(shí)現(xiàn)有的提供者契約, 也可以用來(lái)發(fā)現(xiàn)一個(gè)尚未明確的提供者契約.

消費(fèi)者驅(qū)動(dòng)的契約: 代表服務(wù)提供者向其所有當(dāng)前消費(fèi)者承諾遵守的約束. 一旦各消費(fèi)者把自己的具體期望告訴提供者, 則提供者無(wú)論在什么時(shí)間和場(chǎng)景下, 都不能打破契約.

在實(shí)現(xiàn)的服務(wù)交互設(shè)計(jì)中, 上面這三種契約是同時(shí)存在的, 筆者(這本書的作者)所在的支付平臺(tái)里, 交易系統(tǒng)在完成一筆支付后, 需要到賬務(wù)系統(tǒng)為商戶入賬, 這個(gè)過(guò)程中, 服務(wù)契約表現(xiàn)如下.

生產(chǎn)者契約: 賬務(wù)系統(tǒng)提供 Dubbo 服務(wù)化接口, 參數(shù)為商戶賬號(hào)ID、入賬訂單號(hào)和入賬金額.

消費(fèi)者契約: 賬務(wù)系統(tǒng)返回 DTO, 包含賬戶賬戶ID、入賬訂單號(hào)、入賬金額、入賬時(shí)間、賬務(wù)流水號(hào)、入賬狀態(tài)等, 而交易系統(tǒng)只需要使用其中的入賬訂單號(hào)和入賬狀態(tài).

消費(fèi)者驅(qū)動(dòng)的契約: 為了保證資金安全, 交易系統(tǒng)作為入賬的發(fā)起者向賬務(wù)提出要求, 需要賬務(wù)做冪等和濾重處理, 對(duì)重復(fù)的入賬請(qǐng)求進(jìn)行攔截; 賬務(wù)系統(tǒng)在接受這個(gè)契約后, 即將來(lái)有任何改變, 也不能打破這個(gè)限制, 否則就造成資金流失, 這在金融系統(tǒng)中是最嚴(yán)重的問(wèn)題.

服務(wù)提供者契約是服務(wù)提供者單方面定下的規(guī)則, 而一個(gè)消費(fèi)者契約會(huì)成為提供者契約的一部分, 多個(gè)服務(wù)消費(fèi)者可以對(duì)服務(wù)提供者提出約束, 服務(wù)提供者需要在將來(lái)遵守服務(wù)消費(fèi)者提出的契約, 這就是消費(fèi)者驅(qū)動(dòng)的契約.

上面的資料是我抄書加自己寫的, 如果難以理解可以看看 文章1 和 文章2

當(dāng)調(diào)用任意一個(gè)服務(wù)時(shí), 都需要經(jīng)過(guò)同一個(gè)服務(wù)(API 網(wǎng)關(guān), 也就是說(shuō)每個(gè)服務(wù)都不能繞過(guò)這個(gè)節(jié)點(diǎn)), 這就是中心化; 微服務(wù)提倡去中心化治理, 因?yàn)楫?dāng)業(yè)務(wù)量增加后可能會(huì)導(dǎo)致 API 網(wǎng)關(guān)出現(xiàn)性能瓶頸.

不推薦每個(gè)服務(wù)都使用相同的標(biāo)準(zhǔn)和技術(shù)來(lái)開(kāi)發(fā)和使用服務(wù). 可以使用 C++ 開(kāi)發(fā)一個(gè)服務(wù)來(lái)調(diào)用 Java 服務(wù).

微服務(wù)推薦使用 RESTful 樣式的 API 或透明的 RPC 調(diào)用框架, 進(jìn)行交互, 不推薦使用數(shù)據(jù)共享模式.

讀者容錯(cuò)模式就是在消費(fèi)者或提供者接口改變時(shí)進(jìn)行容錯(cuò), 比如提供者返回?cái)?shù)據(jù)中新增項(xiàng)后, 消費(fèi)者指獲取需要的數(shù)據(jù).

提供者契約: 服務(wù)提供者提供了哪些約定, 比如提供了什么功能和消息格式.

消費(fèi)者契約: 是對(duì)某個(gè)消費(fèi)者的需求進(jìn)行更為精確的描述, 在一次具體的服務(wù)業(yè)交互場(chǎng)景下, 代表消費(fèi)者需要提供者提供功能中的哪些部分?jǐn)?shù)據(jù).

消費(fèi)者驅(qū)動(dòng)契約: 例如服務(wù)端調(diào)整架構(gòu)或接口調(diào)整而對(duì)消費(fèi)者不透明, 導(dǎo)致接口調(diào)用失敗, 而CDC則是以消費(fèi)者提出接口契約, 交由服務(wù)提供方實(shí)現(xiàn), 并以測(cè)試用例對(duì)契約進(jìn)行產(chǎn)生約束, 所以服務(wù)提供方在滿足測(cè)試用例的情況下可以自行更改接口或架構(gòu)實(shí)現(xiàn)而不影響消費(fèi)者.