Kafka Streams体系结构

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（免责声明：该博客系列由我的一位同事撰写）。