本文摘自AWS白皮书，《Implementing Microservices on AWS》
摘要
微服务是软件开发的一种架构和组织方法，它可以加速部署周期、增强创新和自主性，提高软件应用程序的可维护性和可扩展性，通过使用敏捷方法帮助团队独立工作，扩展组织交付的软件和服务。微服务方案中，软件由小服务组成，小服务通过定义良好的、可以独立部署的API进行通信。这些服务由小型自主团队拥有。这种组织方法是成功扩展组织的关键。
在客户构建微服务时，我们观察到三种常见的模式：API驱动、事件驱动和数据流。在这篇文章中，我们将介绍三种方法，并总结微服务的共同特征，讨论构建微服务的主要挑战，并描述产品团队如何利用Amazon Web Services（AWS）来克服这些挑战。
介绍
微服务架构对于软件工程来说并不是一种全新的方法，而是各种成功和成熟概念的组合，比如：
- Agile software development 敏捷软件开发
- Service-oriented architectures 面向服务的体系结构
- API-first design API的设计
- Continuous Integration/Continuous Delivery (CI/CD) 持续集成/持续交付
在大多数情况下，12因素应用程序的设计模式被用于微服务。我们首先介绍了高度伸缩性、容错的微服务体系结构（用户界面、微服务实现和数据存储）的不同方面，以及如何在利用容器技术的AWS上构建它。然后，我们建议使用AWS服务实现典型的无服务器微服务体系结构，以减少操作复杂性。
Serverless被定义为一个操作模型，遵循以下原则：
没有提供或管理的基础设施
自动按消费单位缩放
“按价值付款”的计费模式
内置的可用性和容错能力
最后，我们查看整个系统并讨论微服务体系结构的跨服务方面，如分布式监视和审计、数据一致性和异步通信。
AWS上的简单微服务
典型的应用程序使用不同的层构建-用户接口层、业务层和持久层。微服务体系结构的核心思想是将功能拆分为内聚的“垂直领域”-不是通过技术层，而是通过实现特定领域。下图描述了AWS上典型微服务应用程序的参考体系结构。
用户接口
web应用程序通常使用JavaScript框架来实现与REST或RESTful API通信的单页面应用程序。静态web内容可以使用Amazon Simple Storage Service (Amazon S3)和Amazon CloudFront提供。
由于微服务的客户端从最近的边缘位置提供服务，并从缓存或代理服务器获得响应，从而优化到源服务器的连接，因此延迟可以显著降低。然而，微服务彼此之间的运行并不会从CDN中受益。在某些情况下，这种方法可能会增加额外的延迟。最佳实践是实现其他缓存机制，以减少聊天和最小化延迟。
微服务
我们常说api是微服务的大门，API充当一组编程接口(通常是RESTful web服务API)背后的应用程序逻辑的入口点。此API接受并处理来自客户端的调用，并可能实现诸如流量管理、请求过滤、路由、缓存、身份验证和授权等功能。
AWS集成了支持微服务开发的构件。两种流行的方法是使用AWS Lambda和带有AWS Fargate的Docker容器。
使用AWS Lambda，您只需上传您的代码，并让Lambda负责运行和扩展执行所需的所有工作，以满足高可用性的实际需求曲线。这意味着不需要对基础设施进行管理。Lambda支持多种编程语言，可以从其他AWS服务触发，也可以直接从任何web或移动应用程序调用。AWS Lambda的最大优势之一是您可以快速移动:您可以专注于您的业务逻辑，因为安全性和可伸缩性是由AWS管理的。Lambda驱动了可伸缩平台。
减少部署操作工作的一种常见方法是基于容器的部署。由于可移植性、生产力和效率等优点，Docker等容器技术在过去几年里越来越受欢迎。容器的学习曲线可能非常陡峭，您必须考虑Docker映像的安全保障与监控。
Amazon Elastic Container Service (Amazon ECS)和Amazon Elastic Kubernetes Service (Amazon EKS)消除了安装、操作和扩展自己的集群管理基础设施的需要。通过简单的API调用，您可以启动和停止启用docker的应用程序，查询集群的完整状态，并访问许多熟悉的特性，如安全组、负载平衡、Amazon Elastic Block Store (Amazon EBS)卷和AWS身份和访问管理(AWS Identity and access Management, IAM)角色。
AWS Fargate是一种容器管理服务，它允许您运行没有服务器的容器，因此您不必担心配置、配置和扩展虚拟机集群来运行容器。使用Fargate，您不再需要为容器应用程序提供足够的计算资源。Fargate可以启动成千上万个容器，并且可以轻松地扩展到运行最关键的任务应用程序。
Amazon ECS支持容器放置策略和约束，以自定义Amazon ECS如何放置和终止任务。任务放置约束是在任务放置期间考虑的规则。您可以将属性(本质上是键-值对)与容器实例关联起来，然后使用约束来根据这些属性放置任务。例如，您可以使用约束来放置基于实例类型或实例功能的特定微服务，例如由gpu支持的实例。
Amazon EKS运行最新版本的开源Kubernetes软件，因此您可以使用来自Kubernetes社区的所有现有插件和工具。运行在Amazon EKS上的应用程序与运行在任何标准Kubernetes环境中的应用程序完全兼容，无论是运行在本地数据中心还是公有云上。Amazon EKS集成了IAM和Kubernetes，使您能够向Kubernetes中的本地身份验证系统注册IAM实体。不需要手动设置与Kubernetes主机进行身份验证的凭据。IAM集成允许您使用IAM直接通过主机本身进行身份验证，从而提供对Kubernetes主机公共端点的细粒度访问。
Amazon ECS和Amazon EKS中使用的Docker图像可以存储在Amazon Elastic Container Registry (Amazon ECR)中。Amazon ECR消除了操作和扩展容器注册中心所需的基础设施的需要。
持续集成和持续交付(CI/CD)是最佳实践，也是DevOps计划的重要组成部分，它支持快速的软件更改，同时保持系统的稳定性和安全性。然而，这超出了本白皮书的范围，更多信息可以在“在AWS上实践持续集成和持续交付”白皮书中找到。
AWS PrivateLink是一种高可用性、可扩展的技术，允许您私下将VPC连接到受支持的AWS服务、由其他AWS帐户托管的服务(VPC端点服务)和受支持的AWS市场合作伙伴服务。您不需要使用internet网关、NAT设备、公共IP地址、AWS直连连接或VPN连接来与服务通信。您的VPC和服务之间的通信不会离开Amazon网络。
PrivateLink是增强微服务体系结构隔离性的好方法，例如，可以创建数百个vpc，每个vpc托管并提供单个微服务。公司现在可以创建服务并将其出售给AWS的其他客户，通过私有连接进行访问。它们创建一个接受TCP流量的服务，将其托管在网络负载均衡器之后，然后直接或在AWS市场中提供服务。他们将收到新订阅请求的通知，并可以选择接受或拒绝每一个请求。虽然AWS PrivateLink的能力在许多场景中都有优点，但SaaS组织对此特别感兴趣。通过AWS PrivateLink, SaaS提供商看到了使用这种网络结构来增强和扩展其解决方案的架构和业务模型的新的和创造性的机会。
数据存储
数据存储用于存储微服务所需的数据。流行的会话数据存储是内存缓存，如Memcached或Redis。AWS提供这两种技术，作为管理的Amazon ElastiCache服务的一部分。
在应用程序服务器和数据库之间放置缓存是减少数据库上读负载的常见机制，从而允许使用资源来支持更多的写操作。缓存也可以改善延迟。
关系数据库仍然非常流行用于存储结构化数据和业务对象。AWS通过Amazon关系数据库服务(Amazon RDS)提供6个数据库引擎(Microsoft SQL Server、Oracle、MySQL、MariaDB、PostgreSQL和Amazon Aurora)作为管理服务。
然而，关系数据库并不是为无限扩展而设计的，这使得应用技术来支持大量查询变得困难和耗时。
NoSQL数据库的设计目的是为了支持可伸缩性、性能和可用性，而不是关系数据库的一致性。NoSQL数据库的一个重要元素是它们通常不执行严格的模式。数据分布在可以水平伸缩的分区上，并使用分区键进行检索。由于各个微服务被设计为很好地完成一件事情，所以它们通常有一个简化的数据模型，这个模型可能非常适合NoSQL持久性。必须理解，与关系数据库相比，sql数据库具有不同的访问模式。例如，连接表是不可能的。如果有必要，则必须在应用程序中实现逻辑。您可以使用Amazon DynamoDB创建一个数据库表，该表可以存储和检索任意数量的数据，并为任何级别的请求流量提供服务。DynamoDB提供了个位数毫秒的性能，但是，某些用例需要以微秒为单位的响应时间。DynamoDB Accelerator (DAX)为访问数据提供缓存功能。
DynamoDB还提供了一个自动伸缩功能，可以根据实际流量动态调整吞吐量容量。然而，在某些情况下，由于应用程序中持续时间很短的大型活动峰值，容量规划是困难的或不可能的。对于这种情况，DynamoDB提供了一个按需选项，它提供了简单的按请求付费定价。随需应变的DynamoDB能够在不进行容量规划的情况下每秒立即处理数千个请求。
降低操作复杂度
我们所描述的体系结构已经在使用托管服务，但是我们仍然需要管理亚马逊弹性计算云(Amazon EC2)实例。我们可以进一步减少运行所需的操作工作，通过使用完全无服务器的体系结构来维护和监视微服务。
API的实现
架构、部署、监视、持续改进和维护API可能是一项耗时的任务。有时需要运行不同版本的api来确保所有客户机的向后兼容性。开发周期的不同阶段(即开发、测试和生产)进一步增加了操作工作。
授权是所有api的关键特性，但它的构建通常很复杂，而且涉及重复的工作。当一个API发布并获得成功时，下一个挑战是管理、监控和利用API的第三方开发者的生态系统。
其他重要的特性和挑战包括限制请求以保护后端服务、缓存API响应、处理请求和响应转换，以及使用Swagger等工具生成API定义和文档。
Amazon API Gateway解决了这些挑战，降低了创建和维护RESTful API的操作复杂性。
API网关允许您使用AWS API或AWS管理控制台通过导入Swagger定义以编程方式创建API。API网关作为任何运行在Amazon EC2、Amazon ECS、AWS Lambda或任何内部环境中的web应用程序的前门。基本上，API网关允许您在无需管理服务器的情况下运行API。
图2演示了API网关如何处理API调用并与其他组件进行交互。来自移动设备、网站或其他后端服务的请求被路由到最近的CloudFront存在点(PoP)，以最小化延迟并提供最佳用户体验。
无服务器微服务
“没有服务器比没有服务器更容易管理”。清除服务器是消除操作复杂性的一种好方法。
Lambda与API网关紧密集成。从API网关到Lambda进行同步调用的能力支持创建完全无服务器的应用程序，我们的文档对此进行了详细描述。
图3展示了使用AWS Lambda的无服务器微服务的体系结构，其中完整的服务是由托管服务构建的，这消除了为规模和高可用性而设计的体系结构负担，并消除了运行和监视微服务底层基础设施的操作工作。
图4显示了同样基于无服务器服务的类似实现。在这种体系结构中，Docker容器与AWS Fargate一起使用，因此没有必要关心底层基础设施。除了Amazon DynamoDB之外，还使用了Amazon Aurora Serverless，这是Amazon Aurora (MySQL兼容版)的随需应变、自动伸缩配置，其中数据库将根据应用程序的需要自动启动、关闭和伸缩容量。
部署Lambda-Based应用程序
您可以使用AWS CloudFormation来定义、部署和配置无服务器应用程序。
AWS无服务器应用程序模型(AWS SAM)是定义无服务器应用程序的一种方便方法。AWS SAM由CloudFormation本地支持，并定义了用于表示无服务器资源的简化语法。为了部署应用程序，只需在CloudFormation模板中指定作为应用程序一部分所需的资源及其相关的权限策略，打包部署构件，并部署模板。基于AWS SAM, SAM Local是一个AWS CLI工具，它为您提供了一个环境，在将您的无服务器应用程序上传到Lambda运行时之前，在本地对其进行开发、测试和分析。您可以使用SAM Local来创建一个模拟AWS运行时环境的本地测试环境。
分布式系统组件
在了解了AWS如何解决与单个微服务相关的挑战之后，我们现在希望关注跨服务的挑战，比如服务发现、数据一致性、异步通信以及分布式监视和审计。
服务发现
微服务体系结构的主要挑战之一是允许服务彼此发现和交互。微服务体系结构的分布式特性不仅使服务的通信变得更加困难，而且还带来了其他挑战，比如检查这些系统的健康状况以及宣布何时有新的应用程序可用。您还必须决定如何以及在何处存储可由应用程序使用的元存储信息(如配置数据)。在本节中，我们将探讨在基于微服务的体系结构的AWS上执行服务发现的几种技术。
Amazon ECS现在包含了集成服务发现，使您的容器化服务更容易发现并彼此连接。在此之前，为了确保服务能够彼此发现和连接，您必须基于Amazon Route 53、AWS Lambda和ECS事件流配置和运行自己的服务发现系统，或者将每个服务连接到负载均衡器。
Amazon ECS使用Route 53自动命名API创建和管理服务名称注册表。名称将自动映射到一组DNS记录，以便您可以在代码中通过名称引用服务，并编写DNS查询，以便在运行时将名称解析到服务的端点。您可以在服务的任务定义中指定健康检查条件，Amazon ECS确保服务查找只返回健康的服务端点。
此外，您还可以为Kubernetes管理的服务利用统一服务发现。为了实现这种集成，AWS参与了Kubernetes孵化器项目的外部DNS项目。另一个选择是利用AWS Cloud Map的功能。AWS Cloud Map扩展了自动命名api的功能，为资源(如ip、url和ARNs)提供了服务注册表，并提供了基于api的服务发现机制，该机制具有更快的更改传播速度和使用属性缩小发现资源集的能力。现有的Route 53自动命名资源自动升级到AWS Cloud Map。
实现服务发现的另一种方法是使用第三方软件，如HashiCorp、etcd或Netflix Eureka。这三个示例都是分布式的、可靠的键值存储。对于HashiCorp Consul，有一个AWS Quick Start，它设置一个灵活的、可伸缩的AWS云环境，并将HashiCorp Consul自动启动到您选择的配置中。
在高级微服务体系结构中，实际应用程序可以由数百甚至数千个服务组成。通常应用程序最复杂的部分不是实际的服务本身，而是这些服务之间的通信。服务网格是处理服务间通信的附加层，负责监视和控制微服务体系结构中的流量。这允许像服务发现这样的任务完全由这一层来处理。
通常，服务网格分为数据平面和控制平面。数据平面由一组智能代理组成，这些代理与应用程序代码一起部署，作为一个特殊的sidecar代理，拦截微服务之间的所有网络通信。控制平面负责与代理通信。
服务网格是透明的，这意味着应用程序开发人员不需要知道这个额外的层，也不需要更改现有的应用程序代码。AWS App Mesh是一个服务网格，它提供了应用程序级别的网络，使您的服务可以轻松地跨多种类型的计算基础设施彼此通信。AWS App Mesh标准化了你的服务的通信方式，给了你端到端的可见性，并确保了你的应用的高可用性。
您可以将 AWS App Mesh与AWS Fargate、Amazon ECS、Amazon EKS和AWS上的自管理Kubernetes上运行的现有或新的微服务结合使用。AWS App Mesh可以监视和控制跨集群、编排系统或作为单个应用程序运行的微服务的通信，而无需进行任何代码更改。
分布式数据管理
单片应用程序通常由大型关系数据库支持，该数据库定义了所有应用程序组件通用的单个数据模型。在微服务方法中，这种中央数据库将妨碍建立分散和独立组件的目标。每个微服务组件都应该有自己的数据持久层。然而，分布式数据管理提出了新的挑战。作为CAP定理的结果，分布式微服务体系结构在性能上固有地牺牲了一致性，并且需要采用最终的一致性。
在分布式系统中，业务事务可以跨越多个微服务。因为它们不能利用单个ACID事务，所以您可能会以部分执行而告终。在这种情况下，我们需要一些控制逻辑来重做已经处理过的事务。为此，通常采用分布式的Saga模式。在失败的业务事务的情况下，Saga安排了一系列补偿事务，这些补偿事务撤消了前面事务所做的更改。 AWS Step Functions使得实现一个Saga执行协调器变得很容易，如下图所示。
构建由主数据管理工具和过程管理的关键引用数据的集中存储为微服务提供了一种方法来同步它们的关键数据并可能回滚状态。使用Lambda和预定的Amazon CloudWatch事件，您可以构建一个简单的清理和重复删除机制。
状态更改通常会影响多个微服务。在这种情况下，事件源已被证明是一种有用的模式。事件源背后的核心思想是将每个应用程序更改表示为一个事件记录并将其持久化。数据以事件流的形式存储，而不是持久化应用程序状态。数据库事务日志和版本控制系统是事件源的两个众所周知的例子。事件溯源有两个好处:可以为任何时间点确定和重构状态。它自然会产生一个持久的审计跟踪，并有助于调试。
在微服务体系结构上下文中，事件源通过使用发布/订阅模式来分离应用程序的不同部分，它将相同的事件数据提供给不同的微服务数据模型。事件源经常与CQRS(命令查询责任隔离)模式结合使用，以将读写工作负载分离开来，并优化性能、可伸缩性和安全性。在传统的数据管理系统中，命令和查询在相同的数据存储库中运行。
图6显示了如何在AWS上实现事件源模式。Amazon Kinesis数据流是中央事件存储的主要组件，它以事件的形式捕获应用程序更改并将其保存在Amazon S3上。
图6描述了由Amazon API Gateway、AWS Lambda和Amazon DynamoDB组成的三个不同的微服务。蓝色箭头表示事件流:当microservice 1经历事件状态更改时，它通过将消息写入Kinesis数据流来发布事件。所有微服务都在AWS Lambda中运行它们自己的Kinesis数据流应用程序，AWS Lambda读取消息的副本，根据微服务的相关性过滤消息，并可能转发消息进行进一步处理。
Amazon S3在所有微服务上持久地存储所有事件，并且是调试、恢复应用程序状态或审计应用程序更改时的唯一可靠来源。
异步通信和轻量级的消息
在传统的单片应用程序中，通信是直接的—应用程序的一部分使用方法调用或内部事件分发机制与其他部分通信。如果使用解耦的微服务实现相同的应用程序，则必须使用网络通信实现应用程序不同部分之间的通信。
HTTP/S协议是实现微服务之间同步通信的最流行的方法。在大多数情况下，RESTful api使用HTTP作为传输层。REST架构风格依赖于无状态通信、统一接口和标准方法。
使用API Gateway，您可以创建一个API，作为应用程序访问来自后端服务的数据、业务逻辑或功能的“前门”，例如在Amazon EC2和Amazon ECS上运行的工作负载、在Lambda上运行的代码或任何web应用程序。使用API网关服务定义的API对象是一组资源和方法。资源是API域中的类型化对象，它可以将数据模型或关系关联到其他资源。可以将每个资源配置为响应一个或多个方法，即标准HTTP动词，如GET、POST或PUT。REST api可以部署到不同的阶段、版本化以及克隆到新版本。
API Gateway处理所有涉及到接受和处理数十万并发API调用的任务，包括流量管理、授权和访问控制、监控以及API版本管理。
实现微服务之间通信的另一个模式是消息传递。服务通过队列交换消息进行通信。这种通信风格的一个主要好处是，不需要服务发现，而服务是松散耦合的。同步系统是紧密耦合的，这意味着同步下游依赖中的问题会直接影响上游调用方。来自上游调用方的重试可以快速扩展和放大问题。
根据特定的需求(如协议)，AWS提供不同的服务来帮助实现此模式。一个可能的实现是使用Amazon Simple Queue Service (Amazon SQS)和Amazon Simple Notification Service (Amazon SNS)的组合。这两种服务紧密合作:Amazon SNS允许应用程序通过推送机制向多个订阅者发送消息。通过同时使用Amazon SNS和Amazon SQS，可以将一条消息传递给多个消费者。图7演示了Amazon SNS和Amazon SQS的集成。
当您订阅一个SQS队列到一个SNS主题时，您可以向主题发布一条消息，而Amazon SNS向订阅的SQS队列发送一条消息。消息包含发布到主题的主题和消息，以及JSON格式的元数据信息。
另一种实现策略基于Amazon MQ，如果现有软件使用开放标准api和协议(包括JMS、NMS、AMQP、STOMP、MQTT和WebSocket)进行消息传递，则可以使用Amazon MQ。Amazon SQS公开了一个自定义API，这意味着，如果您有一个现有的应用程序需要从本地环境迁移到AWS，那么代码更改是必要的。对于Amazon MQ，在许多情况下不需要这样做。
Amazon MQ管理流行的开源消息代理ActiveMQ的管理和维护。底层基础设施自动提供高可用性和消息持久性，以支持应用程序的可靠性。
当涉及多个微服务时，微服务的分布式特性使得编排工作流具有挑战性。开发人员可能会试图直接将编制代码添加到他们的服务中。应该避免这种情况，因为它引入了更紧密的耦合，使快速替换单个服务变得更加困难。
您可以使用Step Functions从各个执行离散功能的组件构建应用程序。Step Functions提供了一个状态机，它隐藏了服务编排的复杂性，比如错误处理和序列化/并行化。这使您可以快速地扩展和更改应用程序，同时避免服务内部的额外协调代码。
单步函数是协调组件和单步执行应用程序功能的可靠方法。Step Functions提供一个图形化控制台，将应用程序的组件作为一系列步骤进行排列和可视化。这使得构建和运行分布式服务变得非常简单。Step Functions自动触发和跟踪每个步骤，并在出现错误时重试，因此您的应用程序按预期的顺序执行。Step Functions记录每个步骤的状态，这样当出现问题时，您可以快速诊断和调试问题。您甚至可以在不编写代码的情况下更改和添加步骤，以使您的应用程序更快地发展和创新。
Step Functions是AWS无服务器平台的一部分，支持编排Lambda函数以及基于计算资源(如Amazon EC2和Amazon ECS)的应用程序，还支持Amazon SageMaker和AWS Glue等其他服务。图8说明了Lambda函数的调用是如何直接从Step Functions推到Lambda的，而Amazon EC2或Amazon ECS上的工作人员则持续轮询调用。
Step Functions为您管理操作和底层基础结构，以帮助确保您的应用程序在任何规模上都可用。
要构建工作流，Step Functions使用Amazon States语言。工作流可以包含顺序或并行步骤以及分支步骤。
图9显示了结合顺序和并行步骤的微服务体系结构的示例工作流。可以通过Step Functions API或API Gateway调用这样的工作流。
分布式监控
微服务体系结构由许多需要监视的不同分布式组件。您可以使用Amazon CloudWatch来收集和跟踪指标、集中和监视日志文件、设置警报并自动响应AWS环境中的更改。CloudWatch可以监视AWS资源，如EC2实例、DynamoDB表和RDS DB实例，以及应用程序和服务生成的自定义指标，以及应用程序生成的任何日志文件。
您可以使用CloudWatch获得系统范围内对资源利用、应用程序性能和操作健康状况的可见性。CloudWatch提供了一个可靠的、可伸缩的、灵活的监控解决方案，您可以在几分钟内开始使用它。您不再需要设置、管理和扩展自己的监视系统和基础设施。在微服务体系结构中，使用CloudWatch监视定制指标的功能是一个额外的好处，因为开发人员可以决定为每个服务收集哪些指标。此外，还可以基于自定义指标实现动态扩展。
另一个流行的选择是使用Prometheus，尤其是亚马逊的eks。Prometheus是一个开源的监测和报警工具包，经常与Grafana结合使用，以可视化收集到的指标。许多Kubernetes组件在/metrics存储指标，普罗米修斯可以定期收集这些指标。
一致的日志记录对于故障诊断和确定问题非常重要。微服务允许团队发布比以前更多的版本，并鼓励工程团队对生产中的新特性进行试验。理解客户的影响对于逐步改进应用程序是至关重要的。
默认情况下，大多数AWS服务集中它们的日志文件。AWS上日志文件的主要目的地是Amazon S3和Amazon CloudWatch日志。对于运行在EC2实例上的应用程序，可以使用守护进程将日志文件发送到CloudWatch日志。Lambda函数将其日志输出发送到CloudWatch日志，Amazon ECS包括对awslogs日志驱动程序的支持，该驱动程序允许将容器日志集中到CloudWatch日志。对于Amazon EKS来说，有必要运行FluentD，它将集群中各个实例的日志转发到一个集中的日志CloudWatch日志中，在那里，这些日志将通过Elasticsearch和Kibana进行更高级的报告。
图10说明了一些服务的日志功能。然后，团队可以使用Amazon Elasticsearch Service (Amazon ES)和Kibana等工具搜索和分析这些日志。Amazon Athena可用于对Amazon S3中的集中日志文件运行特殊查询。
在许多情况下，一组微服务一起工作来处理请求。设想一个由数十个微服务组成的复杂系统，其中调用链中的一个服务发生了错误。即使每个微服务都正确地进行了日志记录，并且将日志合并到一个中央系统中，也很难找到所有相关的日志消息。
AWS X-Ray背后的核心思想是使用相关id，它是附加到与特定事件链相关的所有请求和消息上的惟一标识符。当请求到达第一个x - ray集成服务(例如，应用程序负载均衡器或API网关)并包含在响应中时，跟踪ID将添加到HTTP请求的特定跟踪标头X-Amzn-Trace-Id中。通过X-Ray SDK，任何微服务都可以读取，但也可以添加或更新这个头。
AWS X-Ray与Amazon EC2、Amazon ECS、Lambda和AWS Elastic Beanstalk合作。您可以将X-Ray用于用Java、Node、.net编写的应用程序。
搜索、分析和可视化日志数据是理解分布式系统的一个重要方面。Amazon CloudWatch Logs Insights是一个可以即时探索、分析和可视化日志的伟大服务。这允许您排除操作问题。分析日志文件的另一个选项是使用Amazon ES和Kibana。
Amazon ES可以用于全文搜索、结构化搜索、分析，以及三者的组合。Kibana是Amazon ES的一个开源数据可视化插件，可以与之无缝集成。
图12展示了使用Amazon ES和Kibana进行的日志分析。CloudWatch日志可以配置为通过CloudWatch日志订阅向Amazon ES实时传输日志条目。Kibana将数据可视化，并向Amazon ES中的数据存储公开一个方便的搜索接口。该解决方案可以与ElastAlert等软件结合使用，实现报警系统，以便在数据中检测到异常、峰值或其他感兴趣的模式时，发送SNS通知、电子邮件、创建JIRA票据等。
分析日志文件的另一个选择是使用Amazon Redshift和Amazon QuickSight。
Amazon QuickSight可以轻松连接到AWS数据服务，包括Amazon Redshift、Amazon RDS、Amazon Aurora、Amazon EMR、Amazon DynamoDB、Amazon S3和Amazon Kinesis。
Amazon CloudWatch日志可以作为日志数据的集中存储，除了只存储数据外，还可以将日志条目流到Amazon Kinesis data Firehose。
图13描述了一个场景，其中使用CloudWatch日志和Kinesis Data Firehose将日志条目从不同的源流到Amazon Redshift。Amazon QuickSight使用存储在Amazon Redshift中的数据进行分析、报告和可视化。
图14描述了Amazon S3上的日志分析场景。当日志存储在S3 bucket中时，日志数据可以加载到不同的AWS数据服务中，如Amazon Redshift或Amazon EMR，以分析存储在日志流中的数据并发现异常。
补充
通过将单片应用程序拆分成小的微服务，通信开销增加了，因为微服务必须互相通信。在许多实现中，使用了HTTP上的REST，因为它是一种轻量级通信协议，但是高消息量可能会导致问题。在某些情况下，可以考虑合并来回发送许多消息的服务。如果您发现自己处于这样一种情况，即您整合了越来越多的服务，只是为了减少聊天，那么您应该检查您的问题域和域模型。
在本白皮书的前面，在异步通信和轻量级消息传递一节中，讨论了不同的可能协议。对于微服务，通常使用简单的协议，如HTTP。服务交换的消息可以采用不同的编码方式，比如JSON或YAML等可读的格式，或者Avro或协议缓冲区等高效的二进制格式。
缓存是减少微服务架构延迟和聊天的好方法。根据实际的用例和瓶颈，可以使用几个缓存层。许多运行在AWS上的微服务应用程序使用Amazon ElastiCache在本地缓存结果，从而减少对其他微服务的调用量。API Gateway提供了一个内置的缓存层，以减少后端服务器上的负载。此外，缓存还有助于减少数据持久层的负载。任何缓存机制的挑战都是在良好的缓存命中率和数据的及时性/一致性之间找到适当的平衡。
审计
在微服务体系结构(可能有数百个分布式服务)中要解决的另一个挑战是确保用户对每个服务的操作的可见性，并能够在组织级别上获得所有服务的良好全局视图。为了帮助实施安全策略，审计资源访问和导致系统更改的活动是很重要的。
必须在单个服务级别以及在更广泛的系统上运行的服务之间跟踪更改。通常，微服务体系结构中经常发生更改，这使得审计更改更加重要。在本节中，我们将介绍AWS中的关键服务和特性，这些服务和特性可以帮助您审计微服务体系结构。
AWS CloudTrail是一个跟踪微服务变化的有用工具，因为它可以记录所有在AWS云中进行的API调用，并在几分钟内将其实时发送到CloudWatch日志或Amazon S3。
所有用户和自动系统操作都可以进行搜索，并且可以对意外行为、公司策略违规或调试进行分析。记录的信息包括时间戳、用户/帐户信息、调用的服务、请求的服务操作、调用者的IP地址以及请求参数和响应元素。
CloudTrail允许为同一个帐户定义多个路径，从而允许不同的涉众(如安全管理员、软件开发人员或IT审计人员)创建和管理自己的路径。如果微服务团队有不同的AWS帐户，可以将轨迹聚合到一个单独的S3 bucket中。
在CloudWatch中存储审计跟踪的优点是实时捕获审计跟踪数据，并且很容易将信息重新路由到Amazon ES进行搜索和可视化。您可以配置CloudTrail来登录Amazon S3和CloudWatch日志。
必须对系统体系结构中的某些更改做出快速响应，并且必须采取行动来纠正这种情况，或者启动特定的治理过程来授权进行更改。
CloudWatch事件与CloudTrail的集成允许它为所有AWS服务中的所有API调用生成事件。还可以定义自定义事件或基于固定的调度生成事件。
当触发事件并匹配定义的规则时，可以立即通知组织中的适当人员，使他们能够采取适当的操作。如果所需的操作可以自动化，则规则可以自动触发内置工作流或调用Lambda函数来解决问题。
图15显示了一个环境，其中CloudTrail和CloudWatch事件一起处理微服务体系结构中的审计和修复需求。CloudTrail跟踪所有微服务，审计跟踪存储在S3存储桶中。CloudWatch事件位于CloudTrail之上，当您的架构发生特定更改时，它会触发警报。
要在敏捷开发环境中维护对快速变化的基础设施配置的控制，必须使用更自动化、更受管理的方法来审计和控制体系结构。
虽然CloudTrail和CloudWatch事件是跨微服务跟踪和响应基础设施更改的重要构建块，但是AWS Config 允许公司使用特定的规则定义安全策略，从而自动检测、跟踪和警告您违反策略。
下一个示例演示如何在微服务体系结构中检测、通知和自动响应不兼容的配置更改。开发团队的一名成员对微服务的API网关进行了更改，允许端点接受入站HTTP通信流，而不是只允许HTTPS请求。因为这种情况之前已经被组织确定为安全遵从性问题，所以 AWS Config 已经在监视这种情况。
该规则将更改标识为安全违规，并执行两个操作:在S3 bucket中创建已检测到的更改日志以进行审计，并创建一个SNS通知。在我们的场景中，使用Amazon SNS有两个目的:向指定的组发送电子邮件以通知安全违规，以及向SQS队列添加消息。接下来，获取消息，并通过更改API网关配置恢复兼容状态。
结论
微服务架构是一种分布式设计方法，旨在克服传统单片架构的局限性。微服务帮助扩展应用程序和组织，同时改进周期时间。然而，它们也带来了一些挑战，可能增加额外的体系结构复杂性和操作负担。
AWS提供了大量的托管服务，可以帮助产品团队构建微服务体系结构，并最小化体系结构和操作复杂性。本篇文章将指导您了解相关AWS服务，以及如何使用AWS服务实现典型模式，如服务发现或事件源等。