[System Design] 事件中心服务 (EventHub)

Posted by Akilis on 26 Jun, 2021

需求与应用

需求

• 前端/移动端上报性能监控事件。

• 后端服务在非Web上下文中 ，例如Shell进程，上报事件。

• 收敛、整合消息推送渠道，作为基础服务能力。

应用

• 作为订阅发布内核，扮演数据摄入与中转的角色。

• 作为微服务中间件, 异步解耦合。例如重构看板订阅发布服务，以事件驱动替换数据库轮询调度，提升系统稳定性、容错能力。

解决方案

现有设施

架构暴露，由消息中间件直接串联BI及BI外部的依赖服务完成数据的摄入与中转。并未实现真正的事件服务化，通过组件及外部服务的堆积，完成后端埋点数据的收集与ETL。

• 打点系统。后端服务通过客户端模块Tracer，异步发送埋点事件。客户端目前只有Kafka一种实现，直连公司的Kafka/BMQ.

• ETL任务。借助BI数据集制作能力，创建“Kafka -> CH (ClickHouse)”类型的数据集；或者在Dorado平台，创建"BMQ -> CH"类型的任务，然后再在BI创建"CH -> CH"类型的数据集。最终在BI里，使用可视化分析CH数据集。两者底层实际上都是依赖于其它组件例如Dorado做数据消费与落库。

设计目标

• 规划出独立的事件处理平台，能够支持跨端的、跨网的数据摄入、处理、流转。例如新增RESTful接口发布、订阅事件。

• 覆盖对高吞吐、低延时、强一致性有不同侧重点的场景。具体来讲，支持通过透明横向扩展来匹配数据生产速率、支持Push/Pull消费模式的客户端、对于订阅事件失败时的错误处理与补偿。

• 内聚事件总线到服务内部，取消外部平台与依赖，自治的数据流管道。例如支持ETL任务类型的订阅。

系统框架

外部交互

• EventHub - 事件中心
  事件的集散地，以及处理、加工和应用。

• Publisher - 多端发布

  • Browser通过RESTful API发布事件。

  • 后端服务通过客户端Tracer发布事件，Tracer有事件总线原生协议的实现 (raw client)，以及HTTP协议的实现 (HTTP client)。对于网络可达、高吞吐的场景，可以使用raw client，对于低时延、或者网络只能使用HTTP协议的场景，可以使用HTTP client。

• Subscriber - 订阅消费

  • ETL - 事件抽取流转管道
    订阅行为事件，创建ETL推送类型，实现数据落库。

  • Notification - 告警通知
    订阅告警事件，以各种方式推送通知。

  • Webhook - 开发侧回调
    订阅关注事件，当事件匹配时，发起RESTFul请求，通知下游。

  • Apps - 应用开发
    基于订阅，实现其它业务，例如统计、审计。

服务架构

• EventApp
  提供RESTFul API

  • PubSub

    • Publish event

    • Subscribe content

  • Event Register & Token Manager
    事件登记与Token管理

    • 集中注册事件，防止冲突。

    • 管理事件的发布与订阅授权。事件外围开发者，登记开发者信息并获取token，在发布与订阅时提供Token，EventHub进行鉴权。

• EventBus
  订阅发布内核

  • Match Engine
    订阅规则匹配事件的路由引擎。

    • Publisher发送的事件中，包含事件key。Subscriber订阅事件时，通过指定key以及BLOB匹配表达式，进行匹配。

    • 事件key可以被多个订阅者关注。内存维护这样的路由信息，并使用Database持久化，服务重启时从持久化装置恢复。

  • Message Broker
    事件的队列管道。重点关注事件发布（即生产）的阻塞问题，以及事件订阅（即消费）的摄入模式。

    • 生产API

      • Blocking (阻塞型). SLA更关注一致性、易用性。

      • Non-blocking (非阻塞型). SLA更关注吞吐能力、失败率。

    • 消费API

      • Push (推模式). 更适合EventHub调用对外服务，例如Webhook, 直接推送内容. 重点关注重试、超时、错误处理、熔断的支持。

      • Pull (拉模式). 更适合外部服务主动拉取，例如使用raw client直连EventBus，根据自身的消息处理能力，按需消费事件流。

  • Pusher
    推送动力模块，涵盖各种中转、即席处理、通知能力。

    • 应用

      • Lark即时消息

      • Email

      • Applet. 诸如Teams/WebEx这样的小程序.

      • Webhook

      • ETL. 管道任务.

    • 容错处理

      • 事件推送失败后，存储相关信息到Database，可实现消息补偿机制。

  • Tracer
    事件发布(即消息生产) 客户端

    • Facade设计模式，各种服务或者语言的接入者能够获取一致的开发体验。
    • 内部实现RESTFul API，以及原生事件总线协议，接入者根据不同场景，按需接入。

选型

• Message Broker
  主要从伸缩/有序/一致性考虑各自优势。综合来看，Kafka扩展更容易，做二次开发更友好，场内事件上报使用Kafka已有铺垫打磨。采用Kafka (场内选择BMQ)作为Borker.
  • 伸缩
    • Redis
      • 发布新增channel，客户端纵向新增订阅channel，吞吐较差，客户端侧无法横向做扩展。优先考虑publish，底层用old/new hash table围绕channel，保存client订阅关系。subscriber规模不能过大，否则unsubscribe代价大。谨慎支持pattern subscription。
      • pubsub的吞吐benchmark, 单节点大于cluster.
      • pipelining publish提高吞吐。
    • Kafka
      • 使用一个topic，作为事件总线, 增加/减少partition，来实现伸缩能力。
    • 总结
      • 事件key放置于事件模型的payload，防止更改订阅规则时，需要起停client。
  • 有序
    • Redis
      • pubsub模式，只要处于正常订阅状态，则保证有序，因为publish是阻塞的。pipelining除外。
      • 也可借助list数据结构实现。
    • Kafka
      • 发送消息带key，则保证partition内有序。
    • 总结
      • event携带业务时间戳，协助实现顺序性问题。
      • update无序性后果很严重。
  • 一致
    • Redis
      • 无持久化。发送成功即ACK，在callback (processed)之前。
    • Kafka
      • OFFSET采用手动提交模式，处理之后提交ACK。
    • 总结
      • 异步则很难保证强一致性，除非借助于checkpointing机制。

部署与安装

1. EventHub总体框架基于RESTful web。

2. 使用Gunicorn作为web server，考虑数据集中进入与流转，属于I/O-bound类型的业务场景，sync worker类型，提高吞吐能力。

3. 对外通过域名方式访问，采用基于均匀随机的负载均衡策略。

4. 使用外置Cache加速某些查询相关的重接口。

5. 借助MySQL完成业务数据持久化。

6. Tracer客户端以代码方式与事件发布方集成在一起，主服务可以安装在任何地方, 需要注意的是底层EventBus在场内实现时，虽然支持跨机房部署生产消息，但消费只能在某机房进行。

引用

• [1]事件协议 Event FeedModel.

   DSPS    WEB    SCCS   

 Share on: Email

---