前言
在过去的一年里，我一直是负责Wix的事件驱动消息基础设施（基于Kafka之上）的数据流团队的一员。该基础设施被 1400 多个微服务使用。 在此期间，我已经实现或目睹了事件驱动消息传递设计的几个关键模式的实现，这些模式有助于创建一个健壮的分布式系统，可以轻松处理不断增长的流量和存储需求。
一、消费与投射 -
那些非常受欢迎的服务会成为瓶颈 当您遇到存储大型领域对象的“流行”数据的瓶颈时，此模式可以提供帮助。 在 Wix，我们的MetaSite服务就是这种情况，它为 Wix 用户创建的每个站点保存了大量元数据，例如站点版本、站点所有者以及站点上安装了哪些应用程序-已安装的应用程序上下文。 此信息对于 Wix 的许多其他微服务（团队）很有价值，例如Wix Stores、Wix Bookings、Wix Restaurants等等。这个单一的服务被超过 100 万 RPM 的请求轰炸，以获取网站元数据的各个部分。 通过查看服务的各种 API 可以明显看出，它正在处理其客户端服务的太多不同的问题。
MetaSite 服务处理约 1M RPM 的各种请求 我们想要回答的问题是，我们如何以最终一致的方式从该服务转移读取请求？ 使用 Kafka 创建“物化视图”负责这项服务的团队决定创建一项附加服务，该服务仅处理 MetaSite 的一个问题——来自其客户端服务的“已安装应用程序上下文”请求。
-
首先，他们将所有数据库的站点元数据对象流式传输到 Kafka 主题，包括新站点创建和站点更新。一致性可以通过在 Kafka Consumer 中进行数据库插入来实现，或者通过使用像Debezium这样的[url=https://en.wikipedia.org/wiki/Change_data_capture]CDC[/url]产品来实现。
-
其次，他们使用自己的数据库创建了一个“只写”服务（反向查找写入器），该服务使用站点元数据对象，但仅获取已安装应用程序上下文并将其写入数据库。即，它将站点元数据的某个“视图”（已安装的应用程序）投射到数据库中。
使用和项目安装的应用程序上下文
-
第三，他们创建了一个“只读”服务，只接受与已安装应用程序上下文相关的请求，他们可以通过查询存储计划的“已安装应用程序”视图的数据库来完成这些请求。
拆分读写 结果：
-
通过将数据流式传输到 Kafka，MetaSite 服务与数据的消费者完全分离，从而显着降低了服务和数据库的负载。
-
通过使用来自 Kafka 的数据并为特定上下文创建“物化视图”，反向查找编写器服务能够创建最终一致的数据投影，该投影针对其客户服务的查询需求进行了高度优化。
-
将读取服务与写入服务分开，可以轻松扩展只读数据库复制和服务实例的数量，以处理来自全球多个数据中心的不断增长的查询负载。
2.端到端的事件驱动
-便于业务流程状态更新 请求-回复模型在浏览器-服务器交互中特别常见。
通过将 Kafka 与websocket一起使用，我们可以驱动整个流事件，包括浏览器-服务器交互。 这使得交互更具容错性，因为消息保存在 Kafka 中，并且可以在服务重新启动时重新处理。这种架构也更具可扩展性和解耦性，因为状态管理完全从服务中移除，并且不需要数据聚合和查询维护。 考虑以下用例 - 将所有 Wix 用户的联系人导入 Wix 平台。 此过程涉及多项服务——Contacts Jobs 服务处理导入请求并创建导入批处理作业，Contacts Importer执行联系人的实际格式化和存储（有时在 3rd 方服务的帮助下）。 注册，然后会告诉你结果传统的请求-回复方式需要浏览器不断轮询导入状态，前端服务保持部分数据库表的状态更新，同时轮询用于状态更新的下游服务。 相反，通过使用 Kafka 和webs
524
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
