卡夫卡流架构

Question

我希望从架构的角度澄清一些关于 Kafka Streams 的想法。

我了解流处理和数据丰富的用途，如果将数据推回 Kafka，其他应用程序可以重复使用这些数据，但 Streams 应用程序的正确实现是什么？

我最初的想法是创建一个应用程序，它可以拉入一个表，将其连接到一个流中，然后为每个条目触发一个事件，而不是将其推回 Kafka。如果多个服务使用这些数据，那么每个服务都会实现自己的表，对吗？

我还没有实现一个测试应用程序，它可能会回答其中的一些问题，但我认为这是一个规划的好地方。基本上，应该在哪里触发事件，在流式应用程序中还是在单独的消费者应用程序中？

Answer 1

我最初的想法是创建一个应用程序，它可以拉入一个表，将其连接到一个流中，然后为每个条目触发一个事件，而不是将其推回 Kafka。

在事件驱动的架构中，如果您认为 Kafka 主题不应该是与其他应用程序共享事件的目的地，那么应用程序会将事件发送到哪里（以及如何发送）？您还有其他偏好吗？

如果多个服务使用这些数据，那么每个服务都会实现自己的表，对吗？

是的，这是一种选择。

另一种选择是使用 KStreams 中的 interactive queries 功能（也称为可查询状态），它允许您的第一个应用程序直接向其他应用程序公开其表和状态存储（例如，通过 REST API）。其他应用程序将不需要具体化自己的表。但是，架构的缺点是您现在可以通过请求-响应通信在您的第一个应用程序和任何其他下游应用程序之间直接耦合。虽然这种直接的服务间通信模式在微服务架构中很流行，但一个引人注目的替代方案是不使用直接通信，而是让微服务/应用程序通过 Kafka 间接地相互通信（即使用前一个选项）。

基本上，应该在哪里触发事件，在流式应用程序中还是在单独的消费者应用程序中？

这是一个偏好问题，见上文。为了了解您的想法，您可能需要阅读关于 Kafka 的事件驱动架构的 4 部分迷你系列：https://www.confluent.io/blog/journey-to-event-driven-part-1-why-event-first-thinking-changes-everything（免责声明：此博客系列由我的一位同事撰写）。