本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 上的簡易微服務架構 AWS
<a name="simple-microservices-architecture-on-aws"></a>

 典型的單體應用程式 由不同的圖層組成：呈現圖層、應用程式圖層和資料圖層。另一方面， 微服務架構會根據特定網域，而不是技術圖層，將功能分隔成具有凝聚力的*垂直*。圖 1 說明典型微服務應用程式的參考架構 AWS。

![\[顯示 上典型微服務應用程式的圖表 AWS\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/microservices-on-aws/images/typical-microservices-application.png)


# 使用者界面
<a name="user-interface"></a>

 現代 Web 應用程式通常使用 JavaScript 架構來開發與後端 APIs單一頁面應用程式。這些 APIs通常使用代表狀態傳輸 (REST) 或 RESTful APIs 或 GraphQL APIs 建置。您可以使用 Amazon Simple Storage Service ([Amazon S3](https://aws.amazon.com/s3/)) 和 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 提供靜態 Web 內容。

# 微服務
<a name="microservices"></a>

 APIs被視為微服務*的前門*，因為它們是應用程式邏輯的進入點。一般而言，會使用 RESTful Web 服務 API 或 GraphQL APIs。這些 APIs會管理和處理用戶端呼叫、處理流量管理、請求篩選、路由、快取、身分驗證和授權等函數。

## 微服務實作
<a name="microservices-implementations"></a>

 AWS 提供建置區塊來開發微服務，包括 Amazon ECS 和 Amazon EKS 作為容器協同運作引擎的選擇 AWS Fargate ，以及 EC2 作為託管選項。 AWS Lambda 是建置微服務的另一種無伺服器方式 AWS。這些託管選項之間的選擇取決於客戶管理基礎基礎設施的需求。

 AWS Lambda 可讓您上傳程式碼，以高可用性自動擴展和管理其執行。這消除了基礎設施管理的需求，因此您可以快速移動並專注於您的商業邏輯。Lambda 支援[多種程式設計語言](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)，並且可由其他服務觸發 AWS 或直接從 Web 或行動應用程式呼叫。

 由於可攜性、生產力和效率，容器型應用程式越來越受歡迎。 AWS 提供數種服務來建置、部署和管理容器。
+  [App2Container](https://aws.amazon.com/app2container/) 是命令列工具，可將 Java 和 .NET Web 應用程式遷移和現代化為容器格式。 AWS A2C 會分析並建置在裸機、虛擬機器、Amazon Elastic Compute Cloud (EC2) 執行個體或雲端中執行的應用程式庫存。
+  Amazon Elastic Container Service ([Amazon ECS](https://aws.amazon.com/ecs/)) 和 Amazon Elastic Kubernetes Service ([Amazon EKS](https://aws.amazon.com/eks/)) 可 管理您的容器基礎設施，讓您更輕鬆地啟動和維護容器化應用程式。  
  +  Amazon EKS 是一項受管 Kubernetes 服務，可在 AWS 雲端和內部部署資料中心 ([Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/)) 中執行 Kubernetes。這會將雲端服務延伸至內部部署環境，以滿足低延遲、本機資料處理、高資料傳輸成本或資料駐留需求 （請參閱「[使用 Amazon EKS Anywhere 執行混合容器工作負載](https://d1.awsstatic.com/kubernetes-pmm/eks-a/getting-started/AWS_Whitepaper_Running_Hybrid_Container_Workloads_with_Amazon_EKS_Anywhere.pdf)」的白皮書）。您可以透過 EKS 從 Kubernetes 社群使用所有現有的外掛程式和工具。
  +  Amazon Elastic Container Service (Amazon ECS) 是一種全受管容器協同運作服務，可簡化容器化應用程式的部署、管理和擴展。客戶選擇 ECS 以簡化和深度整合 AWS 服務。

 如需進一步閱讀，請參閱部落格 [Amazon ECS 與 Amazon EKS：了解 AWS 容器服務](https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/)。
+  [AWS App Runner](https://aws.amazon.com/apprunner/) 是一種全受管容器應用程式服務，可讓您建置、部署和執行容器化 Web 應用程式和 API 服務，而不需要先前的基礎設施或容器體驗。
+  [AWS Fargate](https://aws.amazon.com/fargate/)是無伺服器運算引擎，可與 Amazon ECS 和 Amazon EKS 搭配使用，以自動管理容器應用程式的運算資源。
+  [Amazon ECR](https://aws.amazon.com/ecr/) 是全受管容器登錄檔，提供高效能託管，因此您可以可靠地將應用程式映像和成品部署到任何地方。

# 持續整合和持續部署 (CI/CD)
<a name="continuous-integration-and-continuous-deployment-cicd"></a>

 持續整合和持續交付 (CI/CD) 是 DevOps 快速軟體變更計劃 的重要部分。 AWS 提供實作微服務 CI/CD 的服務，但詳細討論超出本文件的範圍。如需詳細資訊，請參閱在白皮書[上練習持續整合和持續交付 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)。

# 私有網路
<a name="private-networking"></a>

AWS PrivateLink 是一項技術，透過允許虛擬私有雲端 (VPC) 與支援的 服務之間的私有連線，增強微 AWS 服務的安全性。它有助於隔離和保護微服務流量，確保其永遠不會跨越公有網際網路。這對於遵守 PCI 或 HIPAA 等法規特別有用。

# 資料存放區
<a name="data-store"></a>

 資料存放區用於保留微服務所需的資料。工作階段資料的熱門存放區是記憶體內快取，例如 Memcached 或 Redis。 AWS 提供兩種技術做為受管 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 服務的一部分。

 在應用程式伺服器和資料庫之間放置快取是減少資料庫讀取負載的常見機制，進而允許資源用於支援更多寫入。快取也可以改善延遲。

 關聯式資料庫在儲存結構化資料和商業物件方面仍然非常熱門。 透過 [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS) AWS 提供六個資料庫引擎 (Microsoft SQL Server、Oracle、MySQL、MariaDB、PostgreSQL 和 [Amazon Aurora](https://aws.amazon.com/rds/aurora/)) 做為受管服務。

 不過，關聯式資料庫並非針對無限擴展而設計，這可能會讓套用技術以支援大量查詢變得困難且耗時。

 NoSQL 資料庫旨在有利於關聯式資料庫一致性的可擴展性、效能和可用性。NoSQL 資料庫的一個重要元素是它們通常不會強制執行嚴格的結構描述。資料分散到可以水平擴展的分割區，並使用分割區索引鍵擷取。

 由於個別微服務的設計是很好地執行一件事，因此它們通常具有簡化的資料模型，可能非常適合 NoSQL 持久性。請務必了解 NoSQL 資料庫的存取模式與關聯式資料庫不同。例如，無法聯結資料表。如果需要，則必須在應用程式中實作邏輯。您可以使用 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 建立資料庫資料表，以存放和擷取任意數量的資料，並為任何層級的請求流量提供服務。DynamoDB 提供單一位數毫秒的效能，不過，某些使用案例需要以微秒為單位的回應時間。 [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) (DAX) 提供快取功能來存取資料。

 DynamoDB 還提供自動擴展功能，可動態調整輸送量容量以回應實際流量。不過，在某些情況下，由於應用程式的短期活動高峰，容量規劃很難或無法進行。在這種情況下，DynamoDB 提供隨需選項，提供簡單的pay-per-request定價。DynamoDB 隨需能夠立即處理數千個請求，無需規劃容量。

 如需詳細資訊，請參閱 [分散式資料管理](distributed-data-management.md)和[如何選擇資料庫](https://aws.amazon.com/startups/learn/maximizing-performance-with-aws-databases)。

# 簡化操作
<a name="simplyfing-operations"></a>

 為了進一步簡化執行、維護和監控微服務所需的操作工作，我們可以使用 完全無伺服器架構。

## 部署 Lambda 型應用程式
<a name="deploying-lambda-based-applications"></a>

 您可以透過上傳`zip`檔案封存，或使用有效的 Amazon ECR 映像 URI 透過主控台 UI 建立和上傳容器映像，來部署 Lambda 程式碼。不過，當 Lambda 函數變得複雜時，表示它具有層、相依性和許可，透過 UI 上傳可能會變得難以進行程式碼變更。

 使用 AWS CloudFormation 和  AWS Serverless Application Model ([AWS SAM](https://github.com/awslabs/serverless-application-model)) AWS Cloud Development Kit (AWS CDK)或 Terraform 可簡化定義無伺服器應用程式的程序。CloudFormation 原生支援的 AWS SAM 提供簡化的語法，用於指定無伺服器資源。 AWS Lambda Layers 可協助管理跨多個 Lambda 函數的共用程式庫、盡可能減少函數使用量、集中租用戶感知程式庫，並改善開發人員體驗。Lambda SnapStart for Java 可增強對延遲敏感應用程式的啟動效能。

 若要部署，請在 CloudFormation 範本中指定資源和許可政策、套件部署成品，以及部署範本。SAM Local 是一種 AWS CLI 工具，允許在上傳至 Lambda 之前對無伺服器應用程式進行本機開發、測試和分析。

 與 AWS Cloud9 IDE 等工具整合 AWS CodeBuild AWS CodeDeploy，並 AWS CodePipeline 簡化撰寫、測試、偵錯和部署 SAM 型應用程式。

 下圖顯示使用 CloudFormation 和 AWS CI/CD 工具部署 AWS Serverless Application Model 資源。

![\[show AWS Serverless Application Model (AWS SAM) 圖表\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/microservices-on-aws/images/aws-sam.png)


## 抽象化多租用戶複雜性
<a name="abstracting-multi-tenancy-complexities"></a>

 在 SaaS 平台等多租戶環境中，簡化與多租戶相關的複雜性至關重要，讓開發人員能夠專注於特徵和功能開發。這可以使用 [AWS Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) 等工具來實現，該工具提供共同程式庫來解決交叉切割問題。這種方法背後 的原理是，共用程式庫和工具在正確使用時，可以有效地管理租戶內容。  

 但是，由於業務邏輯可能帶來的複雜性和風險，他們不應該擴展到封裝業務邏輯。共用程式庫的基本問題是與更新相關的複雜性增加，相較於標準程式碼複製，管理更具挑戰性。因此，在尋找最有效的抽象時，在共用程式庫的使用與重複之間取得平衡至關重要。

## API 管理
<a name="api-management"></a>

 管理 APIs 可能很耗時，特別是在考慮多個版本、開發週期階段、授權和其他功能時，例如限流和快取。除了 [API Gateway](https://aws.amazon.com/api-gateway/) 之外，有些客戶也會使用 ALB (Application Load Balancer) 或 NLB (Network Load Balancer) 進行 API 管理。Amazon API Gateway 有助於降低建立和維護 RESTful APIs的操作複雜性。它可讓您以程式設計方式建立 APIs，做為「前門」，從後端服務存取資料、商業邏輯或功能、授權和存取控制、速率限制、快取、監控和流量管理，並在不管理伺服器的情況下執行 APIs。

 圖 3 說明 API Gateway 如何處理 API 呼叫並與其他元件互動。來自行動裝置、網站或其他後端服務的請求會路由至最近的 CloudFront 存在點 (PoP)， 以減少 延遲 並提供最佳的 使用者體驗。

![\[顯示 API Gateway 呼叫流程的圖表\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/microservices-on-aws/images/api-gateway-call-flow.png)