聚合器微服務設計模式
這是一種最常見也最簡單的設計模式。
代理微服務設計模式
這是聚合模式的一個變種。
在這種情況下,客戶端並不聚合數據,但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求,也可以進行數據轉換工作。
鏈式微服務設計
這種模式在接收到請求後會產生一個經過合併的響應。
服務ABC之間的通信是同步消息傳遞,所以在整個鏈路調用完成之前,客戶端會一直阻塞。因此,服務調用鏈路不易過長,以免客戶端長時間等待。
分支微服務設計模式
這種設計是聚合器模式的擴展,允許同時調用兩個微服務鏈,如下圖
數據共享微服務設計模式
自治是微服務設計原則之一,就是說微服務是全棧式服務。但在重構現有的“單體 應用”時,SQL數據庫反規範華可能會導致數據重複和不一致。因此,在單體應用到微服務架構的過度階段,可以使用這種設計模式。
在這種情況下,部分微服務可能會共享緩存和數據庫緩存。不過,這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程序而言,這是一種反模式。
異步消息傳遞微服務設計模式
雖然REST設計模式非常流行,但它是同步的,會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應。
微服務設計時考慮的幾個問題
API Gateway服務見掉用服務發現服務容錯服務部署數據調用思維導圖