聚合器微服務(wù)設(shè)計模式
這是一種最常見也最簡單的設(shè)計模式。
代理微服務(wù)設(shè)計模式
這是聚合模式的一個變種堪藐。
在這種情況下莉兰,客戶端并不聚合數(shù)據(jù),但會根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)礁竞。代理可以僅僅委派請求糖荒,也可以進行數(shù)據(jù)轉(zhuǎn)換工作。
鏈?zhǔn)轿⒎?wù)設(shè)計
這種模式在接收到請求后會產(chǎn)生一個經(jīng)過合并的響應(yīng)模捂。
服務(wù)ABC之間的通信是同步消息傳遞捶朵,所以在整個鏈路調(diào)用完成之前,客戶端會一直阻塞枫绅。因此泉孩,服務(wù)調(diào)用鏈路不易過長,以免客戶端長時間等待并淋。
分支微服務(wù)設(shè)計模式
這種設(shè)計是聚合器模式的擴展寓搬,允許同時調(diào)用兩個微服務(wù)鏈,如下圖
數(shù)據(jù)共享微服務(wù)設(shè)計模式
自治是微服務(wù)設(shè)計原則之一县耽,就是說微服務(wù)是全棧式服務(wù)句喷。但在重構(gòu)現(xiàn)有的“單體 應(yīng)用”時镣典,SQL數(shù)據(jù)庫反規(guī)范華可能會導(dǎo)致數(shù)據(jù)重復(fù)和不一致。因此唾琼,在單體應(yīng)用到微服務(wù)架構(gòu)的過度階段兄春,可以使用這種設(shè)計模式。
在這種情況下锡溯,部分微服務(wù)可能會共享緩存和數(shù)據(jù)庫緩存赶舆。不過,這只有在兩個服務(wù)之間存在強耦合關(guān)系時才可以祭饭。對于基于微服務(wù)的新建應(yīng)用程序而言芜茵,這是一種反模式。
異步消息傳遞微服務(wù)設(shè)計模式
雖然REST設(shè)計模式非常流行倡蝙,但他是同步的九串,會造成阻塞。因此部分基于微服務(wù)的架構(gòu)可能會選擇使用消息隊列代替REST請求/響應(yīng)寺鸥。
微服務(wù)設(shè)計時考慮的幾個問題
- API Gateway
- 服務(wù)見掉用
- 服務(wù)發(fā)現(xiàn)
- 服務(wù)容錯
- 服務(wù)部署
- 數(shù)據(jù)調(diào)用