# REL 3  如何設計您的工作負載服務架構？
<a name="w2aac19b9b7b5"></a>

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

**Topics**
+ [REL03-BP01 選擇如何劃分工作負載](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 建置專注於特定業務領域和功能的服務](rel_service_architecture_business_domains.md)
+ [REL03-BP03 每個 API 都提供服務合約](rel_service_architecture_api_contracts.md)

# REL03-BP01 選擇如何劃分工作負載
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 在確認應用程式的彈性要求時，工作負載劃分是很重要的。應盡可能避免整合型架構。您應審慎考量哪些應用程式元件可分解為微型服務。根據您的應用程式要求，這最終會盡可能由服務導向架構 (SOA) 與微型服務組合而成。可以無狀態的工作負載較有能力部署為微型服務。 

 **預期成果：** 工作負載應可受支援、可擴展，並且盡可能地鬆散耦合。 

 在選擇如何劃分工作負載時，請在效益與複雜性之間取得平衡。讓新產品能率先推出的正確做法，不同於打造可從最初需求擴展的工作負載的做法。重構現有的整合型時，您必須考量應用程式如何能支援以無狀態為方向的解構。將服務細分為較小的服務，可讓明確定義的小型團隊加以開發及管理。但較小的服務可能會帶來複雜性，包括延遲可能增加、偵錯更複雜，以及運作負擔增加。 

 **常見的反模式：** 
+  AWS Well-Architected [微型服務 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是一種特定情況：基本元件變得高度互相依賴，以致於只要有其中之一失敗，就會引發更加巨大的失敗，而導致元件像整合型一樣僵固且脆弱。

 **建立此實務準則的優勢：** 
+  更明確的劃分可造就更高的靈活性、組織彈性及可擴展性。 
+  降低服務中斷的影響。 
+  應用程式元件可能會有不同的可用性要求，這一點可藉由更細微的劃分來支應。 
+  為支援工作負載的團隊明確定義責任。 

 **未建立此最佳實務時的曝險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>

 根據劃分工作負載的方式，選擇您的架構類型。選擇 SOA 或微型服務架構 (或在少數情況下選擇整合型架構)。即使您選擇從整合型架構開始，仍須確保該架構為模組化，且隨著使用者採用，產品擴展時，該架構最終可以演進成 SOA 或微型服務。SOA 和微型服務各自提供較小的劃分，這些劃分同時也是偏好使用的現代可擴展且可靠的架構；但在部署微型服務架構時，特別要考慮做一些取捨。 

 主要取捨之一，就是您現在擁有一種分散式運算架構，而其可能會增加您滿足使用者延遲要求的難度，並且在偵測和追蹤使用者互動方面還存在額外的複雜性。您可以利用 AWS X-Ray 來解決此問題。要考慮的另一個影響是，隨著您管理的應用程式數量增加，營運複雜性也隨之增加，因而需要部署多個獨立元件。 

![\[整合型、服務導向與微型服務架構的比較圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)


## 實作步驟
<a name="implementation-steps"></a>
+  決定適當的架構以重構或建置您的應用程式。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)。

 **實作計劃的工作量：** 高 

## 資源
<a name="resources"></a>

 **相關的最佳實務：** 
+  [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) 

# REL03-BP02 建置專注於特定業務領域和功能的服務
<a name="rel_service_architecture_business_domains"></a>

 服務導向架構 (SOA) 會建置具有依業務需求定義之明確描述功能的服務。微型服務運用領域模型和有界限的環境來對此項業務進一步限縮，因此各服務僅做一件事。專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。 

 在設計微型服務架構的過程中，運用領域驅動設計 (DDD) 有助於使用實體建立業務問題模型。例如，對於 Amazon.com 網站而言，實體可能包括包裝、交付、時間表、價格、折扣和貨幣。然後運用 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)，將此模型進一步劃分成更小的模型，其中具有相似功能和特性的實體歸類成一組。因此，以 Amazon.com 為例，包裝、交付及時間表會是出貨環境的一環，而價格、折扣及貨幣則是定價環境的一環。隨著此模型劃分成多個環境，如何界定微型服務界限的範本便會浮現。 

![\[如何界定微型服務的模型範本\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/building-services.png)


 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  根據您的業務領域及其各自功能設計工作負載。專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。 
  +  進行領域分析，以便對應工作負載的領域驅動設計 (DDD)。然後您可以選擇符合工作負載需求的架構類型。
    +  [如何整合型服務分成微型服務](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
    +  [遭到舊式系統包圍時開始使用 DDD](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
    +  [Eric Evans「領域驅動設計：解決軟件核心的複雜性」](https://www.amazon.com/gp/product/0321125215) 
    +  [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+ 將您的服務分解為最小的元件。您可以使用微型服務架構，將工作負載劃分具有最小的功能的多個元件，以實現組織擴展和敏捷性。
  +  定義工作負載的 API 及其設計目標、限制和其他使用考量。
    +  定義 API。
      +  API 定義應考慮增長和其他參數。 
    +  定義設計的可用性。
      + 您的 API 可能針對不同功能具有多個設計目標。
    +  建立限制 
      +  使用測試來定義工作負載功能的限制。

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [有界限的環境 (領域驅動設計的集中模式)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Eric Evans「領域驅動設計：解決軟件核心的複雜性」](https://www.amazon.com/gp/product/0321125215) 
+  [遭到舊式系統包圍時開始使用 DDD](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+  [如何整合型服務分成微型服務](https://martinfowler.com/articles/break-monolith-into-microservices.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/) 

# REL03-BP03 每個 API 都提供服務合約
<a name="rel_service_architecture_api_contracts"></a>

 服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。版本控制策略可讓您的用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。只要不違反合約，隨時都可進行部署。服務供應商團隊可以使用自己選擇的技術堆疊，以滿足 API 合約要求。同樣地，服務取用者可以使用自有的技術。 

 微型服務採用此服務導向架構 (SOA) 的概念，進而建立擁有最少功能組的服務。每個服務均會發佈一個 API 及使用該服務的設計目標、限制和其他考量事項。這可與 *呼叫應用程式* 建立合約。這樣即可實現三個主要優勢： 
+  該服務包含一個待處理的簡明業務問題，以及一個存在業務問題的小團隊。這樣一來，將能更好地進行組織擴展。 
+  只要符合 API 和合約要求，團隊能隨時進行部署。 
+  只要符合 API 和合約要求，團隊能隨時使用任何他們想要的技術堆疊。 

 Amazon API Gateway 是一項全受管的服務，可讓開發人員輕鬆地建立、發佈、維護、監控和保護任何規模的 API。涉及接受和處理多達數十萬個並行 API 呼叫 (包括流量管理、授權與存取控制、監控和 API 版本管理) 的所有任務均由 API Gateway 處理。您可以使用 OpenAPI Specification (OAS) (先前稱為 Swagger Specification)，定義 API 合約並將其匯入至 API Gateway。您之後可以使用 API Gateway 進行 API 的版本控制和部署作業。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>
+  每個 API 都提供服務合約：服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。 
  +  [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
    +  版本控制策略可讓用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。
    +  Amazon API Gateway 是一種全受管的服務，可讓開發人員輕鬆地建立任何規模的 API。您可以使用 OpenAPI Specification (OAS) (先前稱為 Swagger Specification)，定義 API 合約並將其匯入至 API Gateway。您之後可以使用 API Gateway 進行 API 的版本控制和部署作業。

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [有界限的環境 (領域驅動設計的集中模式)](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/)