簡介
應用程式架構最常見的兩種方法是單體應用程式（功能由單一大型應用程式提供）和微服務架構（功能拆分為協調運作的小單元）。這些設計選擇可能會對開發體驗、部署的便利性和營運足跡產生深遠的影響。
應用程式架構影響環境的最重要方式之一是它如何影響您使用資料庫的方式。應用程式結構通常會影響資料結構，也會影響資料的儲存位置以及如何對其進行操作。在本指南中，我們將討論單體架構和微服務之間的差異，特別是這些決策如何影響您的資料庫。
查看 Prisma 資料平台，在單一位置管理您的所有應用程式資料。
什麼是單體架構和微服務？
在軟體開發中，單體架構和微服務都描述了應用程式架構。
單體應用程式
單體應用程式是傳統的應用程式開發和部署風格。在單體設計中，執行有用的工作所需的大部分處理、通訊和協調都發生在單一應用程式內部。應用程式與外部世界介接，以接收來自使用者的輸入和命令（通常透過網頁伺服器端點公開），並與資料庫等其他服務互動。
單體架構之所以受歡迎，是因為它們遵循廣為人知的開發模式，並且擁有大量的工具套件，可以協助進行偵錯和疑難排解。單體應用程式的整合特性也使其在營運環境中相對容易部署和管理。雖然在不同團隊處理同一個應用程式時，必須注意協調變更，但活動部件的數量相對較少。
話雖如此，使用單一全方位應用程式也可能存在許多缺點。應用程式開發必須緊密協調，以確保與特定功能相關的所有程式碼彼此保持同步。當必須擴展整個應用程式以滿足不同需求時，擴展也可能非常具有挑戰性，尤其因為應用程式可能沒有協調所需的介面或邏輯（如果必須執行多個副本）。
微服務
微服務是一種替代方法，用於架構應用程式，其中涉及將應用程式的功能拆分為許多離散的「服務」。這些服務各自具有明確定義的職責，並透過網路相互協調以完成有用的工作。從某種意義上說，微服務是一種開發風格，它分解應用程式並將內部通訊重新實作為網路通訊。
人們選擇微服務而不是單體應用程式有很多原因。微服務可讓您根據個別效能和負載特性獨立擴展服務。除了擴展性本身的優點之外，跨各種主機執行多個小型元件副本還可以提高應用程式的彈性，以協助確保硬體故障不會導致停機。
這種彈性讓您可以不僅將各種元件的擴展分離開來，還可以將開發本身分離開來。可以使用完全不同的語言來建構不同的服務，只要它們提供其他元件可以與之通訊的介面即可。這可能會對團隊對元件的「所有權」體驗產生深遠的影響，並帶來諸如快速迭代甚至完全重寫服務而不會影響其他區域的能力等優點。
微服務也帶來了自身的挑戰。例如，部署和管理大量服務的營運複雜性可能會讓人難以承受，尤其是在您的團隊沒有強大的營運背景的情況下。服務間通訊的重要性增加了對網路層提出的需求和流量的複雜性。同時，偵錯和測試變得更加困難，因為傳統工具通常不適用於分散式環境。
微服務如何影響資料庫架構？
上面討論的架構選項對開發流程的外觀以及在生產環境中營運應用程式的方式產生了深遠的影響。其中一個可能受到特別影響的元件是資料庫。
單體應用程式通常與集中式資料庫一起部署。應用程式可能會將讀取操作傳遞給複本，以更均勻地分散負載，但一般而言，資料都位於一個位置。在這種情況下，集中式資料庫負責管理與許多不同應用程式上下文和功能相關的資訊。
然而，微服務通常與更複雜的資料環境結合在一起。個別微服務通常與它們自己的資料庫實例一起部署，這些實例負責管理該特定服務的資料，僅此而已。
使用服務專用資料庫的優點和缺點
這種模式之所以受歡迎，是因為它允許開發人員獨立迭代和部署每個微服務。開發中最大的協調點之一是修改資料庫的程式碼，因為變更可能會影響應用程式的許多不同部分。如果一個團隊變更了資料庫綱要，則可能會破壞旨在預期先前綱要的功能。
為每個微服務提供自己的資料庫可以解耦這種級聯效應，以便開發人員可以在減少協調並增加信心的情況下進行所需的變更。它進一步實現了將服務作為離散、重點明確的元件進行管理的目標，這些元件僅透過明確定義的介面相互互動。
然而，每個微服務一個資料庫的模式並非沒有自身的挑戰。隨著微服務數量的增加，個別資料儲存區的數量也隨之增加。營運需求成倍增加，因為團隊現在必須為每個新服務管理資料庫部署、備份、容錯移轉和其他問題。如果沒有完善的工具和專業知識，這可能會很快變得難以管理。
開發人員還必須弄清楚如何協調可能接觸多個微服務的查詢和更新。例如，如果要下訂單，客戶的資料、庫存資料和訂單資訊本身可能由不同的微服務管理。
結論
微服務模式可以協助您擴展應用程式，並可以使組織更輕鬆地協調某些開發和部署任務。它可以協助您更快地迭代和發布變更，同時限制新程式碼對應用程式其他部分的影響。
務必了解您選擇的架構將如何影響開發流程、基礎架構和營運需求的不同部分。就微服務而言，資料庫環境通常與單體部署非常不同。務必了解要預期的變更以及如何管理挑戰以維持生產力。
查看 Prisma 資料平台，在單一位置管理您的所有應用程式資料。
