本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 开启了简单的微服务架构 AWS
<a name="simple-microservices-architecture-on-aws"></a>

 典型的单片应用程序由不同的层组成：表示层、应用层和数据层。 另一方面，微服务架构根据特定领域而不是技术层将功能划分为有凝聚力的*垂直市场*。图 1 说明了上 AWS典型微服务应用程序的参考架构。

![\[该图显示了典型的微服务应用程序 AWS\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/microservices-on-aws/images/typical-microservices-application.png)


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

 现代 Web 应用程序通常使用 JavaScript 框架来开发与后端 APIs通信的单页应用程序。 APIs 它们通常使用表述性状态转移 (REST) 或或 RESTful APIs GraphQL APIs 构建。静态网页内容可以使用亚马逊简单存储服务 (A [mazon S3](https://aws.amazon.com/s3/)) 和[亚马逊](https://aws.amazon.com/cloudfront/)提供 CloudFront。

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

 APIs 被认为是微服务的*前门*，因为它们是应用程序逻辑的入口点。通常 RESTful 使用网络服务 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，一种命令行工具，用于将 Java 和.NET Web 应用程序迁移到容器](https://aws.amazon.com/app2container/)格式并对其进行现代化改造。 AWS A2C 分析并生成在裸机、虚拟机、Amazon Elastic Compute Cloud (EC2) 实例或云中运行的应用程序清单。
+  亚马逊弹性容器服务 ([Amazon ECS](https://aws.amazon.com/ecs/)) 和亚马逊弹性 Kubernetes Service [(Amazon](https://aws.amazon.com/eks/) EKS) 管理您的容器基础设施，从而更轻松地启动和维护容器化应用程序。  
  +  [Amazon EKS 是一项托管 Kubernetes 服务，用于在 AWS 云端和本地数据中心（亚马逊 EKS Anywhere）中运行 Kubernetes。](https://aws.amazon.com/eks/eks-anywhere/)这将云服务扩展到本地环境，以满足低延迟、本地数据处理、高数据传输成本或数据驻留要求（参见 “使用 [Amazon EKS Anywhere 运行混合容器工作负载” 的](https://d1.awsstatic.com/kubernetes-pmm/eks-a/getting-started/AWS_Whitepaper_Running_Hybrid_Container_Workloads_with_Amazon_EKS_Anywhere.pdf)白皮书）。您可以将来自 Kubernetes 社区的所有现有插件和工具与 EKS 一起使用。
  +  Amazon Elastic Container Service (Amazon ECS) 是一项完全托管的容器编排服务，可简化容器化应用程序的部署、管理和扩展。客户之所以选择 ECS，是因为它既简单又能与 AWS 服务深度集成。

 如需进一步阅读，请参阅博客 [Amazon ECS vs 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](https://aws.amazon.com/elasticache/) 托管 ElastiCache服务中提供了这两种技术。

 在应用程序服务器和数据库之间放置缓存是减少数据库读取负载的常用机制，这反过来又可以允许使用资源来支持更多的写入。缓存还可以改善延迟。

 关系数据库在存储结构化数据和业务对象方面仍然非常流行。 AWS 通过亚马逊[关系数据库服务（亚马逊 RDS）提供六种数据库引擎（微软 SQL Server、甲骨文、MySQL、MariaDB、PostgreSQL 和[亚马逊 Aur](https://aws.amazon.com/rds/aurora/) ora）作为托管服务](https://aws.amazon.com/rds/)。

 但是，关系数据库并不是为无限扩展而设计的，这会使应用技术来支持大量查询变得困难和耗时。

 NoSQL 数据库的设计有利于可扩展性、性能和可用性，而不是关系数据库的一致性。NoSQL 数据库的一个重要元素是，它们通常不强制执行严格的架构。数据分布在可以水平扩展的分区上，并使用分区键进行检索。

 由于单个微服务旨在很好地完成一件事，因此它们通常具有非常适合 NoSQL 持久性的简化数据模型。重要的是要明白，NoSQL 数据库的访问模式与关系数据库不同。例如，无法联接表。如果有必要，则必须在应用程序中实现逻辑。您可以使用 [Amazon Dy](https://aws.amazon.com/dynamodb/) namoDB 创建数据库表，该表可以存储和检索任意数量的数据并处理任何级别的请求流量。DynamoDB 提供个位数的毫秒性能，但是，某些用例需要以微秒为单位的响应时间。 [DynamoDB](https://aws.amazon.com/dynamodb/dax/) 加速器 (DAX) 提供用于访问数据的缓存功能。

 DynamoDB 还提供自动扩展功能，可根据实际流量动态调整吞吐容量。但是，在某些情况下，由于应用程序中出现了持续时间较短的大型活动峰值，因此容量规划很困难或不可能。对于此类情况，DynamoDB 提供了按需选项，其定价非常简单。 pay-per-requestDynamoDB 按需能够即时处理每秒数千个请求，无需进行容量规划。

 有关更多信息，请参阅[分布式数据管理](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`文件存档来部署 Lambda 代码，也可以使用有效的 Amazon ECR 映像 URI 通过控制台用户界面创建和上传容器映像。但是，当 Lambda 函数变得复杂（这意味着它具有层、依赖关系和权限）时，通过用户界面上传可能会因为代码更改而变得笨拙。

 使用AWS CloudFormation 和 AWS Serverless Application Model ([AWS SAM](https://github.com/awslabs/serverless-application-model)) AWS Cloud Development Kit (AWS CDK)、或 Terraform 可以简化定义无服务器应用程序的过程。 AWS SAM 原生支持 CloudFormation，它提供了一种用于指定无服务器资源的简化语法。AWS Lambda 层可帮助管理多个 Lambda 函数之间的共享库，最大限度地减少函数占用空间，集中租户感知库并改善开发者体验。Lambda f SnapStart or Java 增强了延迟敏感型应用程序的启动性能。

 要进行部署，请在 CloudFormation 模板中指定资源和权限策略，打包部署对象，然后部署模板。SAM Local 是一种 AWS CLI 工具，允许在上传到 Lambda 之前对无服务器应用程序进行本地开发、测试和分析。

 与 AWS Cloud9 IDE、、等工具集成 AWS CodeBuild AWS CodeDeploy， AWS CodePipeline 简化了基于 SAM 的应用程序的创作、测试、调试和部署。

 下图显示了使用 CloudFormation 和 C AWS I/CD 工具部署 AWS Serverless Application Model 资源。

![\[显示的示意图 AWS Serverless Application Model (AWS SAM)\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/microservices-on-aws/images/aws-sam.png)


## 抽象多租户的复杂性
<a name="abstracting-multi-tenancy-complexities"></a>

 在像 SaaS 平台这样的多租户环境中，简化与多租户相关的复杂性，让开发人员腾出时间专注于功能和功能开发至关重要。这可以通过诸如L [AWS Lambda ay](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) ers之类的工具来实现，这些工具提供了用于解决跨领域问题的共享库。 这种方法背后的基本原理是，如果使用得当，共享库和工具可以有效地管理租户上下文。  

 但是，由于它们可能带来的复杂性和风险，它们不应扩展到封装业务逻辑。共享库的一个基本问题是更新的复杂性增加，与标准代码复制相比，更新更难管理。因此，在寻求最有效的抽象时，必须在使用共享库和重复之间取得平衡。

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

 管理 APIs 可能很耗时，尤其是在考虑多个版本、开发周期的各个阶段、授权以及其他功能（例如限制和缓存）时。除了 [API Gatew](https://aws.amazon.com/api-gateway/) ay 之外，一些客户还使用 ALB（应用程序负载均衡器）或 NLB（网络负载均衡器）进行 API 管理。Amazon API Gateway 有助于降低创建和维护的操作复杂性 RESTful APIs。它允许您以 APIs 编程方式创建，充当访问后端服务、授权和访问控制、速率限制、缓存、监控和流量管理中的数据、业务逻辑或功能的 “前门”，并且 APIs 无需管理服务器即可运行。

 图 3 说明了 API Gateway 如何处理 API 调用以及如何与其他组件交互。来自移动设备、网站或其他后端服务的请求会被路由到最近的接入 CloudFront 点 (PoP)，以减少延迟并提供最佳的用户体验。

![\[显示了 API Gateway 调用流程的示意图\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/microservices-on-aws/images/api-gateway-call-flow.png)