REL03-BP01 選擇如何劃分工作負載
在確認應用程式的彈性要求時，工作負載劃分是很重要的。應盡可能避免整合型架構。您應審慎考量哪些應用程式元件可分解為微型服務。根據您的應用程式要求，這最終會盡可能由服務導向架構 (SOA) 與微型服務組合而成。可以無狀態的工作負載較有能力部署為微型服務。
預期成果： 工作負載應可受支援、可擴展，並且盡可能地鬆散耦合。
在選擇如何劃分工作負載時，請在效益與複雜性之間取得平衡。讓新產品能率先推出的正確做法，不同於打造可從最初需求擴展的工作負載的做法。重構現有的整合型時，您必須考量應用程式如何能支援以無狀態為方向的解構。將服務細分為較小的服務，可讓明確定義的小型團隊加以開發及管理。但較小的服務可能會帶來複雜性，包括延遲可能增加、偵錯更複雜，以及運作負擔增加。
常見的反模式：
-
AWS Well-Architected 微型服務 Death Star
是一種特定情況：基本元件變得高度互相依賴，以致於只要有其中之一失敗，就會引發更加巨大的失敗，而導致元件像整合型一樣僵固且脆弱。
建立此實務準則的優勢：
-
更明確的劃分可造就更高的靈活性、組織彈性及可擴展性。
-
降低服務中斷的影響。
-
應用程式元件可能會有不同的可用性要求，這一點可藉由更細微的劃分來支應。
-
為支援工作負載的團隊明確定義責任。
未建立此最佳實務時的曝險等級： 高
實作指引
根據劃分工作負載的方式，選擇您的架構類型。選擇 SOA 或微型服務架構 (或在少數情況下選擇整合型架構)。即使您選擇從整合型架構開始，仍須確保該架構為模組化，且隨著使用者採用，產品擴展時，該架構最終可以演進成 SOA 或微型服務。SOA 和微型服務各自提供較小的劃分，這些劃分同時也是偏好使用的現代可擴展且可靠的架構；但在部署微型服務架構時，特別要考慮做一些取捨。
主要取捨之一，就是您現在擁有一種分散式運算架構，而其可能會增加您滿足使用者延遲要求的難度，並且在偵測和追蹤使用者互動方面還存在額外的複雜性。您可以利用 AWS X-Ray 來解決此問題。要考慮的另一個影響是，隨著您管理的應用程式數量增加，營運複雜性也隨之增加，因而需要部署多個獨立元件。
整合型、服務導向與微型服務架構
實作步驟
-
決定適當的架構以重構或建置您的應用程式。SOA 和微型服務各自提供較小的分隔，而這是偏好使用的現代可擴展和可靠架構。SOA 會是達成較小分隔的良好折衷方案，同時能避免微型服務的部分複雜性。如需詳細資訊，請參閱 微型服務權衡
。 -
如果您的工作負載適用於此類型，且您的組織可以提供支援，則應使用微型服務架構達成最佳的靈活性和可靠性。如需詳細資訊，請參閱 實作 AWS 上的微型服務。
-
考慮遵循 Strangler Fig 模式，
將整合型重構為較小的元件。為此，必須逐步將特定的應用程式元件取代為新的應用程式和服務。AWS Migration Hub Refactor Spaces 可作為增量重構的起點。如需詳細資訊，請參閱 「使用扼制模式順暢地遷移內部部署的工作負載」 。 -
實作微型服務時可能需要服務探索機制，讓這些分散式服務能夠彼此通訊。AWS App Mesh 可以搭配服務導向架構使用，以提供可靠的服務探索和存取。 AWS Cloud Map
也可用於動態、使用 DNS 的服務探索。 -
如果您要從整合型遷移至 SOA，Amazon MQ 可在您於雲端重新設計舊版應用程式時，以服務匯流排的形式消弭差距。
-
對於具有單一共用資料庫的現有整合型，請選擇如何將資料重新組織為較小的區段。此時可以按業務單位、存取模式或資料結構來劃分。在重構程序的這個時間點，您應選擇以關聯式或非關聯式 (NoSQL) 類型的資料庫繼續操作。如需詳細資訊，請參閱 「從 SQL 到 NoSQL」。
實作計劃的工作量： 高
資源
相關的最佳實務：
相關文件：
相關範例：
相關影片：
