微服務架構的設計模式

jopen 9年前發布 | 56K 次閱讀 設計模式

原文  http://www.infoq.com/cn/news/2015/04/micro-service-architecture


<p> 前不久,Java Code Geeks發表了一篇 <a href="/misc/goto?guid=4958871413170057400" rel="nofollow,noindex">文章</a> ,分析 <a href="/misc/goto?guid=4958871413283360945" rel="nofollow,noindex">單體應用與微服務的優缺點</a> 。近日,該網站又發表了一篇 <a href="/misc/goto?guid=4958871413407961552" rel="nofollow,noindex">文章</a> ,提供了六種微服務架構的設計模式。 </p>

<p> 聚合器微服務設計模式 </p>

<p> 這是一種最常用也最簡單的設計模式,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/db7da53f7815373ee68211996ddf89a8.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="361" /> </p>

<p> 聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的Web頁面,將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務, 對檢索到的數據增加業務邏輯后進一步發布成一個新的微服務,這符合DRY原則。另外,每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務,那么它 也有自己的緩存和數據庫。聚合器可以沿X軸和Z軸獨立擴展。 </p>

<p> 代理微服務設計模式 </p>

<p> 這是聚合器模式的一個變種,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/e9a12c91ff5c7cec33d18552dd905cfb.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="359" /> </p>

<p> 在這種情況下,客戶端并不聚合數據,但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求,也可以進行數據轉換工作。 </p>

<p> 鏈式微服務設計模式 </p>

<p> 這種模式在接收到請求后會產生一個經過合并的響應,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/a0da38c91639c97b85ea2361344f1e06.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="393" /> </p>

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

<p> 分支微服務設計模式 </p>

<p> 這種模式是聚合器模式的擴展,允許同時調用兩個微服務鏈,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/89fcb1094f0795c27f9f98bdd6c2b36c.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="437" /> </p>

<p> 數據共享微服務設計模式 </p>

<p> 自治是微服務的設計原則之一,就是說微服務是全棧式服務。但在重構現有的“單體應用(monolithic application)”時,SQL數據庫反規范化可能會導致數據重復和不一致。因此,在單體應用到微服務架構的過渡階段,可以使用這種設計模式,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/4d987e6eda53947b1afdbd87fdb40109.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="433" /> </p>

<p> 在這種情況下,部分微服務可能會共享緩存和數據庫存儲。不過,這只有在兩個服務之間存在強耦合關系時才可以。對于基于微服務的新建應用程序而言,這是一種反模式。 </p>

<p> 異步消息傳遞微服務設計模式 </p>

<p> 雖然REST設計模式非常流行,但它是同步的,會造成阻塞。因此部分基于微服務的架構可能會選擇使用消息隊列代替REST請求/響應,如下圖所示: </p>

<p> <img src="https://simg.open-open.com/show/bff34f45bb709d2a4d5f698fc80bbe92.png" class="alignCenter" alt="微服務架構的設計模式" width="700" height="438" /> </p>

<p> 感興趣的讀者可以參考《 <a href="/misc/goto?guid=4958871413530090258" rel="nofollow,noindex">微服務中的耦合與自治</a> 》一文為自己的微服務選擇合適的消息傳遞模式。 </p>

  </div>

</div>

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!