一、微服務架構設計中經常需要處理的問題羅列： API Gateway 內部服務間互相調用 服務發現 服務容錯、熔斷、降級 服務部署 數據處理 二、設計模式 1、微服務-聚合器設計模式： 聚合器調用多個服務實現應用程式所需的功能。它可以是一個簡單的 WEB 頁面，將檢索到的數據進行處理展示。它也可以是 ...
一、微服務架構設計中經常需要處理的問題羅列：
- API Gateway
- 內部服務間互相調用
- 服務發現
- 服務容錯、熔斷、降級
- 服務部署
- 數據處理
二、設計模式
1、微服務-聚合器設計模式：
聚合器調用多個服務實現應用程式所需的功能。它可以是一個簡單的 WEB 頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一步發佈成一個新的微服務，這符合 DRY 原則。另外，每個服務都有自己的緩存和資料庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和資料庫。聚合器可以沿 X軸 和 Z軸 獨立擴展。
本文作者:張永清，轉載註明出處：https://www.cnblogs.com/laoqing/p/13187684.html
DRY 原則：
不做重覆的事（Don't Repeat Yourself），意思是說，在一個設計里，對於任何東西，都應該有且只有一個表示，其它的地方都應該引用這一處。這樣需要改動的時候，只需調整這一處，所有的地方就都變更過來了。降低可管理單元複雜度的一個基本策略就是將他們拆解成更小的單元。
2、微服務-代理設計模式：
類似聚合設計模式，但是客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
3、微服務-鏈式設計模式：
serviceA 接收到請求後會與 serviceB 進行通信，類似地，serviceB 會同 serviceC 進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調用鏈不宜過長，以免客戶端長時間等待，這是一個同步的串列處理過程，無法進行並行處理。
4、微服務-分支設計模式：
允許同時調用兩個微服務鏈，適合於並行調用處理，效率更高。
5、微服務-dataShared設計模式：
部分微服務可能會共用緩存和資料庫存儲。不過，這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程式而言，這是一種反模式，正常的情況下，不推薦這麼設計。
6、微服務-非同步消息設計模式：
RESTFul 設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替 RESTFul 請求/響應。
