微服務解耦設計模式 - Neeraj

如果你正在開發一個大型的、複雜的應用程式，或者正在拆除一個單體的應用程式，你應該考慮微服務架構。微服務架構將一個應用結構為一系列鬆散耦合的服務。微服務旨在通過實現持續交付和部署來加速軟體開發。

在微服務下，有兩種型別的專案。

• 棕地專案--它指的是在現有或遺留系統的背景下開發和部署一個新的軟體系統。因此，將一個單體應用轉換為微服務就屬於這個專案。
• 綠地專案 - 這涉及到為一個全新的環境從頭開始建立一個系統，沒有任何遺留程式碼可供利用。當你從零開始，沒有任何限制或依賴性時使用的一種方法。

按子領域模式分解

領域驅動設計（DDD）方法是一種建立複雜軟體應用程式的方式，它是基於物件導向的領域模型的開發。DDD為每個子域定義了單獨的領域模型。每個子域都屬於一個領域。識別子域與識別業務能力的過程相同，即分析業務和識別專業領域。最有可能的是，最終的結果將是業務熟悉的子域。領域模型的範圍在DDD中被稱為有界上下文。有界上下文包括實現模型的程式碼工件。

子域可以分類如下

• 核心--企業最大的差異化因素，也是應用中最有價值的部分。
• 支援 - 不是一個差異化因素，但與企業提供的服務有關。通常是內部實施或外包。
• 通用 - 不針對業務，最好使用現成的軟體來實施。

這種模式有以下好處

• 子域是相對穩定的，所以架構是穩定的。
• 我們的開發團隊是跨職能的、自主的，並且專注於交付業務價值而不是技術功能。
• 服務是鬆散的耦合和內聚的。

將單體應用分解為微服務時面臨的挑戰

在分解單體應用時，可能會出現一些挑戰。

• 網路延遲--在一個分散式系統中，網路延遲是一個持續的問題。你可能會發現，對服務的特定分解會導致兩個服務之間出現大量的往返次數。
• 保持跨服務的資料一致性 - 每個服務都會有自己的資料庫，所以保持跨服務的資料一致性會很困難。
• 上帝類--上帝類是控制系統中太多其他物件的物件，它超越了邏輯，成長為做所有事情的類。由於其規模和複雜性，它是一個集中了系統智慧的類，並使用其他類的資訊。

Strangler模式

當把傳統的單體應用遷移到微服務架構中時，會使用Strangler模式。通過使用這種模式，單體應用可以通過用新的服務取代特定的功能而逐步轉變。一旦新的服務準備就緒，舊的元件就會被扼殺，新的服務就會投入使用，而舊的元件就會退役。