一、聚合氣微服務設計模式

最常見、最簡單的設計模式，效果如圖所示：?

聚合器調用多個服務實現應用程序所需的功能?

它可以是一個簡單的?Web?頁面，將檢索到的數據進行處理并展示，也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯后進一步發布成一個新的微服務，這符合?DRY?原則?

另外，每個服務都有自己的緩存和數據庫系統?

如果聚合器是一個組合服務，那么它也有自己的緩存和數據庫?

二、代理微服務設計模式

這是聚合模式的一個變種，如圖所示：

在這種情況下，客戶端并不聚合數據，但會根據業務需求的差別調用不同的微服務?

代理僅僅可以委派請求，也可以進行數據轉換工作?

每個微服務都有自己獨立地緩存和數據庫系統，彼此獨立?

三、鏈式微服務設計模式

這種模式在接收到請求后會產生一個經過合并的響應，如圖所示：?

Load?Balancer?到?Service?A?的線只有單向，如圖一，此處為繪畫錯誤

在這種情況下，服務?A?接收到請求后會與服務?B?進行通信，類似地，服務?B?會同服務?C?進行通信?

所有服務都使用同步消息傳遞?

在整個鏈式調用完成之前，客戶端會一直阻塞?

因此，服務調用鏈不宜過長，以免客戶端長時間等待?

四、分支微服務設計模式

這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如圖所示：?

Load?Balancer?到?Service?A?的線只有單向，如圖一，此處為繪畫錯誤

每個調用鏈分別調用自己的服務?

當某個調用出現問題時，互相之間不是造成影響

五、數據共享微服務設計模式

自治是微服務的設計模式之一，也就是說微服務是全棧式服務?

但在重構現有的 “單體應用（monolithic?application）” 時，SQL?數據庫反規范化可能會導致數據重復和不一致?

因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式。如圖所示：?

Load?Balancer?到?Service?A?的線只有單向，如圖一，此處為繪畫錯誤?

在這種情況下，部分微服務可能會共享緩存和數據庫存儲?

不過，這只有在兩個服務之間存在強耦合關系才可以?

對于基于微服務的新建應用程序而言，這是一種反模式?

六、異步消息傳遞微服務設計模式

雖然?RESTful?設計模式非常流行，但它是同步的，會造成阻塞?

因此部分基于微服務的架構可能會選擇使用消息隊列代替?RESTful?請求 / 響應，如圖所示：?

各個服務之間通過異步的消息隊列進行交互，當服務出現問題時，不會造成阻塞，隊列會幫忙緩存消息，直到消息服務開始工作?

參考資料：《微服務架構實戰》——?張鋒

一? 葉? 知? 秋，奧? 妙? 玄? 心?