java - 使用 Apache Camel 和/或 ActiveMQ 在 Java Boot 集成微服务中实现持久重新交付

Question

我想开发一个小型集成微服务，实现两个现有系统之间的通信。

系统 A 有一个 Apache Kafka 主题生产和消费消息。

系统 B 具有 REST API 并能够调用 REST API 回调。

我正在尝试开发的解决方案必须能够与每个系统通信，转换消息并将其传递到另一个系统（同时进行大量日志记录等）。消息的数量和消息的大小很小。性能将不是问题。

我选择的堆栈是 Spring Boot + Apache Camel 用于路由 + ELK 用于日志记录（+ 模板引擎等，这并不相关）。

我主要关心的是保证交货的要求。根据我的阅读，Camel 将消息存储在内存中，这意味着重新启动/更新我的微服务可能会丢失一些不可接受的数据。

实施保证交付的相关行业标准是什么？我正在研究 ActiveMQ，但不确定我是否需要带大枪，因为解决方案很小并且数据量很小。不过我并不太反对这个想法。

我想我的问题是

1. 将 3rd 方 Kafka 与 3rd 方 REST 系统集成时，实现持久保证交付的优雅方法是什么？
2. 为了一个小的微服务而带来一个完整的消息代理是不是太过分了？

标签： javaapache-kafkaapache-camelmicroservicesactivemq

Answer 1

1. 简而言之——不，没有一种“优雅”的方式来实现它。卡夫卡确实不能做到本义意义上的保证交付。Kafka 解决方案通常依赖于所有支持多次重放相同数据能力的端点（或者消费者能够跟踪已经交付的内容并丢弃重复消息）。与 REST 相同 - REST 端点（以及一般的 HTTP，不支持有保证的交付。

2. 这是一个主观的问题，但我会尽量客观地回答——ActiveMQ 的占用空间比 Kafka 小。如果您使用的是 Camel，您可以轻松地将占用空间小的 ActiveMQ 代理与 Camel 路由放在一起。这是一种常见的架构——自 Camel 成立以来就一直存在。或者，如果消息量很低，独立的 ActiveMQ 代理就像运行单个容器或 Java 进程一样简单。

“Kafka to Queued Messaging”是一种常见的模式，用于向其他系统提供有保证的交付。这集中了到排队消息传递代理的网络链接的错误处理和重试。然后，您的骆驼路线将从队列中读取。您可以使用 JMS 本地事务安全地将队列到一个 REST 端点视为类似 XA 的保证交付。