在分解單體應用程序到微服務體系架構時，重點考慮獨立數據庫拆分是很重要的。您需要想出一個可靠的策略，將您的數據庫分割為多個與應用程序對齊的小型數據庫。簡而言之，您需要將您的應用程序/服務從使用單一的共享數據庫中拆分出來。
您應該以這樣一種方式設計您的微服務體系結構，即每個單獨的微服務都有自己的獨立數據庫和自己的領域數據。這將允許您獨立部署和擴展微服務。
傳統的應用程序只有一個共享的數據庫，數據通常在不同的組件之間共享。我們都使用過這樣的數據庫，並且發現開發更簡單，因為數據存儲在一個存儲庫中。但是這種數據庫設計存在很多問題。
共享單個數據缺點
1、為多個服務提供單個數據庫的傳統設計造成了緊密耦合，並且無法獨立部署服務更改。如果有多個服務訪問同一個數據庫，那麼任何模式更改都需要在所有服務之間進行協調，這在現實世界中可能會導致部署更改的額外工作和延遲。
2、使用這種設計很難擴展單個服務，因為您只能選擇擴展整個單塊數據庫。
3、提高應用程序性能成為一個挑戰。使用一個共享數據庫，在一段時間內，您最終會得到一個巨大的表。這使得數據檢索變得困難，因為您必須連接多個大型表來獲取所需的數據。
4、大多數情況下，關係存儲是作為整體數據庫的。這限制了所有服務使用關係數據庫。然而，在某些情況下，無sql數據存儲可能更適合您的服務，因此您不希望與集中式數據存儲緊密耦合。
如何在微服務體系結構中管理數據
每個微服務都應該有自己的數據庫，並且應該包含與該微服務本身相關的數據。這將允許您獨立部署單個服務。單個團隊現在可以擁有相應微服務的數據庫。
微服務應該遵循領域驅動設計並具有有限的上下文。您需要基於領域來設計應用程序，領域與應用程序的功能是一致的。這就像遵循代碼優先方法而不是數據優先方法一樣——因此您首先設計模型。這是一種與傳統的在開始處理新需求或新項目時首先設計數據庫表的方法完全不同的方法。您應該始終努力保持業務模型的完整性。
在設計數據庫時，查看應用程序功能並確定它是否需要關係模式。如果NoSQL數據庫符合您的標準，請保持對它的開放態度。
數據庫應該被視為每個微服務的私有數據庫。沒有其他微服務可以直接修改存儲在另一個微服務中的數據庫中的數據。
在下圖中，訂單服務不能直接更新定價數據庫，只能通過微服務API訪問。這有助於您實現不同服務之間的一致性。
事件驅動架構是在不同服務之間維護數據一致性的通用模式。與等待ACID事務完成處理並佔用系統資源不同，您可以通過將消息卸載到隊列中來提高應用程序的可用性和性能。這提供了服務之間的鬆散耦合。
隊列的消息可以被視為事件，並且可以遵循發佈-子模型。發佈者發佈消息，而不知道已經訂閱了事件流的使用者。體系結構中組件之間的鬆散耦合可以構建高度可伸縮的分佈式系統。
在從單體架構到微服務的過程中處理數據庫更改是一項挑戰。在本文中，我們瞭解了單體數據庫設計的問題，以及如何在微服務體系結構中處理數據。
閱讀更多 程序你好 的文章
