微服务之间的通信：Apache Kafka vs Hazelcast's Topic

Question

免责声明。 我有使用Hazelcast 和Vert.x 的经验。我是Apache Kafka 的新手。抱歉，如果我的问题看起来是先入为主的，那不是。

有两种广泛的方式来安排微服务之间的通信：REST 和消息传递。在我所在的地区，当有人说他们正在使用消息传递在微服务之间进行通信时——这实际上是指 Apache Kafka。

我很想知道为什么 Apache Kafka 比 Hazelcast 的 Topic 更适合微服务之间的通信需求？好点吗？因为哪些保证、特性或架构决策？

Hazelcast 的集群范围消息传递示例如下所示：

// node #1
Hazelcast.newHazelcastInstance()
         .getTopic("topic")
         .publish(new Date());

// node #2
Hazelcast.newHazelcastInstance()
         .getTopic("topic");
         .addMessageListener(message -> /*Do something here*/);

还有在 Hazelcast 的主题和成员发现之上编写的 Vert.x（非常粗略地说演员框架）。

Kafka 消息传递是否更适合微服务之间的通信？

Answer 1

Kafka 的消息传递模型/通信与其他可用的主流消息传递基础架构明显不同。虽然大多数消息传递基础设施都明确区分了主题和队列，但 Kafka 严格来说没有。 它的主题可以作为一个主题也可以作为一个队列，这种灵活性在 Hazelcast 中是不可用的。

现在。从微服务设计的角度来看，就设计选项而言，这可能会产生很大的不同。任何利用消息传递的微服务本质上都是通过异步通道进行明显的同步通信，例如 NGINX 模型。

从这个角度看下面的用例（仅示例）：

1. 有 5 个 tomcats 水平部署了 2 个 Web 应用程序，它们本质上是一个更大系统的子系统
2. 他们每个人都需要交换数据（仅根据请求读取）而没有任何其他依赖项（数据交换协议在外部定义）
3. 需要选择性地记录子系统之间的所有交互

解决方案本身很简单，发送请求，等待响应直到超时，如果收到响应则返回，否则异常返回。

从设计的角度来看，它虽然有点复杂。假设“最多一次”的处理方式，一般的设计是将请求发布到队列，从主题中读取响应。在 Hazelcast 中，它需要一个 IQueue（考虑到缩放不是一个因素）和一个 ITopic。在 Kafka 中，可以使用一个主题、两个分区和消费者组 ID 来完成。此外，可以通过向主题/分区添加或删除其他消费者来启用或禁用日志记录。

以上只是说明如何实现异步通信的示例，Hazelcast 和 Kafka（以及 JMS/Camel 等）都有自己的一套灵活性。因此，特定基础架构的选择在很大程度上取决于您的通信设计。

Answer 2

这是一个有点笼统的问题，我不是 Kafka 专家；但我会尝试讲述 Hazelcast 的消息传递功能。

Hazelcast 包含两种类型的主题；一个是常规的ITopic，另一个是Reliable Topic，它再次实现了ITopic 接口。用法基本相同，但它们的保证不同。常规ITopic 基于 Hazelcast 的事件机制，不保证消息传递。 Reliable Topic由Ringbuffer备份，由于Ringbuffer默认配置了一个同步备份，因此事件不会丢失。此外，每个 Reliable ITopic 都有自己的 Ringbuffer；如果一个主题有一个非常快的生产者，它不会导致运行速度较慢的主题出现问题。最后，由于常规 ITopic 背后的事件系统与其他数据结构（例如集合侦听器）共享，因此您可能会遇到隔离问题。 Reliable ITopic 不会发生这种情况。但是由于所有这些缺点，常规的ITopic 可以运行得更快一些，因为它使用了fire&forget 事件机制。

Apache Kafka 有自己很大的优势；例如，它全部构建为具有时间持久日志的消息流平台，因此能够将数据存储到磁盘以实现容错。

总之，如果您需要消息持久性以及应用程序消息传递所需的所有功能，请选择 Kafka，因为它更专业。但是，如果您需要一个包含消息传递支持的内存数据平台，请使用 Hazelcast。