Kafka 流架构
Kafka Streams Architecture
我希望从架构的角度澄清一些关于 Kafka Streams 的想法。
我了解流处理和数据丰富的用途，如果将数据推回 Kafka，其他应用程序可以重复使用这些数据，但 Streams 应用程序的正确实现是什么？
我最初的想法是创建一个应用程序，将 table 拉入，将其加入流，然后为每个条目触发一个事件，而不是将其推回 Kafka。如果多个服务使用此数据，那么每个服务都会实现自己的 table，对吧？
而且我还没有实现测试应用程序，它可能会回答其中一些问题，但我认为这是规划的好地方。基本上，应该在哪里触发事件，是在流媒体应用程序中还是在单独的消费者应用程序中？
My initial thoughts would be to create an application that pulls in a table, joins it to a stream, and then fires off an event for each entry rather than pushing it back into Kafka.
在 event-driven 架构中，如果您认为 Kafka 主题不应该是与其他应用程序共享事件的目的地，应用程序会将事件发送到哪里（以及如何发送）？您还有其他偏好吗？
If multiple services use this data, then each would materialize their own table, right?
是的，这是一种选择。
另一种选择是使用 KStreams 中的 interactive queries 功能（又名可查询状态），它允许您的第一个应用程序直接向其他应用程序公开其表和状态存储（例如，通过 REST API).其他应用程序将不需要具体化他们自己的表。但是，架构的缺点是您现在可以通过 request-response 通信在您的第一个应用程序和任何其他下游应用程序之间直接耦合。虽然这种直接 inter-service 通信模式在微服务架构中很流行，但一个引人注目的替代方案是不使用直接通信，而是让 microservices/apps 通过 Kafka 相互间接通信（即使用前面的选项).
Basically, where should the event be triggered, in the streaming app or in a separate consumer app?
这是一个偏好问题，见上文。为了传达您的想法，您可能需要阅读关于 event-driven 架构与 Kafka 的 4 部分迷你系列：https://www.confluent.io/blog/journey-to-event-driven-part-1-why-event-first-thinking-changes-everything（免责声明：该博客系列由我的同事撰写）。
我希望从架构的角度澄清一些关于 Kafka Streams 的想法。
我了解流处理和数据丰富的用途，如果将数据推回 Kafka，其他应用程序可以重复使用这些数据，但 Streams 应用程序的正确实现是什么？
我最初的想法是创建一个应用程序，将 table 拉入，将其加入流，然后为每个条目触发一个事件，而不是将其推回 Kafka。如果多个服务使用此数据，那么每个服务都会实现自己的 table，对吧？
而且我还没有实现测试应用程序，它可能会回答其中一些问题，但我认为这是规划的好地方。基本上，应该在哪里触发事件，是在流媒体应用程序中还是在单独的消费者应用程序中？
My initial thoughts would be to create an application that pulls in a table, joins it to a stream, and then fires off an event for each entry rather than pushing it back into Kafka.
在 event-driven 架构中，如果您认为 Kafka 主题不应该是与其他应用程序共享事件的目的地，应用程序会将事件发送到哪里（以及如何发送）？您还有其他偏好吗？
If multiple services use this data, then each would materialize their own table, right?
是的，这是一种选择。
另一种选择是使用 KStreams 中的 interactive queries 功能（又名可查询状态），它允许您的第一个应用程序直接向其他应用程序公开其表和状态存储（例如，通过 REST API).其他应用程序将不需要具体化他们自己的表。但是，架构的缺点是您现在可以通过 request-response 通信在您的第一个应用程序和任何其他下游应用程序之间直接耦合。虽然这种直接 inter-service 通信模式在微服务架构中很流行，但一个引人注目的替代方案是不使用直接通信，而是让 microservices/apps 通过 Kafka 相互间接通信（即使用前面的选项).
Basically, where should the event be triggered, in the streaming app or in a separate consumer app?
这是一个偏好问题，见上文。为了传达您的想法，您可能需要阅读关于 event-driven 架构与 Kafka 的 4 部分迷你系列：https://www.confluent.io/blog/journey-to-event-driven-part-1-why-event-first-thinking-changes-everything（免责声明：该博客系列由我的同事撰写）。