【六種微服務架構的設計模式】

聚合器微服務設計模式

聚合器調用多個服務實作應用程式所需的功能。它可以是一個簡單的Web頁面，将檢索到的資料進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的資料增加業務邏輯後進一步釋出成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和資料庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和資料庫。聚合器可以沿X軸和Z軸獨立擴充。

代理微服務設計模式

在這種情況下，用戶端并不聚合資料，但會根據業務需求的差别調用不同的微服務。代理可以僅僅委派請求，也可以進行資料轉換工作。

鍊式微服務設計模式

在這種情況下，服務A接收到請求後會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鍊式調用完成之前，用戶端會一直阻塞。是以，服務調用鍊不宜過長，以免用戶端長時間等待。

分支微服務設計模式

這種模式是聚合器模式的擴充，允許同時調用兩個微服務鍊，

資料共享微服務設計模式

自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（monolithic application）”時，SQL資料庫反規範化可能會導緻資料重複和不一緻。是以，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示：

在這種情況下，部分微服務可能會共享緩存和資料庫存儲。不過，這隻有在兩個服務之間存在強耦合關系時才可以。對于基于微服務的建立應用程式而言，這是一種反模式。

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

雖然REST設計模式非常流行，但它是同步的，會造成阻塞。是以部分基于微服務的架構可能會選擇使用消息隊列代替REST請求/響應