識別微服務界限
微服務的大小正確為何？ 你經常聽到一些效果的東西，“不是太大，不是太小”-雖然這當然是正確的，但它在實踐中並不非常有説明。 但是，如果您從精心設計的領域模型開始，就更容易推理微服務。
本文使用無人機遞送服務作為執行中的範例。 您可以 在這裡深入瞭解案例和對應的參考實作。
從領域模型到微服務
在 上一篇文章中，我們定義了無人機遞送應用程式的一組限定內容。 然後，我們更仔細地查看其中一個系結內容、出貨界限內容，並識別出該界限內容的一組實體、匯總和網域服務。
現在我們已經準備好從領域模型移至應用程式設計。 以下是可用來從領域模型衍生微服務的方法。
從限定內容開始。 一般而言，微服務中的功能不應跨越一個以上的限定內容。 根據定義，限定的內容會標示特定領域模型的界限。 如果您發現微服務將不同的領域模型混合在一起，這表示您可能需要返回並精簡您的定義域分析。
接下來，查看領域模型中的匯總。 匯總通常是微服務的良好候選專案。 設計良好的匯總會展示設計完善的微服務的許多特性，例如：
- 匯總衍生自商務需求，而不是技術考慮，例如數據存取或傳訊。
- 匯總應該具有較高的功能凝聚力。
- 匯總是持續性的界限。
- 匯總應該以鬆散方式結合。
網域服務也是微服務的良好候選專案。 網域服務是跨多個匯總的無狀態作業。 典型的範例是涉及數個微服務的工作流程。 我們將在無人機遞送應用程式中看到這一點的範例。
最後，請考慮非功能性需求。 查看小組大小、數據類型、技術、延展性需求、可用性需求和安全性需求等因素。 這些因素可能會導致您進一步將微服務分解成兩個或多個較小的服務，或執行相反動作，並將數個微服務合併成一個。
識別應用程式中的微服務之後，請根據下列準則來驗證您的設計：
- 每個服務都有單一責任。
- 服務之間沒有閒聊的通話。 如果將功能分割成兩個服務會導致它們過於閒聊，則可能是這些函式屬於相同服務的徵兆。
- 每個服務都足夠小，可由獨立工作的小型小組所建置。
- 沒有任何相依性需要兩個或多個服務部署在鎖定步驟中。 一律可以部署服務，而不需重新部署任何其他服務。
- 服務不會緊密結合，而且可以獨立發展。
- 您的服務界限不會造成數據一致性或完整性的問題。 有時候，藉由將功能放入單一微服務，維護數據一致性非常重要。 話又說，請考慮您是否真的需要強式一致性。 分散式系統中有解決最終一致性的策略，而分解服務的優點通常超過管理最終一致性的挑戰。
最重要的是，請務必務實，並記住網域驅動設計是反覆的過程。 如有疑問，請從更粗略的微服務開始。 將微服務分割成兩個較小的服務比重構數個現有微服務的功能更容易。
範例：定義無人機遞送應用程式的微服務
回想一下，開發小組已識別出四個匯總：傳遞、套件、無人機和帳戶，以及兩個網域服務，排程器和主管。
傳遞和套件是微服務的明顯候選專案。 排程器和監督員會協調其他微服務所執行的活動，因此實作這些網域服務作為微服務是合理的。
無人機和帳戶很有趣，因為它們屬於其他限定內容。 其中一個選項是讓排程器直接呼叫無人機和帳戶限定內容。 另一個選項是在出貨界限內容內建立無人機和帳戶微服務。 這些微服務會藉由公開更適合出貨內容的 API 或數據架構，在界限內容之間調解。
無人機和帳戶限定內容的詳細數據超出本指南的範圍，因此我們在參考實作中為其建立模擬服務。 但在此情況下，以下是需要考慮的一些因素：
直接呼叫至其他界限內容的網路額外負荷為何？
另一個限定內容的數據架構是否適合此內容，或者最好有針對這個限定內容量身打造的架構？
另一個系結內容是否為舊版系統？ 若是如此，您可能會建立可做為 反損毀層 的服務，以在舊版系統與新式應用程式之間進行轉譯。
小組結構為何？ 與負責其他限定內容的小組通訊是否很容易？ 如果沒有，建立在兩個內容之間調解的服務，有助於降低跨小組通訊的成本。
到目前為止，我們還沒有考慮任何非功能性需求。 思考應用程式的輸送量需求，開發小組決定建立個別的擷取微服務，負責內嵌用戶端要求。 此微服務會將傳入要求放入緩衝區進行處理，以實作 負載撫平 。 排程器會從緩衝區讀取要求，並執行工作流程。
非功能性需求導致小組建立一項額外的服務。 到目前為止，所有服務都是關於即時排程和傳遞套件的程式。 但系統也需要將每個傳遞的歷程記錄儲存在長期記憶體中，以進行數據分析。 小組考慮將此視為傳遞服務的責任。 不過，對於歷程分析與進行中的作業，數據儲存需求大不相同（請參閱 數據考慮）。 因此，小組決定建立個別的傳遞歷程記錄服務，以接聽傳遞服務的 DeliveryTracking 事件，並將事件寫入長期記憶體。
下圖顯示此時的設計：
下載此架構的 Visio 檔案。
後續步驟
此時，您應該清楚了解設計中每個微服務的用途和功能。 現在您可以建構系統。