將巨石分解為微服務 - AWS 規定指引
目標業務成果

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

將巨石分解為微服務

虎斑沃德和梅德古林, Amazon Web Services (AWS)

2023 年 4 月 (文件歷史記錄)

遷移到 Amazon Web Services (AWS) 雲端具有許多優勢，包括技術和業務敏捷性、新的收益機會以及降低成本。若要充分利用這些優勢，您應該透過將整合式應用程式重構為微服務，持續將組織的軟體現代化。此過程包括三個主要步驟：

現代化通常涉及兩種類型的項目：

  • Brownfield 項目涉及在現有或傳統系統的背景下開發和部署新的軟件系統。

  • Greenfield 項目涉及從頭開始創建一個全新的環境系統，而不涉及任何遺留代碼。

對於棕地專案，應用程式現代化旅程的第一個步驟之一就是將投資組合中的重點分解為微服務。

大部分的應用程式都是以專為特定商業使用案例所設計的巨石開始。如果整體架構不強制執行模塊化設計，那麼對於沒有在完善的領域知識範圍內明確定義責任的應用程序來說，整體式可能仍然是有效的選擇。整體式作為單一部署單元的核心特性也有助於減輕設計缺陷，例如緊密耦合或缺乏內部結構。

雖然整體可以是某些用例的有效選項，但它通常不適合現代應用程序。巨體的內部結構定義不佳，可能會使程式碼維護變得困難，這會為新開發人員創造陡峭的學習曲線，並造成額外的支援成本。高耦合度和低凝聚力可以顯著增加新功能所需的時間，並且您可能無法根據流量模式擴展個別元件。Monoliths 還需要多個團隊協調一個大型版本，從而增加了協作和知識轉移負擔。最後，您會發現，當您的業務或用戶群成長時，添加新功能或構建新的用戶體驗變得困難。

為了避免這種情況，您可以使用分解模式來分解整體應用程式、將它們轉換為數個微服務，然後將它們遷移到微服務架構。微服務架構將應用程式結構為一系列鬆散耦合的服務。微服務旨在透過持續交付和持續部署 (CI/CD) 程序來加速軟體開發。

在開始分解過程之前，您應該評估要分解哪些巨石。請務必包含具有可靠性或效能問題的巨石，或在緊密結合的架構中包含多個元件。我們也建議您完全瞭解整體的商業使用案例、其技術，以及其與其他應用程式之間的相依性。

本指南適用於應用程式擁有者、企業擁有者、架構師、技術主管和專案經理。它討論了以下六種用於分解巨石的雲端原生模式，並描述了每種模式的優缺點：

本指南是內容系列的一部分，其中涵蓋了建議的應用程式現代化方法AWS。該系列還包括：

目標業務成果

在將您的巨石分解為微服務之後，您應該期待以下結果：

  • 將您的整合式應用程式有效轉換為微服務架構。

  • 快速調整不斷波動的業務需求，而不會中斷核心活動，例如高擴展性、改善彈性、持續交付和故障隔離。

  • 更快的創新，因為每個微服務都可以單獨測試和部署。