# REL03-BP01 選擇如何劃分工作負載
在確認應用程式的彈性要求時，工作負載劃分是很重要的。應盡可能避免整合型架構。您應審慎考量哪些應用程式元件可分解為微型服務。根據您的應用程式要求，這最終會盡可能由服務導向架構 (SOA) 與微型服務組合而成。可以無狀態的工作負載較有能力部署為微型服務。
**預期成果：** 工作負載應可受支援、可擴展，並且盡可能地鬆散耦合。
在選擇如何劃分工作負載時，請在效益與複雜性之間取得平衡。讓新產品能率先推出的正確做法，不同於打造可從最初需求擴展的工作負載的做法。重構現有的整合型時，您必須考量應用程式如何能支援以無狀態為方向的解構。將服務細分為較小的服務，可讓明確定義的小型團隊加以開發及管理。但較小的服務可能會帶來複雜性，包括延遲可能增加、偵錯更複雜，以及運作負擔增加。
**常見的反模式：**
+ AWS Well-Architected [微型服務 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是一種特定情況：基本元件變得高度互相依賴，以致於只要有其中之一失敗，就會引發更加巨大的失敗，而導致元件像整合型一樣僵固且脆弱。
**建立此實務準則的優勢：**
+ 更明確的劃分可造就更高的靈活性、組織彈性及可擴展性。
+ 降低服務中斷的影響。
+ 應用程式元件可能會有不同的可用性要求，這一點可藉由更細微的劃分來支應。
+ 為支援工作負載的團隊明確定義責任。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
根據劃分工作負載的方式，選擇您的架構類型。選擇 SOA 或微型服務架構 (或在少數情況下選擇整合型架構)。即使您選擇從整合型架構開始，仍須確保該架構為模組化，且隨著使用者採用，產品擴展時，該架構最終可以演進成 SOA 或微型服務。SOA 和微型服務各自提供較小的劃分，這些劃分同時也是偏好使用的現代可擴展且可靠的架構；但在部署微型服務架構時，特別要考慮做一些取捨。
主要取捨之一，就是您現在擁有一種分散式運算架構，而其可能會增加您滿足使用者延遲要求的難度，並且在偵測和追蹤使用者互動方面還存在額外的複雜性。您可以利用 AWS X-Ray 來解決此問題。要考慮的另一個影響是，隨著您管理的應用程式數量增加，營運複雜性也隨之增加，因而需要部署多個獨立元件。
![\[整合型、服務導向與微型服務架構的比較圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 實作步驟
+ 決定適當的架構以重構或建置您的應用程式。SOA 和微型服務各自提供較小的分隔，而這是偏好使用的現代可擴展和可靠架構。SOA 會是達成較小分隔的良好折衷方案，同時能避免微型服務的部分複雜性。如需詳細資訊，請參閱 [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)。
+ 如果您的工作負載適用於此類型，且您的組織可以提供支援，則應使用微型服務架構達成最佳的靈活性和可靠性。如需詳細資訊，請參閱 [實作 AWS 上的微型服務。](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 考慮遵循 [*Strangler Fig* 模式，](https://martinfowler.com/bliki/StranglerFigApplication.html) 將整合型重構為較小的元件。為此，必須逐步將特定的應用程式元件取代為新的應用程式和服務。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 可作為增量重構的起點。如需詳細資訊，請參閱 [「使用扼制模式順暢地遷移內部部署的工作負載」](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)。
+ 實作微型服務時可能需要服務探索機制，讓這些分散式服務能夠彼此通訊。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 可以搭配服務導向架構使用，以提供可靠的服務探索和存取。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 也可用於動態、使用 DNS 的服務探索。
+ 如果您要從整合型遷移至 SOA，[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 可在您於雲端重新設計舊版應用程式時，以服務匯流排的形式消弭差距。
+ 對於具有單一共用資料庫的現有整合型，請選擇如何將資料重新組織為較小的區段。此時可以按業務單位、存取模式或資料結構來劃分。在重構程序的這個時間點，您應選擇以關聯式或非關聯式 (NoSQL) 類型的資料庫繼續操作。如需詳細資訊，請參閱 [「從 SQL 到 NoSQL」](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html)。
**實作計劃的工作量：** 高
## 資源
**相關的最佳實務：**
+ [REL03-BP02 建置專注於特定業務領域和功能的服務](rel_service_architecture_business_domains.md)
**相關文件：**
+ [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [什麼是服務導向架構？](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [有界限的環境 (領域驅動設計的集中模式)](https://martinfowler.com/bliki/BoundedContext.html)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [微型服務 - 此新架構術語的定義](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 上的微型服務](https://aws.amazon.com/microservices/)
+ [什麼是 AWS App Mesh？](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**相關範例：**
+ [迭代應用程式現代化研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**相關影片：**
+ [透過 AWS 上的微型服務提供卓越品質](https://www.youtube.com/watch?v=otADkIyugzY)