一、微服務架構設計中經常需要處理的問題羅列：

• 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 請求/響