-
通过消费来自 Kafka 的数据,并为特定的上下文创建一个“物化视图”,反向查找写入器服务能够创建一个最终一致的数据投影,大幅优化了客户端服务的查询需求。
-
将读服务与写服务分开,可以方便地扩展只读 DB 副本和服务实例的数量,这些实例可以处理来自全球多个数据中心的不断增长的查询负载。
2.端到端事件驱动
针对简单业务流程的状态更新
请求-应答模型在浏览器-服务器交互中特别常见。借助 Kafka 和[WebSocket]((),我们就有了一个完整的事件流驱动,包括浏览器-服务器交互。
这使得交互过程容错性更好,因为消息在 Kafka 中被持久化,并且可以在服务重启时重新处理。该架构还具有更高的可伸缩性和解耦性,因为状态管理完全从服务中移除,并且不需要对查询进行数据聚合和维护。
考虑一下这种情况,将所有 Wix 用户的联系方式导入 Wix 平台。
这个过程涉及到两个服务:Contacts Jobs 服务处理导入请求并创建导入批处理作业,Contacts Importer 执行实际的格式化并存储联系人(有时借助第三方服务)。
传统的请求-应答方法需要浏览器不断轮询导入状态,前端服务需要将状态更新情况保存到数据库表中,并轮询下游服务以获得状态更新。
而使用 Kafka 和 WebSocket 管理者服务,我们可以实现一个完全分布式的事件驱动过程,其中每个服务都是完全独立工作的。
使用 Kafka 和 WebSocket 的 E2E 事件驱动
首先,浏览器会根据开始导入请求订阅 WebSocket 服务。
它需要提供一个 channel-Id,以便 WebSocket 服务能够将通知路由回正确的浏览器:
打开 WebSocket 通知“通道”
第二,浏览器需要向 Jobs 服务发送一个 HTTP 请求,联系人信息使用 CSV 格式,并附加 channel-Id,这样 Jobs 服务(和下游服务)就能够向 WebSocket 服务发送通知。注意,HTTP 响应将立即返回,没有任何内容。
第三,Jobs 服务在处理完请求后,会生成并向 Kafka