微服務設計模式（上）

女主宣言

問題

微服務就是讓服務鬆散耦合，應用單一職責原則。然而，將應用程式分解成更小的部分必須邏輯地完成。如何將應用程式分解為小型服務？

解決方案

一種策略是根據業務能力分解。業務能力是企業為了產生價值而做的事情。給定業務的功能集取決於業務型別。例如，保險公司的能力通常包括銷售、營銷、承保、理賠處理、開票、合規等。每個業務能力都可以被看作是一種服務，只是它是面向業務的，而非技術性的。

問題

使用業務功能分解應用程式可能是一個很好的開始，但是您會遇到所謂的“上帝類”，它們不容易分解。這些類在多個服務中很常見。例如，Order類將用於Order管理、Order收入、Order交貨等等。我們如何分解它們？

解決方案

對於“上帝類”問題，DDD(領域-驅動 設計)起到了拯救作用。它使用子域和有界上下文概念來解決這個問題。DDD將為企業建立的整個領域模型分解為子領域。每個子域都有一個模型，該模型的作用域稱為有界上下文。每個微服務都將圍繞有界上下文開發。

備註：識別子域並不是一項簡單的任務。這需要對業務有所瞭解。與業務功能一樣，子領域是透過分析業務及其組織結構以及識別不同的專業領域來識別的。

問題

到目前為止，我們討論的設計模式是對greenfield的應用程式進行分解，但是我們所做的80%的工作是對brownfield應用程式進行分解，brownfield應用程式是大型的、單一的應用程式。將上面所有的設計模式應用到它們上是很困難的，因為將它們分解成更小的部分同時使用是一個很大的任務。

解決方案

勒死人的模式來了。勒死人的模式是基於一種藤蔓的類比，藤蔓纏繞著一棵樹。這個解決方案很適合web應用程式，在web應用程式中，一個呼叫來回進行，對於每個URI呼叫，可以將服務分解為不同的域並作為獨立的服務託管。我們的想法是一次做一個領域。這將建立兩個獨立的應用程式，它們並排放在同一個URI空間中。最終，新重構的應用程式將“扼殺”或替換原始應用程式，直到您最終可以關閉單片應用程式為止。

問題

當應用程式分解為更小的微服務時，有幾個問題需要解決：

1. 如何呼叫多個微型服務來提取生產者資訊。

2. 在不同的通道(如桌面、移動裝置和平板電腦)上，應用程式需要不同的資料來響應相同的後端服務，因為UI可能不同。

3. 不同的使用者可能需要不同格式的可重用微服務的響應。誰將進行資料轉換或欄位操作？

4. 如何處理不同型別的協議，有些協議可能不受生產者微服務的支援。

解決方案

API閘道器有助於解決微服務實現引起的許多問題，而不僅僅侷限於上述問題。

1. API閘道器是任何微服務呼叫的單一入口點。

2. 它可以作為代理服務將請求路由到相關的微服務，抽象生產者的詳細資訊。

3. 它可以將請求分散到多個服務，並聚合結果傳送回消費者。

4. 一刀切的api不能解決所有使用者的需求；該解決方案可以為每種特定型別的客戶機建立細粒度的API。

5. 它還可以將協議請求(例如AMQP)轉換為另一個協議(例如HTTP)，反之亦然，以便生產者和消費者能夠處理它。

6. 它還可以減輕微服務的身份驗證/授權責任。

問題

我們已經討論瞭如何解決API閘道器模式中的聚合資料問題。然而，我們將在這裡整體地討論它。在將業務功能分解為幾個較小的邏輯程式碼片段時，有必要考慮如何協作每個服務返回的資料。這種責任不能留給消費者，因為那時它可能需要了解生產者應用程式的內部實現。

解決方案

聚合器模式有助於解決這個問題。它討論了我們如何聚合來自不同服務的資料，然後將最終的響應傳送給消費者。這可以透過兩種方式實現：

1. 複合微服務將呼叫所有所需的微服務，合併資料，並在傳送回之前轉換資料。

2. API閘道器還可以將請求劃分為多個微服務，並在將資料傳送給使用者之前聚合資料。

如果要應用任何業務邏輯，建議選擇組合微服務。否則，API閘道器就是已建立的解決方案。

問題

當透過分解業務功能/子域來開發服務時，負責使用者體驗的服務必須從多個微服務中提取資料。在單片世界中，從UI到後端服務只有一個呼叫來檢索所有資料並重新整理/提交UI頁面。然而，現在情況就不一樣了。我們需要知道怎麼做。

解決方案

使用微服務，UI必須被設計成具有螢幕/頁面的多個部分/區域的骨架。每個部分將呼叫單個後端微服務來提取資料。這被稱為組合特定於服務的UI元件。像AngularJS和ReactJS這樣的框架很容易做到。這些螢幕稱為單頁應用程式(SPA)。這使得應用程式能夠重新整理螢幕的特定區域，而不是整個頁面。