架構設計思想-微服務架構設計模式

1、微服務架構設計中常常須要處理的問題羅列：

• API Gateway
• 內部服務間互相調用
• 服務發現
• 服務容錯、熔斷、降級
• 服務部署
• 數據處理

 

2、設計模式

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

 

 

 

 

聚合器調用多個服務實現應用程序所需的功能。它能夠是一個簡單的 WEB 頁面，將檢索到的數據進行處理展現。它也能夠是一個更高層次的組合微服務，對檢索到的數據增長業務邏輯後進一步發佈成一個新的微服務，這符合 DRY 原則。另外，每一個服務都有本身的緩存和數據庫。若是聚合器是一個組合服務，那麼它也有本身的緩存和數據庫。聚合器能夠沿 X軸 和 Z軸 獨立擴展。 

本文做者:張永清，轉載註明出處：http://www.javashuo.com/article/p-kyqmdqqe-ng.html

DRY 原則：

不作重複的事（Don't Repeat Yourself），意思是說，在一個設計裏，對於任何東西，都應該有且只有一個表示，其它的地方都應該引用這一處。這樣須要改動的時候，只需調整這一處，全部的地方就都變動過來了。下降可管理單元複雜度的一個基本策略就是將他們拆解成更小的單元。

二、微服務-代理設計模式：

 

 相似聚合設計模式，可是客戶端並不聚合數據，但會根據業務需求的差異調用不一樣的微服務。代理能夠僅僅委派請求，也能夠進行數據轉換工做。

三、微服務-鏈式設計模式：

serviceA 接收到請求後會與 serviceB 進行通訊，相似地，serviceB 會同 serviceC 進行通訊。全部服務都使用同步消息傳遞。在整個鏈式調用完成以前，客戶端會一直阻塞。所以，服務調用鏈不宜過長，以避免客戶端長時間等待，這是一個同步的串行處理過程，沒法進行並行處理。

四、微服務-分支設計模式：

 

 容許同時調用兩個微服務鏈，適合於並行調用處理，效率更高。

五、微服務-dataShared設計模式：

 

 部分微服務可能會共享緩存和數據庫存儲。不過，這隻有在兩個服務之間存在強耦合關係時才能夠。對於基於微服務的新建應用程序而言，這是一種反模式，正常的狀況下，不推薦這麼設計。

六、微服務-異步消息設計模式：

 

  RESTFul 設計模式很是流行，但它是同步的，會形成阻塞。所以部分基於微服務的架構可能會選擇使用消息隊列代替 RESTFul 請求/響應。