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