原文链接：https://ably.com/topic/apache-kafka-vs-rabbitmq-vs-aws-sns-sqs
将消息从一个组件获取到另一个组件是微服务架构中最重要的部分之一。每个服务必须能够与任何其他服务异步、可靠且大规模地通信。
这就是消息代理的用武之地。消息代理（例如 Apache Kafka、RabbitMQ 和AWS SNS/SQS）为您提供一个通用接口和一组保证，而不是手动协调可能数千个微服务之间的通信。这简化了集成并更容易推理您的系统。
然而，比较消息代理可能很棘手，因为每个消息代理都采用不同的方法来完成工作。那么，您如何决定哪个消息代理最适合您的用例？
在本文中，您将找到有关业界最受欢迎的三个消息代理如何适用于不同用例的指南。我们将研究诸如它们的扩展方法、它们支持的消息传递模式以及它们如何处理性能和智能消息路由之间的权衡等特征。
比较消息代理：您应该寻找什么？
消息代理是一个广泛的类别。虽然我们正在考虑的三个选项中的每一个都在更大系统中的组件之间移动数据，但在它们之间做出决定取决于它们如何做到这一点。
因此，我们需要检查每个消息代理的特征，根据它们如何影响其移动数据的能力以及它的工作方式。我们将研究以下六个因素以及它们如何应用于 Apache Kafka、RabbitMQ 和 AWS SNS/SQS：
- **消息传递模式：**消息代理组织和分发消息的方式（例如发布/订阅或请求回复）比其他架构和用例更适合某些架构和用例。
- **消息路由：**消息代理能否根据消息的内容和其他标准来路由消息？
- **可扩展性：**并非每种情况都需要每秒处理数百万条消息。确保消息代理可以扩展到您需要的吞吐量级别，同时牢记这将如何影响设置和操作的复杂性。
- **可靠性：**消息代理如何处理故障？它会保留消息还是仅通过系统传递消息？
- **安全性：**数据是否加密？消息代理是否提供审核日志？它如何处理身份验证和访问控制？是否经过 HIPAA 和 PCI DSS 等行业标准认证？
- **成本和许可：**消息代理是开源的吗？需要哪些云或服务器资源？是否持续收取许可费？您的团队需要花费多少时间来运行它？
介绍 Apache Kafka、RabbitMQ 以及 AWS SNS 和 SQS
在详细进行比较之前，我们先来谈谈为什么我们关注这三种解决方案。原因之一是它们是您可能遇到的最常见的消息代理解决方案之一。研究表明，全球有近 50,000 家公司使用 RabbitMQ，而超过60,000 家公司正在使用 Apache Kafka。尽管 AWS SQS 的用户群似乎较小，但只有超过 24,000 家公司，但它在更广泛的 Amazon Web Services 生态系统中发挥着重要作用。这种广泛的部署使得您可以更轻松地招募经验丰富的员工、与现有技术堆栈集成，以及当您需要时寻求支持。但还有另一个考虑因素。我们正在研究的每个消息代理都从不同的角度解决该问题。 Apache Kafka 专为吞吐量而设计，而 RabbitMQ 更关注复杂的消息路由。与 RabbitMQ 一样，SNS 和 SQS 这两种 AWS 解决方案更关注路由而不是吞吐量，我们在这里考虑它们是因为 AWS 生态系统的重要性。
阿帕奇·卡夫卡
Apache Kafka 是一个实时流平台，旨在构建可扩展、容错的分布式应用程序。它专门以非常高的吞吐量传输数据，通常用于操作数据，例如日志记录和指标。
拥有如此庞大的安装基础，有一些工具可以将 Apache Kafka 连接到几乎任何其他正在运行的系统。尽管 Apache Kafka 专注于高吞吐量，但它也可以处理传输中的数据，例如触发操作和转换数据。然而，这种灵活性和强大功能是有代价的，因为 Apache Kafka 比某些替代方案更难设置和操作。
RabbitMQ
与 Apache Kafka 专注于流数据不同，RabbitMQ 是一个开源分布式消息代理，支持多种不同的消息传递模式，例如发布/订阅和生产者/消费者。尽管它确实拥有高吞吐量，但它的重点更多地是根据消息内容、一天中的时间、发送者和其他标准智能地路由数据，这使得它非常适合事件驱动的架构。
与 Apache Kafka 一样，RabbitMQ 得到了广泛的支持，具有丰富的集成生态系统。
AWS SNS 和 SQS
Amazon Web Services (AWS) 提供了两种适合消息代理旗帜的产品。 AWS Simple Notification Service (SNS) 是一种高吞吐量消息传递服务，它使用发布/订阅模型在微服务或分发应用程序的组件之间传递消息。
AWS SNS 使用主题创建单独的通知流。它还允许过滤，这样即使消费者订阅了特定主题，他们也不必接收每条消息。
AWS Simple Queue Service (SQS) 是一种先进先出 (FIFO) 队列服务，可将消息分发给潜在的大量消费者。人们倾向于同时使用 SNS 和 SQS，例如，使用 SNS 将消息发布到某个主题，然后使用 SQS 将这些消息可靠地分发到适当的目的地。
与 Apache Kafka 和 RabbitMQ 不同，SNS 和 SQS 只能通过订阅 Amazon Web Services 来使用。
比较 Apache Kafka、RabbitMQ 和 AWS SNS/SQS
为了帮助您了解哪种经纪商最适合您的使用案例，以下是它们与上述注意事项的比较。
| 阿帕奇·卡夫卡 | RabbitMQ | AWS SNS/SQS | |
|---|---|---|---|
| 消息传递模式 | 发布/订阅 | 发布/订阅点对点请求-回复 | 发布/订阅点对点 |
| 消息路由 | 愚蠢的路由器，聪明的消费者。（通过插件可实现更智能的路由） | 基于元数据或消息内容的智能路由。 | 基于元数据或消息内容的智能路由。 |
| 可扩展性 | 每秒高达数百万条消息。 | 每秒多达数千条消息。 | 每秒多达数千条消息。 |
| 可靠性 | 自愈、容错集群。 | 自愈、容错集群。 | 托管服务。 |
| 安全 | TLS 加密和身份验证SASL 授权 | TLS 加密和身份验证SASL 授权 | AWS KMS 身份验证与 AWS IAM 集成 |
| 成本和许可 | 开源。商业选择。 | 开源。商业选择。 | 持续的使用费。 |
消息传递模式
代理如何组织和分发消息几乎影响其他一切。它不仅会影响消息代理最适合的用例，还会影响应用程序架构其余部分的设计、可扩展性、性能和灵活性。
那么，Apache Kafka、RabbitMQ 和 AWS SNS/SQS 提供哪些消息传递模式？
| 图案 | 描述 | 可用性 |
|---|---|---|
| 发布/订阅（Pub/Sub） | Pub/Sub 是围绕主题构建的。发布者将消息推送到主题，由多个订阅者使用。一个简单的例子是天气系统。每个地点都有一个主题。覆盖该位置的气象站将更新推送到该主题，然后移动应用程序、警报服务等作为该主题的订阅者接收这些更新。 Pub/Sub 主要是一种单向广播方法。选择 Pub/Sub 的原因包括：-**松散耦合：发布者和订阅者不需要互相了解或直接依赖对方。- 有利于扩展：发布者推送消息一次，然后专门的代理负责将其推送给订阅者- 灵活性：**添加新主题、发布者和订阅者非常简单，这意味着系统可以轻松适应不断变化的需求。 | 阿帕奇·卡夫卡RabbitMQAWS社交网络服务 |
| 点对点消息传递 | 消息队列或点对点消息传递与 Pub/Sub 的不同之处在于，消息仅由一个订阅者而不是多个订阅者使用。通常，消费者会确认收货，这可以更深入地了解交付能力。选择点对点消息传递的原因包括：- 需要向特定收件人发送消息。- 保证交货。- 按特定顺序交付。 | RabbitMQAWS 服务质量体系 |
| 请求-回复 | 当服务需要系统另一部分的某些内容时，在请求-答复模式下，它会主动请求，然后实时等待答案。请求-答复最适合数据或操作对时间敏感的情况。例如，银行应用程序可能会在进行货币转换之前请求最新的汇率。选择请求-回复消息传递的原因包括：- 及时响应很重要，例如请求者在继续之前需要响应的情况。- 需要双向通信。- 与无法支持发布/订阅通信的遗留系统集成。 | RabbitMQ |
消息路由
在路由方面，消息代理有两种广泛的选择：
- **智能路由器，愚蠢的消费者：**代理决定将消息路由到哪里，这意味着接收消息的微服务或应用程序要做的工作更少。
- **哑路由器，智能消费者：**代理将消息发送到预定的队列，但应用程序堆栈的其他部分必须决定哪个微服务或应用程序读取哪个队列。
从广义上讲，RabbitMQ 采用智能路由器、哑消费者模型。 RabbitMQ 可以使用消息的内容、元数据、发送者、一天中的时间和其他标准来决定如何路由它。
另一方面，Apache Kafka 更适合哑路由器、智能消费者模型。然而，有一些第三方工具可以插入 Apache Kafka 来启用不同类型的智能路由。
AWS SNS 和 SQS 的组合提供了两种方法的组合。正如我们之前看到的，发布者可以为每条消息指定 AWS SNS 主题。与 RabbitMQ 类似，SNS 还允许基于消息元数据和消息正文进行更细粒度的过滤。
可扩展性
我们正在考虑的所有三个消息代理都具有良好的扩展性。但每个功能的扩展程度取决于它提供的其他功能。
消息代理采用智能路由器还是哑路由器方法在这里会产生一些影响。通过要求消息代理做更多的工作，智能路由器方法的可扩展性比哑路由器模型要差一些。
RabbitMQ 和 Apache Kafka 都是水平扩展的。换句话说，您可以创建 RabbitMQ 或 Apache Kafka 节点的集群。每个主题可以跨多个节点进行分区，因此添加更多实例可以增加集群的容量。
尽管两者之间的一些架构决策有所不同，但它们都相对容易扩展。然而，在扩展如何影响吞吐量方面，它们存在显着差异。通常，RabbitMQ每秒处理数千条消息，而即使相对较小的 Apache Kafka 集群每秒也可以处理数百万条消息。
作为托管服务，扩展 AWS SNS 和 SQS 的重点不是可以启动多少个实例，而是吞吐量限制。例如，AWS SQS每秒最多引用 30,000 条消息，并且只有在消息批量发送的情况下才如此。
可靠性
可扩展性和可靠性是齐头并进的。作为水平可扩展的分布式系统，Apache Kafka 和 RabbitMQ 都可以在单个节点离线的情况下继续存在，因为其他节点会弥补这一缺陷。
在 RabbitMQ 的情况下，各个消息在多个节点之间复制，这意味着如果一个节点发生故障，消息在其他节点上仍然可用。同样，RabbitMQ可以将消息持久化到磁盘，这样即使整个集群离线也可以恢复。
与 RabbitMQ 一样，Apache Kafka 使用多个节点来提高可用性。通常，Apache Kafka 将消息复制到三个节点，但复制因子是可配置的。如果某个节点不可用，Apache Kafka 会自动重新配置自身，以将工作负载分散到缩减后的集群中。
AWS SNS 和 SQS 采用类似的方法。它们跨多个可用区（即 AWS 区域内的独立数据中心）复制消息，以便集群能够在一个区域发生中断时幸存下来。与 RabbitMQ 和 Apache Kafka 一样，消息可以持久保存到磁盘，以便在发生较大故障时进行恢复。
安全
除了信任每个供应商/项目如何解决安全漏洞之外，消息代理的安全性还取决于三个因素：
- **身份验证：**验证发布者和消费者的身份以授予对消息代理的访问权限。
- **授权：**使用访问控制列表 (ACL) 来确定每个发布者和消费者可以使用哪些主题和功能。
- **数据加密：**在数据通过系统（传输中）和磁盘上（静态）时保护数据。
与许多事情一样，Apache Kafka 的身份验证可通过使用第三方附加组件进行配置。默认情况下，Apache Kafka 提供 TLS 或SASL身份验证。 TLS 身份验证使用公私密钥对来确认是否允许客户端访问 Apache Kafka 实例。 SASL 提供不同级别的身份验证，从用户名和密码到 OAUTH 2.0。
同样，RabbitMQ使用 X.509 证书提供基于 TLS 的身份验证。或者，RabbitMQ 可以支持用户名/密码对进行身份验证。
Apache Kafka 和 RabbitMQ 都允许通过 ACL 授予细粒度的权限，例如读取、写入、配置和管理。
与此处的许多因素一样，AWS SNS/SQS 略有不同，因为它们是 AWS 生态系统的一部分。因此，他们主要使用 Amazon 的 IAM 证书进行身份验证和访问控制。
不过，在数据加密方面，这些产品之间的差异较小。默认情况下，Apache Kafka 和 RabbitMQ 都以明文形式发送数据，但也可以使用 TLS 加密传输中的数据。就 Apache Kafka 而言，有许多第三方插件可以支持其他形式的传输中加密。 Apache Kafka 和 RabbitMQ 都不加密静态数据，而是建议使用第三方工具，例如加密文件系统。 AWS SNS 和 SQS 依赖AWS Key Management Service来加密静态和传输中的数据。
成本和许可
计算总拥有成本 (TCO) 可能很复杂。 RabbitMQ 和 Apache Kafka 都是开源项目，使用时不需要许可费用。然而，值得注意的是，Apache Kafka 在设置和操作方面可能会带来挑战，这可能意味着您需要聘请专门的员工或顾问来管理和管理部署。
在较小的规模下，RabbitMQ 比 Apache Kafka 更容易运行，并且以其操作稳定性而闻名。如果您选择 Apache Kafka 或 RabbitMQ 的商业版本，显然这会带来许可成本，但您也将受益于附加功能、增强的文档和支持，这反过来又可以降低其他方面的成本。
同样，AWS 产品在这里很奇怪，因为它们不是开源的，只能作为托管服务提供。这将许可、云和运营成本整合到一张账单中。
您应该使用哪个消息代理？
Apache Kafka、RabbitMQ 和 AWS SNS/SQS 都是消息代理，但它们都有自己的优点和缺点。
- Apache Kafka 以其高吞吐量和扩展到非常大的吞吐量的能力而闻名，这使其成为需要实时处理大量数据的应用程序的不错选择。
- RabbitMQ 不太关注纯粹的吞吐量，而更多地关注智能路由消息。
- AWS SNS 和 SQS 的组合比其他两个选项更易于设置和运行，但随着工作负载的扩展，可能会产生成本影响。
那么，哪个消息代理适合您的项目？需要考虑的最重要因素是：
- 它根据消息的内容和元数据路由消息的能力如何。
- 数据量和吞吐量。
- 可扩展性和容错性。
- 安全功能。
- 成本和所有权模型。
考虑到这一点，以下是选择消息代理的一些建议：
- 非常大的数据量、灵活的可扩展性和基本的路由需求：Apache Kafka。
- 大量数据和复杂的路由：RabbitMQ。
- 大量数据和完全托管选项：AWS SNS 和 SQS。