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

這是一種最常見也最簡單的設計模式，效果如下圖所示。
聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的Web頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一步發布成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和數據庫。

二、代理微服務設計模式

這是聚合模式的一個變種，如下圖所示。
在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。每個微服務都有自己獨立的緩存和數據庫系統，彼此獨立。

三、鏈式微服務設計模式

這種模式在接收到請求後會產生一個經過合併的響應，如下圖所示：
在這種情況下，服務A接收到請求後會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。
因此，服務調用鏈不宜過長，以免客戶端長時間等待。

四、分支微服務設計模式

這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如下圖所示：
每個調用鏈分別調用自己的服務。當某個調用出現問題時，互相之間不會造成影響。

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

自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（monolithic application）”時，SQL數據庫反規範化可能會導致數據重複和不一致。
因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示：
在這種情況下，部分微服務可能會共享緩存和數據庫存儲。不過，這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程序而言，這是一種反模式。
 

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

雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應，如下圖所示：
各個服務之間通過異步的消息隊列進行交互，當服務出現問題時，不會造成阻塞，隊列會幫助緩存消息，直到消費服務開始工作。

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?