迈出第一步
简介
应用程序集成是一套服务，支持微服务、分布式系统和无服务器应用程序中解耦组件之间的通信。Amazon Web Services (AWS) 提供六种以上的应用程序集成服务，可支持在云中运行的各种工作负载。
选择最适合您组织和工作负载的集成服务可能会很困难。本决策指南将帮助您提出正确的问题来了解自己的需求，并就如何评估和选择适合您工作负载的集成服务提供明确的指导。
这个 8 分半钟的片段摘自 AWS 企业战略总监 Gregor Hohpe 在 AWS re:Invent 2022 大会上的一小时演讲录音。该片段概述已推出的 AWS 应用程序集成服务。
阅读时间
20 分钟
用途
帮助确定哪些 AWS 应用程序集成服务最适合您的工作负载。
级别
新手
上次更新日期
2023 年 5 月 31 日
涵盖的服务
了解
现代化的主要优势之一是能够转移运维职责，从而让您腾出资源来开展更多增值和创新驱动的活动。
在不同程度的现代化过程中，不同的集成服务对您提出的运维要求不一而足，不论是在 Amazon Elastic Compute Cloud (Amazon EC2) 上托管消息代理（您需要管理扩展、安全配置、预配、修补等），还是无服务器产品/服务（所有底层基础设施均由 AWS 管理）。
当您开始探索和了解自己的标准、环境以及 AWS 提供的一整套集成服务时，我们建议您参考一些最佳实践。无论您选择哪种服务（或哪套服务），这些最佳实践都适用。
了解环境中的集成
一些组织在维护开源集成上花费的时间比预期的要多，这种情况很常见。我们建议您在进行此类投资时，考虑社区资源和 / 或企业或基金会的支持。对这些项目的投资不仅是财务投入，也是对知识资本和潜在技术债务的投资，因为这些组件和相关集成通常需要更新。如需了解更多信息，请参阅 AWS 开源博客。
了解您的架构特征
支持各种架构的能力非常重要。我们建议您将 AWS Well-Architected Framework 作为指南，帮助您理解在 AWS 上构建架构时所做的决策。此外，使用 Well-Architected Framework 还可让您了解在云中设计和运行可靠、可扩展、安全、高效且性价比高的系统的架构最佳实践。
使用多种集成服务组合
如果您使用专门构建的服务，那么多种服务组合可能最适合您的使用场景。以下列出了 AWS 客户使用多种服务组合的几种常见方式。
- 将 Amazon EventBridge 或 Amazon Simple Notification Service (Amazon SNS) 事件路由到 Amazon Simple Queue Service (Amazon SQS) 队列，作为下游消费者的缓冲区。
- 使用 EventBridge Pipes 直接从流（Kinesis Data Streams 或 Amazon Managed Streaming for Apache Kafka (Amazon MSK)）或队列（SQS 或 Amazon MQ）中拉取事件，并将事件发送到 EventBridge 总线以推送给消费者。
- 将 EventBridge 或 SNS 事件路由到 Kinesis Data Streams 或 Amazon MSK，以便收集和查看分析结果。
定义
一旦您对自己的标准、环境、战略方向以及可用服务（包括托管部署和托管模式）有了更清晰的认识，就需要确定集成需求。如果您要迁移到现有的集成平台或消息代理，可能已经了解了一些需求。但是，如果您要迁移到云环境，则需要确定这些需求会发生哪些变化（如有）。
消息传递或流处理平台
这些平台需要实现特定的业务功能。在考虑需要哪些功能时，请参考以下示例使用场景。
示例 1：
假设有一家保险公司会收到不同理赔类型（车险、房屋险或人寿险）的各种理赔消息，这些消息采用不同的业务规则。这可能意味着，消息使用者应具备根据消息中的标头属性将理赔信息路由到不同目的地的功能。
示例 2：
假设有一家航空公司，航班状态更新需要使用高级消息队列协议 (AMQP) 等协议通知所有互连系统，例如行李或登机口操作等。在功能和业务用例原语方面，最大的问题是如何选择最合适的消息传递平台。我们有多种选择，可以根据使用场景确定平台的适用性。
市场采用：该平台已被庞大的客户群体广泛采用，足以满足大多数使用场景；经过实践和测试，拥有活跃的支持社区，可以应对可能遇到的任何问题。这是一个低风险的决策，可为开发资源提供充足的培训。
最适合使用场景：这些平台将针对特定行业的使用场景量身定制，例如航空、物流或医疗保健。对于那些有现成模板可供采用的使用场景，它们可能是最佳选择。这些平台很容易上手，但可能缺乏市场采用程度和灵活性。采用这类平台可能需要大量的时间和资源来验证和积累内部专业知识。
现代化：这类平台采用下一代架构构建而成，可解决云规模部署、多租户、容灾和无服务器定价类型等问题。使用这类平台可能需要对工作负载进行一些重构，以实现长期可行性。云原生平台的设计，侧重于使用现代应用程序的良好架构原则。
示例 3：
如果消息传递平台需要被纳入跨多个区域的大型贷款处理工作流，那么消息传递平台也需要支持相同的业务需求。如果业务需要能够在雨天情况下恢复并回滚到以前的状态，那么底层消息传递或流媒体平台也需要具备一定的快照或重放功能，以重新创建系统状态。
您选择的集成平台应便于异步处理贷款申请，或充当多步骤媒体处理工作流的存储和转发通道。业务流程的关键程度将决定消息传递或流媒体平台所需的功能。
考虑
在考虑云中的主要应用程序集成架构时，有多种方法可以确定每个集成点的功能需求。
以下是选择应用程序集成服务时需要考虑的一些标准。
-
托管式服务和运维开销 -
开源 -
工作负载特征 -
快速迭代和功能开发速度 -
应用程序可移植性 -
自动化可移植性 -
组织规模和技能
-
考虑迁移到云，通过使用托管式服务将运维负担转移给 AWS 来降低运维成本。更高级别的抽象使开发人员和运维人员能够专注于各自特有的增值工作，而不是无差别的任务。
-
考虑在开源技术上实现标准化。开源可以使组织找到合适的技能，并避免一些受限于特定技术的风险。
在开源生态系统中做出错误的选择可能会导致受限于抽象和自行开发的集成。此外，使不同开源组件协同工作的责任通常由做出选择的组织承担。这可能导致组织花费大量时间维护开源集成。
-
在选择合适的集成服务时，了解需要在应用程序之间发送的消息的特征非常重要。消息格式、大小、保留时间和优先级等关键特征会影响集成服务的决策。
有些集成服务更适合基于文本的小型消息，而有些服务则旨在支持文本和二进制等多种格式，并提供更大的消息大小。在某些场景中，除了消息排序外，重放功能的需求也可能是一个重要因素。
例如，您可以使用 Amazon SNS 和 Amazon SQS 提供的 FIFO 功能实现消息排序。此外，还需要考虑采用基于拉取或推送的架构，例如 EventBridge 或 SNS 异步调用 Lambda 函数。
基于拉取的架构可以使用 SQS 或 Kinesis Data Streams 等服务，其中消息存储在队列或流中，然后可以被消费系统检索。Amazon MQ 等消息服务提供更大的消息有效负载功能，并支持无限保留期。但是，它们不提供重放功能。
-
如果您的主要关注点是快速构建和迭代，无服务器服务可能会提供最大价值。无服务器服务让您无需管理基础设施即可构建应用程序。它们提供托管式功能和集成，以减少编写样板代码所花费的时间。
在测试新功能时，无服务器的另一个好处是这些服务提供基于使用量的定价。您的代码仅在服务被调用时运行，因此功能测试不需要前期投入。
-
许多应用程序使用某些协议（例如高级消息队列协议 (AMQP) 或 MQ 遥测传输 (MQTT)）连接到消息服务。或者，它们对使用特定消息协议的某些库有依赖性。此类库或框架的示例包括 Spring Boot、Celery 或 MassTransit。
出于不同的原因，您可能希望保留此类应用程序。在这些情况下，集成服务的选择还取决于对所需协议的支持，以实现应用程序的可移植性。
-
您可能需要一种能与您的基础设施和部署工具兼容的服务，并运行您在本地托管的同一集成系统（例如 Apache ActiveMQ、RabbitMQ 和 Apache Kafka）。
托管式开源服务（如 Amazon MQ 和 Amazon MSK）能够提供云端的优势，同时与本地部署常用的许多部署工具兼容。
如果可以选择重构应用程序，您可以利用无服务器服务原生提供的该功能，并与各种 AWS 服务进行丰富集成。
-
在决定合适的集成服务时，您组织的技能是一个重要因素。如果您的团队熟悉自我管理的产品，且该产品能够满足您的需求，那么选择相同产品的托管式服务是影响最小的途径。这样做可以帮助您应用该服务的最佳实践，并专注于增值活动。
选择
现在您已了解评估应用程序集成需求时将使用的标准，接下来就可以选择适合您环境中工作负载的 AWS 服务。
流数据是由成千上万个数据源持续生成的数据，这些数据源通常同时以小数据量（KB 级别）发送数据记录。它包括各种各样的数据，例如客户使用您的移动或 Web 应用程序生成的日志文件、电子商务购买、游戏中的玩家活动、来自社交网络、金融交易平台或地理空间服务的信息，以及来自数据中心中互联设备或仪器的遥测数据。
AWS Step Functions 是一种无服务器编排服务，可让您与 AWS Lambda 函数和其他 AWS 服务集成，以构建关键业务应用程序。使用 Step Functions 图形控制台，您可以将应用程序的工作流视为一系列事件驱动的步骤。
Amazon Managed Workflows for Apache Airflow
Amazon Managed Workflows for Apache Airflow (Amazon MWAA) 是一种用于 Apache Airflow 的托管编排服务，可用于在云中大规模设置和操作数据管道。Apache Airflow 是一种开源工具，用于以编程方式编写、调度和监控称为工作流的流程和任务序列。
使用
您现在应该清楚地了解每个 AWS 应用程序集成服务的功能，以及哪种服务可能适合您。为了探索如何使用每种可用的 AWS 应用程序集成服务以及了解更多信息，我们提供了一条探索每个服务工作原理的路径。以下章节提供了进阶文档、实践教程和相关资源的链接，帮助您快速上手。
-
Amazon SNS
-
Amazon SQS
-
Amazon EventBridge
-
Amazon MQ
-
Amazon Kinesis Data Streams
-
Amazon MSK
-
AWS Step Functions
-
Amazon MWAA
-
Amazon SNS
-
-
Amazon SQS
-
-
Amazon EventBridge
-
-
Amazon MQ
-
-
Amazon Kinesis Data Streams
-
-
Amazon MSK
-
AWS Step Functions
-
-
Amazon MWAA
-
在 CD 管道中配置 aws-mwaa-local-runner
本教程指导您使用 Amazon Managed Workflows for Apache Airflow 的 aws-mwaa-local-runner 在 GitHub 中构建持续交付 (CD) 管道，以在本地测试您的 Apache Airflow 代码。
Amazon MWAA 分析研讨会
了解如何构建和编排包含上述多项服务的数据和机器学习管道，借此熟悉并深入理解 Airflow 提供的可用于在 AWS 上管理管道/工作流的挂钩和运算符。
