資料庫管理

微服務和單體應用如何影響資料庫

應用程式架構最常見的兩種方法是單體應用架構（功能由一個大型應用程式提供）和微服務架構（功能被拆分為相互協調的小單元）。這些設計選擇在開發體驗、部署便利性和運營足跡方面都會產生深遠的影響。

應用程式架構影響您的環境的最重要方式之一是它如何影響您使用資料庫的方式。應用程式結構通常會影響資料結構，還會影響資料的儲存位置和操作方式。在本指南中，我們將討論單體應用和微服務之間的區別，特別是這些決策如何影響您的資料庫。

在軟體開發中，單體應用和微服務都描述了應用程式架構。

單體應用是傳統的應用程式開發和部署方式。在單體設計中，執行有用工作所需的大部分處理、通訊和協調都在單個應用程式內部發生。應用程式與外部世界互動，接收來自使用者的輸入和命令（很多時候透過 Web 伺服器端點公開），並與資料庫等其他服務互動。

單體應用之所以流行，是因為它們遵循成熟的開發模式，並擁有大量的工具集，可以幫助進行除錯和故障排除。單體應用的整合性也使得在運營環境中部署和管理相對簡單。儘管不同團隊在同一個應用程式上工作時必須謹慎協調更改，但涉及的元件數量相對較少。

話雖如此，使用一個單一的、包羅永珍的應用程式也可能有很多缺點。應用程式開發必須緊密協調，以確保與特定功能相關的所有程式碼保持一致。當整個應用程式必須擴充套件以滿足不同需求時，擴充套件也可能極具挑戰性，特別是在需要執行多個副本時，應用程式可能不具備協調所需的介面或邏輯。

微服務是一種替代的應用程式架構方法，它涉及將應用程式的功能拆分為許多離散的“服務”。這些服務各自擁有明確定義的職責，並透過網路相互協調以完成有用的工作。從某種意義上說，微服務是一種開發風格，它分解應用程式並將內部通訊重新實現為網路通訊。

人們選擇微服務而非單體應用有諸多原因。微服務允許您根據單個服務的效能和負載特性獨立擴充套件服務。除了可伸縮性本身的好處之外，在不同主機上執行小型元件的多個副本可以提高應用程式的彈性，有助於確保硬體故障不會導致停機。

這種靈活性使您能夠解耦不僅是各個元件的擴充套件，還有開發本身。不同的服務可以使用完全不同的語言構建，只要它們提供其他元件可以通訊的介面。這會對團隊對元件的“所有權”體驗產生深遠影響，並帶來快速迭代甚至完全重寫服務而不影響其他領域的好處。

微服務也帶來了自身的挑戰。例如，部署和管理大量服務的操作複雜性可能令人難以承受，特別是如果您的團隊沒有強大的運維背景。服務間通訊的重要性增加了網路層面臨的需求複雜性和流量。同時，由於傳統工具在分散式環境中通常不適用，除錯和測試也變得更加困難。

上述架構選項對開發過程以及在生產環境中操作應用程式的體驗產生了深遠影響。其中一個特別受影響的元件是資料庫。

單體應用通常部署有集中式資料庫。應用程式可能會將讀取操作傳遞給副本以更均勻地分配負載，但通常情況下，所有資料都集中在一個地方。在這種情況下，集中式資料庫負責管理與許多不同應用程式上下文和功能相關聯的資訊。

然而，微服務通常與更復雜的資料環境相結合。單個微服務通常與自己的資料庫例項一起部署，這些例項僅負責管理該特定服務的資料，別無他求。

這種模式之所以流行，是因為它允許開發人員獨立迭代和部署每個微服務。開發中最大的協調點之一是修改資料庫的程式碼，因為更改可能會影響應用程式的許多不同部分。如果一個團隊更改了資料庫模式，它可能會破壞旨在預期先前模式的功能。

為每個微服務配備自己的資料庫可以解耦這種級聯效應，這樣開發人員可以在更少的協調下，更有信心地進行所需的更改。這進一步實現了將服務作為離散的、專注的元件進行管理的目標，這些元件僅透過明確定義的介面相互互動。

然而，每個微服務一個數據庫的模式並非沒有自身的挑戰。隨著微服務數量的增加，單個數據儲存的數量也隨之增加。操作要求也成倍增加，因為團隊現在必須為每個新服務管理資料庫部署、備份、故障轉移和其他問題。如果沒有完善的工具和專業知識，這會很快變得難以管理。

開發人員還必須弄清楚如何協調可能涉及多個微服務的查詢和更新。例如，如果正在下訂單，客戶資料、庫存資料和訂單資訊本身可能由不同的微服務管理。

微服務模式可以幫助您擴充套件應用程式，並使作為組織的某些開發和部署任務更易於協調。它可以幫助您更快地迭代和釋出更改，同時限制新程式碼對應用程式其他部分的影響。

重要的是要了解您的架構選擇將如何影響開發過程、基礎設施和運營要求的不同部分。在微服務的情況下，資料庫環境通常與單體部署大相徑庭。重要的是要了解要預期的變化以及如何管理挑戰以保持生產力。

Justin 自 2013 年以來一直撰寫有關資料庫、Linux、基礎設施和開發者工具的文章。他目前和妻子以及兩隻兔子住在柏林。他通常不必使用第三人稱寫作，這對所有相關方來說都是一種解脫。