將整體分解為微服務 - AWS 方案指引
目標業務成果

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

將整體分解為微服務

Tabby Ward 和 Dmitry Gulin，Amazon Web Services (AWS)

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

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

現代化通常涉及兩種類型的專案：

  • 布朗菲爾德專案涉及在現有或舊版系統的環境中開發和部署新的軟體系統。

  • Greenfield 專案涉及從頭開始為全新的環境建立系統，而不涉及任何舊版程式碼。

對於布朗欄位專案，應用程式現代化旅程中的第一個步驟之一是將產品組合中的整體分解為微服務。

大多數應用程式一開始都是針對特定商業使用案例所設計的單體。如果單體的架構未強制執行模組化設計，則單體對於在成熟網域知識範圍內沒有明確定義責任的應用程式，仍然是有效的選擇。整體做為單一部署單位的中心特性也有助於減輕設計瑕疵，例如緊密耦合或缺乏內部結構。

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

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

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

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

本指南是內容系列的一部分，涵蓋 建議的應用程式現代化方法 AWS。系列也包含：

目標業務成果

將整體分解為微服務後，您應該預期以下結果：

  • 將單體應用程式高效轉換為微服務架構。

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

  • 加快創新速度，因為每個微服務都可以個別測試和部署。