比较：JMS 消息队列与 Apache Kafka
本文探讨了 JMS 消息代理和 Kafka 部署的差异、权衡和架构。
每天分享最新软件开发，Devops，敏捷，测试以及项目管理最新，最热门的文章，每天花3分钟学习何乐而不为，希望大家点赞，评论，加关注，你的支持是我最大的动力。下方抖音有我介绍自动化测试，以及google cloud 相关视频课程，欢迎观看。
比较基于 JMS 的消息队列 (MQ) 基础架构和基于 Apache Kafka 的数据流是一个广泛的话题。不幸的是，这场战斗是苹果与橙子的比较，通常包括来自供应商的错误信息和 FUD。本文探讨
JMS 消息代理和 Kafka 部署的区别、权衡和架构
。了解如何在 JMS 代理（如 IBM MQ 或 RabbitMQ）和开源 Kafka 或无服务器云服务（如 Confluent Cloud）之间进行选择。
动机：苹果与橘子之战
我必须每周在客户会议上讨论 JMS 消息代理和 Apache Kafka 之间的差异和权衡。 最让我恼火的是各种博客、文章和有关此讨论的演示文稿中的 常见 误解和（有时）故意 FUD 。
我最近在“Coding over Cocktails”播客： JMS 与 Kafka：Technology Smackdown中与 Red Hat 的 Clement Escoffier 讨论了这个话题。一场精彩的对话，比你想象的要多得多，我选择了“Kafka 支持者”，而 Clement 接任了“JMS 支持者”的角色。
这些方面促使我写了一个 关于“JMS、消息队列和 Apache Kafka”的博客系列 ：
- 这篇文章： JMS 消息代理与 Apache Kafka 数据流的 10 个比较标准
- Apache Kafka 中死信队列 (DQL) 的 替代方案
- 使用 Apache Kafka实现 请求-回复模式
- 即将推出： 用于选择正确消息传递系统的 决策树 （JMS 与 Apache Kafka）
- 即将到来： 从 JMS 消息代理到 Apache Kafka： 集成、迁移和/或替换
特别感谢我的同事和长期消息传递和数据流专家 Heinz Schaffner 对本系列的技术反馈和审查。他在 TIBCO、Solace 和 Confluent 工作了 25 年。
10 个比较标准：JMS 与 Apache Kafka
本文探讨了十个比较标准。目的是 解释 消息队列和数据流之间的区别，澄清关于 API 或实现是什么的 一些误解，并提供一些技术背景 来进行评估以找到适合工作的工具。
JMS 实现和 Kafka 产品的产品和云服务列表很长。几个例子：
- JMS API 的 JMS 实现 （开源和商业产品）：Apache ActiveMQ、Apache Qpid（使用 AMQP）、IBM MQ（以前的 MQSeries，然后是 WebSphere MQ）、JBoss HornetQ、Oracle AQ、RabbitMQ、TIBCO EMS、TIBCO Cloud Messaging、安慰之类的。
- Apache Kafka 产品、云服务和重写 （超出仅使用开源 Kafka 的有效选项）：Confluent、Cloudera、Amazon MSK、Red Hat、Redpanda、Azure Event Hubs 等。
以下是比较 JMS 消息代理与 Apache Kafka 及其相关产品/云服务的标准：
- 消息代理与数据流平台
- API 规范与开源协议实现
- 事务性与分析性工作负载
- 推送与拉取消息消费
- 简单与强大和复杂的 API
- 持久性存储与真正的解耦
- 服务器端数据处理与解耦连续流处理
- 复杂操作与无服务器云
- Java/JVM 与任何编程语言
- 单一部署与多区域（包括混合和多云）复制
现在让我们探讨十个比较标准。
1. 消息代理与数据流平台
TL;DR： JMS 消息代理提供消息传递功能来生成和使用消息。Apache Kafka 是一个数据流平台，结合了消息传递、存储、数据集成和流处理功能。
首先最重要的方面： JMS 和 Apache Kafka 的比较是苹果与橙色的比较，原因有几个 。我什至会进一步说，并非两者都可以成为水果，因为它们彼此如此不同。
JMS API（以及 IBM MQ、RabbitMQ 等实现）
JMS（Java 消息服务） 是提供通用消息模型的 Java 应用程序编程接口 (API)。API处理生产者-消费者问题，可以方便 软件系统之间的消息发送和接收 。
因此， JMS 消息代理 （实现 JMS API）的核心功能是 将消息从源应用程序实时发送到另一个目的地 。而已。如果这正是您所需要的，那么 JMS 就是您的正确选择！但请记住，项目必须使用额外的工具来完成数据集成和高级数据处理任务。
Apache Kafka（开源和供应商，如 Confluent、Cloudera、Red Hat、Amazon 等）
Apache Kafka 是一种用于数据流的开源协议实现 。这包括：
- Apache Kafka 是分布式消息传递和存储的核心。高吞吐量、低延迟、高可用性、安全。
- Kafka Connect 是一个用于将外部源/目标连接到 Kafka 的集成框架。
- Kafka Streams 是一个简单的 Java 库，支持在 Kafka 框架内进行流式应用程序开发。
这种功能组合能够构建 端到端数据管道和应用程序 。这比使用消息队列所能做的要多得多。
2. JMS API 规范与 Apache Kafka 开源协议实现
TL;DR： JMS 是供应商以他们自以为是的方式实施和扩展的规范。Apache Kafka 是底层指定 Kafka 协议的开源实现。
在评估 JMS 和 Kafka 之前，首先澄清这些术语至关重要：
- 标准 API ：由行业联盟或其他行业中立（通常是全球性）团体或组织指定，指定标准 API。需要对所有功能进行合规性测试并完成认证才能符合标准。示例： OPC-UA 。
- 事实标准 API ：源自现有的成功解决方案（开源框架、商业产品或云服务）。示例： Amazon S3 （来自单一供应商的专有）。 Apache Kafka （来自充满活力的社区的开源）。
- API 规范 ：定义供应商如何实现相关产品的规范文档。对于所有功能的实施，没有完整的合规性测试或完整的认证。结果是“标准 API”，但实现之间没有可移植性。示例： JMS。 特别是对于 JMS，请注意，为了能够使用 JMS 的合规性套件，商业供应商必须向 Oracle 签署非常繁重的报告要求。
替代类型的标准需要权衡取舍。如果您想了解更多信息，请查看过去几年 Apache Kafka 如何成为数据流的事实标准。
与过去几十年将工作负载放在单个数据中心相比，可移植性和迁移在混合和多云环境中变得更加重要。
JMS 是面向消息的中间件的规范
JMS 是 目前在 Java Community Process 下作为 JSR 343 维护的规范。最新（尚未发布）版本 JMS 3.0 作为 Jakarta EE 的一部分正在早期开发中，并更名为 Jakarta Messaging API。今天， JMS 2.0 是流行的消息代理实现中使用的规范 。没有人知道 JMS 3.0 将走向何方。因此，本文重点介绍 JMS 2.0 规范以解决当今的实际问题。
在以下部分中，我经常使用术语“JMS 消息代理”，因为 JMS（即 API）并没有指定或实现您在最喜欢的 JMS 实现中所知道的许多特性。通常， 当人们谈论 JMS 时，他们指的是 JMS 消息代理实现，而不是 JMS API 规范 。
JMS 消息代理和 JMS 可移植性神话
开发 JMS 规范是为了提供一个通用 Java 库来访问不同的消息传递供应商的代理。它旨在充当消息传递供应商专有 API 的包装器，就像 JDBC 为数据库 API 提供类似功能一样。
不幸的是，这种简单的集成结果并非如此。将 JMS 代码从一个供应商的代理迁移到另一个供应商非常复杂，原因如下 ：
- 并非所有 JMS 功能都是必需的（安全性、主题/队列标签、集群、路由、压缩等）
- 没有用于传输的 JMS 规范
- 没有规范来定义如何实现持久性
- 没有规范来定义如何实现容错或高可用性
- 不同供应商对 JMS 规范的不同解释可能导致相同 JMS 功能的其他行为
- 没有安全规范
- broker 中没有关于增值功能的规范（例如主题到队列桥接、broker 间路由、访问控制列表等）
因此， JMS 供应商之间的简单源代码迁移和互操作性是一个神话！ 这听起来很疯狂，不是吗？
供应商在代理中提供了大量独特的功能（例如主题到队列的映射、代理路由等），它们为应用程序提供架构功能，但它们是代理功能的一部分，而不是应用程序或 JMS 的一部分规格。
Apache Kafka 是数据流的开源协议实现
Apache Kafka 是一种 实时执行可靠且可扩展的数据流的实现。该项目是 开源的，在 Apache 2.0 许可下可用， 并由一个庞大的社区驱动。
Apache Kafka 不是 OPC-UA 之类的标准或 JMS 之类的规范 。但是，Kafka 至少提供了源代码参考实现、协议和 API 定义等。
Kafka 将自己确立为数据流的事实标准。今天，超过 100,000 个组织使用 Apache Kafka。Kafka API 成为事件驱动架构和事件流的 事实标准 。它在所有行业和基础设施中都有用例，包括各种事务和分析工作负载。边缘、混合、多云。
现在，等一下。我在上一节中使用了术语 Kafka API。让我们澄清一下：如前所述， Apache Kafka 是 分布式数据流平台的实现，包括服务器端和客户端以及用于生产和消费事件、配置、安全性、操作等 的各种 API。Kafka API 是相关的，同样，因为 Kafka 重写， 如 Azure Event Hubs 和 Redpanda 使用它 。
Apache Kafka 的可移植性：又一个神话？
如果您使用 Apache Kafka 作为开源项目，这就是完整的 Kafka 实现。一些供应商使用完整的 Apache Kafka 实现并围绕它构建更高级的产品。
在这里， 迁移非常简单，因为 Kafka 不仅仅是每个供应商实施不同的规范 。相反，它是相同的代码、库和包。
例如，我已经看到从 Cloudera 到 Confluent 部署或从自我管理的 Apache Kafka 开源基础架构到无服务器 Confluent Cloud 的几次成功迁移。
Kafka API：Kafka Rewrites Like Azure Event Hubs、Redpanda、Apache Pulsar
随着 Kafka 在全球取得成功，一些供应商和云服务并没有在 Apache Kafka 实施之上构建产品。相反，他们 在 Kafka API 之上进行了实现 。底层实现是专有的（如 Azure 的云服务事件中心）或开源的（如 Apache Pulsar 的 Kafka 桥或 Redpanda 用 C++ 重写）。
仔细分析供应商是否集成了整个 Apache Kafka 项目或重写了完整的 API。 与久经考验的 Apache Kafka 项目相反，使用 Kafka API 重写 Kafka 是一个全新的实现！
许多供应商甚至在其支持条款和条件中完全排除了某些组件或 API（例如用于数据集成的 Kafka Connect 或用于流处理的 Kafka Streams），或者排除了诸如一次性语义或长期存储等关键特性。
您可以评估不同的 Kafka 产品及其局限性。最近，我比较了 Confluent、Cloudera、Red Hat 或 Amazon MSK 等 Kafka 供应商和 Azure Event Hubs、AWS Kinesis、Redpanda 或 Apache Pulsar 等相关技术。
只需自己对要求进行战斗测试。如果您发现 Kafka-to-XYZ 桥的代码少于一百行，或者如果您发现从中间件供应商处下载的 .exe Windows Kafka 服务器。持怀疑态度！:-)
所有闪光的不都是金子。一些框架或供应商听起来好得令人难以置信。 仅仅说您支持 Kafka API，您提供了完全托管的无服务器 Kafka 产品，或者如果您不断被迫在 Kafka 上提供恐惧、不确定性和怀疑 (FUD)并且您的能力要好得多，那么您可以更好地扩展是不可信的。例如，我对 Pulsar 总是试图通过在开源社区中创建大量 FUD 和神话来变得比 Kafka 更好而感到恼火。 我在我的Apache Pulsar 与 Kafka 比较中做出了回应两年前。FUD 对任何供应商来说都是错误的策略。这没用。出于这个原因，Kafka 的采用率仍在疯狂增长，而 Pulsar 的百分比增长要慢得多（尽管下载量无论如何都处于低得多的水平）。
3. 事务性与分析性工作负载
TL;DR： JMS 消息代理为少量消息提供事务功能。Apache Kafka 支持支持事务和分析工作负载的少量和大量消息。
JMS：会话和两阶段提交 (XA) 事务
大多数 JMS 消息代理都很好地支持事务性工作负载。
事务处理会话支持单个事务 系列。每个事务将一组产生的消息和一组消费的消息组合成一个原子工作单元。
两阶段提交事务（XA 事务） 在有限的范围内工作 。它们用于与大型机 CICS / DB2 或 Oracle 数据库等其他系统集成。但是它 很难操作，并且不可能扩展 到每秒几笔交易。
需要注意的 是，JMS 2.0 规范并不强制支持 XA 事务 。这与会话事务不同。
Kafka：Exactly-once 语义和事务 API
Kafka 是一个 分布式的容错系统，具有弹性 （如果您正确部署和操作它）。 可以保证没有停机时间和数据丢失， 就像在您最喜欢的数据库、大型机或其他核心平台中一样。
甚至更好： Kafka 的 Transaction API，即Exactly-Once Semantics (EOS) ，从 Kafka 0.11（多年前 GA'ed）开始可用。EOS 使构建事务工作负载变得更加容易，因为您不再需要处理重复项。
Kafka 通过事务 API 支持跨多个分区的原子写入 。这允许生产者将一批消息发送到多个分区。批处理中的所有消息最终对任何消费者都是可见的，或者对消费者不可见。
Kafka 事务的工作方式与 JMS 事务非常不同。 但目标是相同的：每个消费者只接收一次生成的事件。在博客文章“使用 Apache Kafka 的数据流中的分析与事务”中查找更多详细信息。
4. Push vs. Pull 消息消费
TL;DR： JMS 消息代理将消息推送到消费者应用程序。Kafka 消费者拉取消息，为独立的消费者应用程序提供真正的解耦和背压处理。
对于像基于 JMS 的消息代理这样的实时消息系统来说，推送消息似乎是显而易见的选择。但是， 基于推送的消息传递在解耦和可扩展性方面存在各种缺点 。
JMS 希望代理提供背压并实现“预取”功能，但这不是强制性的。如果使用，代理将控制您无法控制的背压。
使用 Kafka，消费者可以控制背压。每个 Kafka 消费者实时、批量或仅按需消费事件 ——以特定消费者支持和处理数据流的方式。对于许多不灵活和非弹性的环境来说，这是一个巨大的优势。
因此，虽然 JMS 有某种背压，但如果队列已满，生产者就会停止。在 Kafka 中，您可以控制消费者的背压。无法使用 JMS 扩展生产者（因为 JMS 队列或主题中没有分区）。
JMS 消费者可以扩展，但您会失去有保证的排序。 JMS 消息代理中的保证排序仅通过单个生产者、单个消费者和事务起作用 。
5. 简单的 JMS API 与强大而复杂的 Kafka API
TL;DR： JMS API 提供了简单的操作来生成和使用消息。Apache Kafka 有一个更细粒度的 API，它带来了额外的功能和复杂性。
JMS 供应商在规范下的实现中隐藏了所有很酷的东西。你只得到 5%（无控制，由供应商构建）。你需要自己做剩下的。另一方面，卡夫卡暴露了一切。大多数开发人员只需要 5%。
总之，请注意 JMS 消息代理的构建是为了将消息 从数据源发送到一个或多个数据接收器。 Kafka 是一个数据流平台，提供更多功能、特性、事件模式和处理选项；并且规模更大 。考虑到这一点，API 非常不同并且具有不同的复杂性也就不足为奇了。
如果您的用例只需要每秒从 A 向 B 发送几条消息，那么 JMS 是正确的选择并且使用简单！如果您需要任何规模的流数据中心，包括数据集成和数据处理，那只有 Kafka。
异步请求-回复与动态数据
JMS 开发人员最常见的愿望之一是使用 Kafka 中的请求-响应功能 。请注意，这种设计模式在消息传递系统中与 RPC（远程过程调用）不同，正如您从 Corba 等遗留工具或 SOAP/WSDL 或 HTTP 等 Web 服务标准中了解的那样。 消息代理中的请求-回复是一种利用相关 ID 的异步通信 。
从生产者（比如移动应用程序）到消费者（比如数据库）获取事件的异步消息传递是一种非常传统的工作流程。无论您是执行即发即弃还是请求回复。您将数据置于静止状态以供进一步处理。 JMS 支持开箱即用的请求-回复 。API 非常简单。
带有事件流的动态数据不断地处理数据。Kafka 日志是持久的。Kafka 应用程序实时或批量维护和查询状态。对于大多数开发人员和架构师来说，数据流是一种范式转变。设计模式非常不同。 不要尝试使用相同的模式和 API 在 Kafka 中重新实现 JMS 应用程序。 那很可能会失败！那是一种反模式。
请求-回复效率低下，并且根据用例可能会遭受很多延迟 。HTTP 或更好的 gRPC 适用于某些用例。Request-reply 被 CQRS（命令和查询责任分离）模式替换为流数据的 Kafka 。CQRS 在 JMS API 中是不可能的，因为 JMS 不提供状态功能并且缺乏事件溯源功能。
请求-响应模式的 Kafka 示例
对于许多 Kafka 用例，CQRS 是更好的设计模式。尽管如此， 请求-回复模式也可以用 Kafka 来实现。 但不一样。尝试像在 JMS 消息代理中那样做（带有临时队列等）最终会杀死 Kafka 集群（因为它的工作方式不同）。
Spring 项目展示了如何做得更好。Kafka Spring Boot Kafka 模板库有一个很好的使用Kafka 构建的请求-回复模式的示例。
查看“ org.springframework.kafka.requestreply.ReplyingKafkaTemplate ”。它使用 Kafka API 轻松创建请求/回复应用程序。该示例很有趣，因为它实现了异步请求/回复，如果您使用例如 JMS API，则编写起来会更复杂）。另一篇不错的 DZone 文章讨论了使用 Spring Kafka模板进行同步请求/回复。
Kafka 模板的 Spring 文档有很多关于 Kafka 的请求/回复模式的详细信息。 因此，如果您使用的是 Spring，那么使用 Kafka 实现请求/回复模式非常简单。 如果您不使用 Spring，您可以学习如何在您的框架中使用 Kafka 进行请求-回复。
6. 持久性存储与真正的解耦
TL;DR： JMS 消息代理使用存储系统来提供高可用性。Kafka 的存储系统更先进，可以实现历史事件的长期存储、背压处理和可重放性。
Kafka 存储不仅仅是您从 JMS 了解的持久性功能
当我向有经验的 JMS 开发人员解释 Kafka 存储系统时，我几乎总是得到相同的回应：“我们的 JMS 消息代理 XYZ 也有存储。我看不到使用 Kafka 的好处！”
JMS 使用临时存储系统，其中消息仅在被处理之前被持久化。 消息的长期存储和可重放性不是 JMS 设计的概念。
仅附加日志、偏移量、保证排序、保留时间、压缩主题等的核心 Kafka 原则提供了许多超出 JMS 的持久性保证的额外好处。 背压处理、消费者之间的真正解耦、历史事件的可重放性等等是 JMS 和 Kafka 之间的巨大差异。
查看 Kafka 文档以深入了解 Kafka 存储系统。我不想谈论 Kafka 的 分层存储 如何通过在 Kafka 日志中提供更好的可扩展性和具有成本效益的长期存储来进一步改变游戏规则。
7. 使用 JMS 的服务器端数据处理与使用 Kafka 的解耦连续流处理
TL;DR： JMS 消息代理提供简单的服务器端事件处理，例如基于消息内容的过滤或路由。卡夫卡经纪人很愚蠢。它的数据处理在解耦的应用程序/微服务中执行。
服务器端 JMS 过滤和路由
大多数 JMS 消息代理都为服务器端事件处理提供了一些功能。这些功能对于某些工作负载很方便！
请注意，服务器端处理通常是有代价的。例如：
- JMS 预过滤可伸缩性问题 ：代理必须处理很多事情。这可以以隐藏的方式杀死经纪人
- JMS 选择器（= 路由）性能问题 ：它会杀死 40-50% 的性能
同样，有时，缺点是可以接受的。那么这是一个很棒的功能。
Kafka：哑管道和智能端点
Kafka 故意不提供服务器端处理 。经纪人傻了。处理发生在智能端点。这是一个非常著名的设计模式：哑管道和智能端点。
缺点 是您需要 单独 的应用程序/微服务/数据产品来实现逻辑。这在无服务器环境中不是大问题（例如使用在 Confluent Cloud 中运行的 ksqlDB 进程进行数据处理）。它在自我管理的环境中变得更加复杂。
然而，这种架构的 巨大好处 是应用程序/技术/编程语言之间的 真正解耦 ，用于构建业务逻辑和基础设施操作的业务单元之间 的关注点分离，以及更好的可扩展性和弹性 。
我是否也想在 Kafka 中看到一些服务器端处理能力？是的，一点没错。特别是对于小型工作负载，性能和可扩展性的影响应该是可以接受的！不过，风险在于人们会滥用这些功能。未来将显示卡夫卡是否会到达那里。
8. 复杂操作与无服务器云
TL;DR： 可扩展 JMS 消息代理或 Kafka 集群的自我管理操作很复杂。无服务器产品（应该）承担运营负担。
操作集群很复杂，不管是 JMS 还是 Kafka
一个 基本的 JMS 消息代理相对容易操作 （包括主动/被动设置）。但是，这 限制了可扩展性和可用性 。JMS API 旨在与单个代理或主动/被动通信以实现高可用性。这个概念涵盖了 应用领域 。
不仅如此（= 集群 ） 对于 JMS 消息代理来说非常复杂 。来自商业供应商的更高级的消息代理集群更强大，但更难操作。
Kafka 是一个 强大的分布式系统 。因此， 操作 Kafka 集群本质上并不容易 。像 Kubernetes 操作员这样的云原生工具承担了滚动升级或处理故障转移等一些负担。
JMS 消息代理和 Kafka 集群都更具挑战性，您的 SLA 要求的规模和可靠性就越高。 没有为中央数据中心 （使用集群）指定 JMS API。Kafka 是专门为战略企业架构 而构建的，而不仅仅是单个业务应用程序。
完全托管的无服务器云救援
由于 JMS API 旨在与单个代理通信，因此很难构建提供可扩展性的无服务器云产品 。因此，在 JMS 云服务中，消费者必须为特定代理设置路由和基于角色的访问控制。 这样的云产品不是无服务器的，而是洗云的 ！但是没有其他选择，因为 JMS API 不像具有大型分布式集群的 Kafka。
在卡夫卡，情况就不同了。 由于 Kafka 是一个可扩展的分布式系统，云提供商可以构建云原生无服务器产品 。构建这样一个完全托管的基础设施仍然非常困难。因此，评估产品，而不仅仅是营销口号！
每个 Kafka 云服务都标榜为“完全托管”或“无服务器”，但大多数不是 。相反，大多数供应商只是配置基础设施，让您操作集群并承担支持风险。另一方面，一些完全托管的 Kafka 产品在功能上非常有限（比如允许非常有限数量的分区）。
一些云供应商甚至从他们的 Kafka 云产品中排除了对 Kafka 的支持 。疯狂，但真实。检查条款和条件作为评估的一部分。
9. Java/JVM 与任何编程语言
TL;DR： JMS 专注于 JVM 编程语言的 Java 生态系统。Kafka 独立于编程语言。
正如名称 JMS（=Java 消息服务） 所说：JMS 是正式为 Java 编写的。一些代理供应商支持他们自己的 API 和客户端。这些是该供应商专有的。我过去见过的几乎所有严重的 JMS 项目都使用 Java 代码。
Apache Kafka 也只提供了一个 Java 客户端 。但是 供应商和社区为几乎所有编程语言提供了其他语言绑定，以及用于 HTTP 通信的 REST API，用于生成/消费来自 Kafka 的事件 。例如，查看博文“ 12 种编程语言走进 Kafka 集群”，查看 Java、Python、Go、.NET、Ruby、node.js、Groovy 等的代码示例。
Kafka 后端的 真正解耦使非常不同的客户端应用程序能够相互交流，无论使用哪种编程语言 。这种灵活性允许构建一个适当的领域驱动设计 (DDD)，其中微服务架构利用 Kafka 作为中枢神经系统。
10. 单 JMS 部署与多区域（包括混合云和多云）Kafka 复制
TL;DR： JMS API 是应用程序和代理之间通信的客户端规范。Kafka 是一个分布式系统，可为混合云和多云用例提供各种架构。
JMS 是客户端规范，而多数据中心复制是代理功能。我不会在这里深入，简单地说： JMS 消息代理不是为跨区域、大洲或混合/多云环境的复制场景而构建的 。
Apache Kafka 的多集群和跨数据中心部署已成为常态而非例外。各种 场景需要多集群Kafka解决方案 。需要考虑具体要求和权衡取舍。
诸如 MirrorMaker（开源）或 Confluent Cluster Linking（商业）等 Kafka 技术支持灾难恢复、分析聚合、云迁移、任务关键型延伸部署和全球 Kafka 部署等用例。
JMS 和 Kafka 解决不同的问题
10 个比较标准表明 JMS 和 Kafka 是非常不同的东西 。虽然两者重叠（例如，消息传递、实时、关键任务），但它们使用不同的技术能力、特性和架构来支持其他用例。
简而言之， 使用 JMS 代理进行从 A 到 B 的简单和低容量的消息传递 。 Kafka 通常是许多数据源和数据接收器之间的实时数据中心 。许多人称其为企业架构的中央实时神经系统。
Kafka 在任意规模的数据集成和数据处理能力以及真正的解耦和事件可重放性是与基于 JMS 的 MQ 系统的主要区别。
但是，尤其是 在无服务器云中，不要担心 Kafka 太强大（太复杂） 。无服务器 Kafka 项目通常以非常低的容量以非常便宜的方式开始， 没有运营负担 。然后它可以随着您不断增长的业务而扩展，而无需重新构建应用程序。
了解基于 JMS 的消息代理和由 Apache Kafka 提供支持的数据流之间的技术差异。 评估这两个选项以找到解决问题的正确工具 。在消息传递或数据流中，进行更详细的评估。每个消息代理都是不同的，即使它们都符合 JMS。同样，所有 Kafka 产品和云服务在功能、支持和成本方面都不同。
您是否使用符合 JMS 的消息代理？有哪些用例和限制？您什么时候或打算改用 Apache Kafka？