使用多个云服务作为构建块来组装现代事件驱动应用程序的情况越来越普遍。使用专门构建的服务来完成特定任务可确保开发人员获得适合其用例的最佳功能。但是，如果服务之间使用不同的技术进行通信，它们之间的通信可能会很困难，这意味着您需要了解每个服务的细微差别以及如何将它们相互集成。我们通常需要创建集成代码（或“胶水”代码）来连接和桥接服务之间的通信。编写胶水代码会减慢我们的速度，增加错误的风险，并且意味着我们将时间花在编写无差别的代码上，而不是为我们的客户构建更好的体验。
介绍 Amazon EventBridge Pipes
今天，我很高兴地宣布推出Amazon EventBridge Pipes，它是 Amazon EventBridge 的一项新功能，通过提供一种简单、一致且经济高效的方式来创建点-事件生产者和消费者之间的点对点集成，无需编写无差别的胶水代码。
最简单的管道由源和目标组成。可选的过滤步骤仅允许特定的源事件流入管道，可选的丰富步骤使用AWS Lambda、AWS Step Functions、Amazon EventBridge API Destinations或Amazon API Gateway在事件到达目标之前丰富或转换事件。借助 Amazon EventBridge Pipes，您可以以简单、可靠、一致且经济高效的方式将受支持的 AWS 和自我管理服务作为事件生产者和事件消费者集成到您的应用程序中。
Amazon EventBridge Pipes 带来了Amazon EventBridge Event Bus最受欢迎的功能，例如事件过滤、与超过 14 种 AWS 服务的集成以及自动交付重试。
Amazon EventBridge Pipes 的工作
原理 Amazon EventBridge Pipes 为您提供了一种无缝集成支持的 AWS 和自我管理服务的方法，有利于配置而不是代码。要开始将服务与 EventBridge Pipes 集成，您需要执行以下步骤:
选择正在生成您的事件的来源。支持的来源包括:Amazon DynamoDB、Amazon Kinesis Data Streams、Amazon SQS、Amazon Managed Streaming for Apache Kafka和Amazon MQ（ActiveMQ 和 RabbitMQ）。
（可选）指定事件过滤器以仅处理与您的过滤器匹配的事件（您无需为被过滤掉的事件付费）。
（可选）使用内置的免费转换或AWS Lambda、AWS Step Functions、Amazon API Gateway或EventBridge API 目标来转换和丰富您的事件，以执行更高级的转换和丰富。
从超过 14 种 AWS 服务中选择一个目标目的地，包括 Amazon Step Functions、Kinesis Data Streams、AWS Lambda 和使用 EventBridge API 目的地的第三方 API。
Amazon EventBridge Pipes 通过减少学习服务和编写集成代码所需的时间来提供简单性来加快开发速度，以获得可靠和一致的集成。
EventBridge Pipes 还附带其他功能，可帮助构建事件驱动的应用程序。例如，通过事件过滤，Pipes 通过仅处理感兴趣的事件来帮助事件驱动的应用程序变得更具成本效益。
开始使用 Amazon EventBridge Pipes
让我们看看如何开始使用 Amazon EventBridge Pipes。在本文中，我将展示如何使用 Amazon EventBridge Pipes 将 Amazon SQS 队列与 AWS Step Functions 集成。
以下屏幕截图是我现有的 Amazon SQS 队列和 AWS Step Functions 状态机。就我而言，我需要为队列中的每个事件运行状态机。为此，我需要将我的 SQS 队列和 Step Functions 状态机与 EventBridge 管道连接起来。
首先，我打开 Amazon EventBridge 控制台。在导航部分，我选择Pipes。然后我选择创建管道。
在此页面上，我可以开始配置管道并设置 AWS Identity and Access Management (IAM) 权限，然后我可以导航到“管道设置” 选项卡。
在权限部分，我可以为此管道定义新的 IAM 角色或使用现有角色。为了提高开发者体验，EventBridge Pipes 控制台会帮我算出 IAM 角色，所以我不需要手动配置所需的权限，让 EventBridge Pipes 为 IAM 角色配置最低权限。由于这是我第一次创建管道，因此我选择了 Create a new role for this specific resource。
然后，我回到构建管道部分。在此页面上，我可以看到 EventBridge Pipes 支持的可用事件源。
我选择SQS并选择我现有的 SQS 队列。如果我需要进行批处理，我可以选择Additional settings开始定义Batch size和Batch window。然后，我选择下一步。
在下一页上，事情变得更加有趣，因为我可以从我刚刚选择的事件源定义事件过滤。此步骤是可选的，但事件过滤功能使我可以轻松处理只需要由我的事件驱动应用程序处理的事件。此外，此事件过滤功能还帮助我提高成本效益，因为此管道不会处理不必要的事件。例如，如果我使用 Step Functions 作为目标，事件过滤将只执行与过滤器匹配的事件。
我可以使用 来自 AWS 事件的示例事件 或定义自定义事件。例如，我想处理价值为 100 或更高的已退回购买商品的事件。以下是 JSON 格式的示例事件:
我还可以通过选择测试模式来进行测试，以确保此事件模式与我将要使用的自定义事件相匹配。一旦我确信这是我想要的事件模式，我就选择Next。
在下一个可选步骤中，我可以使用一个Enrichment来增强、转换或扩展事件，然后再将事件发送到目标位置。当我需要使用现有 AWS Lambda 函数或使用目标 API 的外部 SaaS API 来丰富事件时，这种丰富非常有用。此外，我可以使用Enrichment Input Transformer塑造事件。
最后一步是定义一个目标来处理这个管道传递的事件。
在这里，我可以选择 EventBridge Pipes 支持的各种 AWS 服务。我选择我现有的 AWS Step Functions 状态机，名为pipes-statemachine。
另外，我也可以参考Transforming Amazon EventBridge target input文档使用Target Input Transformer 。对于我的情况，我需要为进入该目标的事件定义高优先级。为此，我在Sample events/Event Payload中定义了一个示例自定义事件，并在Transformer部分添加了: 。然后在输出部分，我可以看到要传递给目标目标服务的最终事件。然后，我选择 创建管道。priorityHIGH
不到一分钟，我的管道就创建成功了。
要测试此管道，我需要将一个事件放入 Amaon SQS 队列中。
要检查 Step Functions 是否成功处理了我的事件，我可以在 Step Functions 中查看我的状态机。在此页面上，我看到我的事件已成功处理。
我还可以转到 Amazon CloudWatch Logs 获取更详细的日志。
事件源须知 – 在发布时，Amazon EventBridge Pipes 支持以下服务作为事件源:Amazon DynamoDB、Amazon Kinesis、Amazon Managed Streaming for Apache Kafka (Amazon MSK) 以及自我管理的 Apache Kafka、Amazon SQS（标准和 FIFO）和 Amazon MQ（均用于 ActiveMQ 和 RabbitMQ）。
事件目标– Amazon EventBridge Pipes 支持 15 个 Amazon EventBridge 目标，包括 AWS Lambda、Amazon API Gateway、Amazon SNS、Amazon SQS 和 AWS Step Functions。要将事件传递到任何 HTTPS 端点，开发人员可以使用API 目的地作为目标。
事件排序——EventBridge Pipes 维护从事件源接收的事件的排序，事件源支持在将这些事件发送到目标服务时进行排序。
编程访问– 您还可以与 Amazon EventBridge Pipes 交互并使用AWS Command Line Interface (CLI)、AWS CloudFormation和AWS Cloud Development Kit (AWS CDK)创建管道。
独立使用– EventBridge Pipes 可以独立于 Amazon EventBridge 总线和 Amazon EventBridge Scheduler 使用。这种灵活性有助于开发人员将来自受支持的 AWS 和自我管理服务的源事件定义为没有 Amazon EventBridge 事件总线的事件源。可用性– Amazon EventBridge Pipes 现已在所有 AWS 商业区域全面推出，亚太地区（海得拉巴）和欧洲（苏黎世）除外。访问Amazon EventBridge Pipes页面以了解有关此功能的更多信息并了解定价。您还可以访问文档页面以了解有关如何开始的更多信息。撰写，唐尼普拉科索，Donnie Prakoso 是 AWS 的一名软件工程师、自称咖啡师和首席开发倡导者。拥有超过 17 年的技术行业经验，从电信、银行到初创公司。他现在专注于帮助开发人员了解各种技术，以将他们的想法转化为执行。他喜欢喝咖啡，喜欢讨论从微服务到 AI/ML 的任何话题。
