Apache Kafka 之上基于 XSLT 的转换“服务”

Question

在我写这个问题的那一刻，没有（还）任何用 [apache-kafka] 和 [xslt] 标记的问题。

我是一个“经典”的面向消息的中间件（BizTalk、TIBCO 等），刚刚发现 Kafka 及其令人印象深刻的性能数据！

然后，我想知道“Kafka-community”关于如何在发布和消费之间转换消息有效负载的建议......

确实，在我的集成世界中，生产者公开的数据结构（即格式）通常与消费者期望的数据结构（格式）完全不同。例如，作为生产者，我可能有一个大型机应用程序在 COBOL 字帖结构中格式化数据，而我的前端应用程序想要使用现代 JSON 格式。

[根据@morganw09dev 的第一个答案更新]

我喜欢@morganw09dev 的提议，但我对创建特定于消费者的主题有点“恼火”。我将“主题 B”（参见 @morganw09dev 的第一个答案）视为我的前端应用程序的特定主题，以便使用“主题 A”中的信息。换句话说，这种特殊性使“主题 B”成为一个队列 ;-) 很好，但我想知道这样的设计是否不会“伤害”Kafka-native ;-)

从我对 Kafka 的初步阅读来看，很明显我还应该了解更多关于 Storm 的知识......但是，然后，我发现 Flink，根据https://flink.apache.org/features.html 的图表，看起来比 Storm 性能要好得多，现在@morganw09dev 提到了 Samza！这意味着我不知道从哪里开始 ;-)

最后，我想在 XSLT 中编写我的转换代码，并且在 Java 世界中，我认为 Saxon 是领先的 XSLT 处理器之一。您知道 Saxon 与 Storm、Flink 或 Samza 的任何“集成”吗？或者，也许我的问题没有意义，我必须找到另一种“方式”来使用 Saxon 和 Kafka。

在我写这篇评论的那一刻，（还）没有任何问题被标记为 [saxon] 和任何 [apache-kafka]、[apache-storm]、[apache-flink] 和/或[apache-samza]。

Answer 1

Kafka 本身不能用于转换数据。它仅用于存储稍后使用的数据。

一个想法是有一个三部分的架构。

Kafka Topic A => Transformer => Kafka Topic B

根据您的示例。您的生产者将 COBOL 相关数据推送到 Kafka 主题 A。您的 Transformer 从主题 A 读取，进行必要的转换，然后将 JSON 输出到主题 B。一旦进入主题 B，前端应用程序就可以以其首选格式读取它。如果你走这条路，Transformer 可以使用 Kafka 的默认消费者和生产者定制构建，或者使用流式框架，如 Apache Samza 或 Apache Storm 来帮助处理消息传递。 Samza 和 Kafka 最初都是在 LinkedIn 开发的，我相信它们可以很自然地协同工作。 （虽然我从未尝试过 Samza）。