此內容已過時。這個版本的 Well-Architected 框架現在可以在以下位置找到： https://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/reliability.html

REL 3: 如何設計您的工作負載服務架構？

使用服務導向架構 (SOA) 或微型服務架構，建置擴展性與可靠性高的工作負載。服務導向架構 (SOA) 是透過服務界面讓軟體元件可重複使用的做法。微型服務架構則進一步讓元件變得更小、更簡單。

資源

選擇如何劃分工作負載: 應避免整合型架構。反之，您應在 SOA 與微型服務之間做出選擇。做出各種選擇時，請在效益與複雜性之間取得平衡，即讓新產品能率先推出的正確做法不同於打造可從最初需求擴展的工作負載的做法。使用較小的區段的優勢包括更高的靈活性、組織彈性及擴展性。複雜情況包括延遲可能增加、偵錯更複雜，以及運作負擔增加
建置專注於特定業務領域和功能的服務: SOA 會建置具有依業務需求定義之明確描述功能的服務。微型服務運用領域模型和有界限的環境來對此項業務進一步限縮，因此各服務僅做一件事。專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。
每個 API 都提供服務合約: 服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。版本控制策略可讓用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。只要不違反合約，隨時都可進行部署。服務供應商團隊可以使用自己選擇的技術堆疊，以滿足 API 合約要求。同樣地，服務取用者可以使用自有的技術。

選擇如何劃分工作負載

根據劃分工作負載的方式，選擇您的架構類型: 選擇服務導向架構 (SOA) 或微型服務架構 (或在某些情況下選擇整合型架構)。

SOA 和微型服務各自提供較小的分隔，而這是偏好使用的現代可擴展和可靠架構。但如果您有充分的理由選擇整合型架構，則仍須確保該架構為模組化，且隨著使用者採用，產品擴展時，該架構擁有最終會演進成 SOA 或微型服務的能力。
SOA 會是達成較小分隔的良好折衷方案，同時能避免微型服務的部分複雜性。
Microservice Trade-Offs
如果您的工作負載適用於此類型，且您的組織可以提供支援，則應使用微型服務架構達成最佳的靈活性和可靠性。
Implementing Microservices on AWS
AWS App Mesh 可以搭配服務導向架構使用，以提供可靠的服務探索和存取。
What is AWS App Mesh?

建置專注於特定業務領域和功能的服務

根據您的業務領域及其各自功能設計工作負載: 專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。

將您的服務分解為最小的元件: 您可以使用微型服務架構，將工作負載劃分具有最小的功能的多個元件，以實現組織擴展和敏捷性。

每個 API 都提供服務合約

每個 API 都提供服務合約: 服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。
Amazon API Gateway: Configuring a REST API Using OpenAPI

版本控制策略可讓用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。
Amazon API Gateway 是一種全受管的服務，可讓開發人員輕鬆地建立任何規模的 API。您可以使用 OpenAPI Specification (OAS) (先前稱為 Swagger Specification)，定義 API 合約並將其匯入至 API Gateway。您之後可以使用 API Gateway 進行 API 的版本控制和部署作業。