6 种事件驱动的架构模式(1)

从服务的各种 API 可以明显看出，它处理了客户端服务的太多不同的关注点。

MetaSite 服务处理大约 1M RPM 的各类请求

我们想要回答的问题是，如何以最终一致的方式将读请求从该服务转移出来？

使用 Kafka 创建“物化视图”

负责这项服务的团队决定另外创建一个服务，只处理 MetaSite 的一个关注点——来自客户端服务的“已安装应用上下文”请求。

• 首先，他们将所有数据库的站点元数据对象以流的方式传输到 Kafka 主题中，包括新站点创建和站点更新。一致性可以通过在 Kafka Consumer 中进行 DB 插入来实现，或者通过使用CDC产品（如Debezium）来实现。

• 其次，他们创建了一个有自己数据库的“只写”服务（反向查找写入器），该服务使用站点元数据对象，但只获取已安装应用上下文并写入数据库。即将站点元数据的某个“视图”（已安装的应用程序）投影到数据库中。

已安装应用上下文消费与投影

• 第三，他们创建了一个“只读”服务，只接受与已安装应用上下文相关的请求，通过查询存储着“已安装应用程序”视图的数据库来满足请求。

读写分离

效果

• 通过将数据以流的方式传输到 Kafka，MetaSite 服务完全同数据消费者解耦，这大大降低了服务和 DB 的负载。

• 通过消费来自 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