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