前不久，Java Code Geeks發(fā)表了一篇文章猎莲，分析單體應(yīng)用與微服務(wù)的優(yōu)缺點(diǎn)绍弟。近日，該網(wǎng)站又發(fā)表了一篇文章著洼，提供了六種微服務(wù)架構(gòu)的設(shè)計(jì)模式樟遣。
1. 聚合器微服務(wù)設(shè)計(jì)模式
這是一種最常用也最簡單的設(shè)計(jì)模式而叼，如下圖所示：
聚合器調(diào)用多個(gè)服務(wù)實(shí)現(xiàn)應(yīng)用程序所需的功能。它可以是一個(gè)簡單的Web頁面豹悬，將檢索到的數(shù)據(jù)進(jìn)行處理展示葵陵。它也可以是一個(gè)更高層次的組合微服務(wù)，對檢索到的數(shù)據(jù)增加業(yè)務(wù)邏輯后進(jìn)一步發(fā)布成一個(gè)新的微服務(wù)瞻佛，這符合DRY原則脱篙。另外，每個(gè)服務(wù)都有自己的緩存和數(shù)據(jù)庫伤柄。如果聚合器是一個(gè)組合服務(wù)绊困，那么它也有自己的緩存和數(shù)據(jù)庫。聚合器可以沿X軸和Z軸獨(dú)立擴(kuò)展响迂。
2. 代理微服務(wù)設(shè)計(jì)模式
這是聚合器模式的一個(gè)變種考抄，如下圖所示：
在這種情況下，客戶端并不聚合數(shù)據(jù)蔗彤，但會(huì)根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)川梅。代理可以僅僅委派請求，也可以進(jìn)行數(shù)據(jù)轉(zhuǎn)換工作
3. 鏈?zhǔn)轿⒎?wù)設(shè)計(jì)模式
這種模式在接收到請求后會(huì)產(chǎn)生一個(gè)經(jīng)過合并的響應(yīng)然遏，如下圖所示：
在這種情況下贫途，服務(wù)A接收到請求后會(huì)與服務(wù)B進(jìn)行通信，類似地待侵，服務(wù)B會(huì)同服務(wù)C進(jìn)行通信丢早。所有服務(wù)都使用同步消息傳遞。在整個(gè)鏈?zhǔn)秸{(diào)用完成之前秧倾，客戶端會(huì)一直阻塞怨酝。因此，服務(wù)調(diào)用鏈不宜過長那先，以免客戶端長時(shí)間等待农猬。
4. 分支微服務(wù)設(shè)計(jì)模式
這種模式是聚合器模式的擴(kuò)展，允許同時(shí)調(diào)用兩個(gè)微服務(wù)鏈售淡，如下圖所示：
5. 數(shù)據(jù)共享微服務(wù)設(shè)計(jì)模式
自治是微服務(wù)的設(shè)計(jì)原則之一斤葱，就是說微服務(wù)是全棧式服務(wù)。但在重構(gòu)現(xiàn)有的“單體應(yīng)用（monolithic application）”時(shí)揖闸，SQL數(shù)據(jù)庫反規(guī)范化可能會(huì)導(dǎo)致數(shù)據(jù)重復(fù)和不一致揍堕。因此，在單體應(yīng)用到微服務(wù)架構(gòu)的過渡階段汤纸，可以使用這種設(shè)計(jì)模式衩茸，如下圖所示：
在這種情況下，部分微服務(wù)可能會(huì)共享緩存和數(shù)據(jù)庫存儲蹲嚣。不過递瑰，這只有在兩個(gè)服務(wù)之間存在強(qiáng)耦合關(guān)系時(shí)才可以祟牲。對于基于微服務(wù)的新建應(yīng)用程序而言，這是一種反模式抖部。
6. 異步消息傳遞微服務(wù)設(shè)計(jì)模式
雖然REST設(shè)計(jì)模式非常流行说贝，但它是同步的，會(huì)造成阻塞慎颗。因此部分基于微服務(wù)的架構(gòu)可能會(huì)選擇使用消息隊(duì)列代替REST請求/響應(yīng)乡恕，如下圖所示：
作者：weiweicsdn
鏈接：http://www.reibang.com/p/47c2ff7c6f98
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處俯萎。
