Skip to content

EventBridge Runtime

Jump to bottom
shenlin edited this page Jan 27, 2023 · 19 revisions

Status

  • Current State: Proposed
  • Authors: shenlin
  • Mailing List discussion: [email protected]
  • Pull Request: #PR_NUMBER
  • Released: <released_version>

Background & Motivation

What do we need to do

  • Will we add a new module? -- Yes.
  • Will we add new APIs? -- Yes.
  • Will we add new features? -- Yes.

Why should we do that

  • Are there any problems with our current project? There are several problems in current RocketMQ EventBridge:

    1. Too much dependence：When using EventBridge, additional deployment of rocketmq and rocketmq-connect is required;
    2. Without its own Runtime, EventBridge cannot provide better services for EDA scenarios, including:
    • Tracing：Comparing with the traditional synchronous call, in the EDA scenario, it is an essential function to support full link tracking query. In addition, Tracing needs to be well integrated with the open source ecosystem (like Zipkin, Skywalking, OpenTelemetry, etc.), which cannot be supported by the existing RocketMQ Connect.
    • Exception handling, retry, dead letter queue：Configure flexible exception handling, retry, dead letter queue.
    • Monitoring & Alarm：Whether there are rich metrics, whether to support monitoring and alarm.
    • Back pressure and flow control: Better protect the downstream.
    • User-friendly：A richer SDK and better integration with the Spring boot ecosystem allow users to use it at a lower cost;

  • What can we benefit from the proposed changes?

    1. Reduce dependence on external services.
    2. Provide better EDA integration experience.

Goals

  • What problem is this proposal designed to solve?

    1. Design the running link of Runtime.
    2. Design the SPI of Runtime.
    3. Design the control of Runtime.

Non-Goals

  • What problem is this proposal NOT designed to solve?

    1. Runtime life cycle management, including how to create/modify/delete.

  • Are there any limits to this proposal?

    Nothing specific.

Changes

Architecture

  • The event gateway will receive the events sent by the user to EventBridge, and deliver the events to the built-in storage, for example: RocketMQ.
  • When the user configures a Rule to subscribe to events on the event bus, Push Runtime will listen to the BUS associated with the Rule, and once an event is received on the Bus, it will push the event to the Target specified by the Rule.
  • If filtering and conversion are configured on the Rule, the event will be pre-processed before pushing.

image

How Push Runtime listens to EventBus

There are two ways here:

  • Solution 1-Independent mode: each Rule creates an MQ subscription separately to monitor whether there is an event on the BUS associated with the Rule; in this mode, each Rule subscription is an independent task.

image

  • Solution 2-Sharing mode: A unified component in the Push Worker monitors the BUS associated with all Rules assigned to the current Worker; if an event occurs on the monitored BUS, the event is distributed to the specified Rule for filtering and conversion. Finally, it is pushed to the Target side through the Sink Connector;

image

Since the EventRule is different from the Streaming scenario, most of the time, there may be no events on the BUS monitored by the Rule; in order to reduce the cost of monitoring MQ, the recommended solution 2: a unified component in the Push Runtime monitors all the Rules assigned to the current Worker and share the resource.

Push Runtime Manager

Problem Analysis:

  • If each running Push Runtime needs to load all the rules, when there are more and more rules, the Push Runtime cannot be expanded horizontally and will become a bottleneck.

Solution:

  • The Push Runtime Cluster only needs to load the Rule assigned to it, and listen to the specified BUS according to the definition of the Rule. Once an event occurs on the BUS, it will filter the event according to the filtering rules and push it to the target terminal Target.

Responsibilities of the Push Runtime Manager:

  • All Push Runtime life cycles are managed by Push Runtime Manger.
  • How Rule is assigned to Push Runtime is managed by Push Runtime Manger.

image

Interface Design/Change

  • Method signature changes -- Add some async function in the Store module.
  • Method behavior changes -- Nothing specific.
  • CLI command changes -- Nothing specific.
  • Log format or content changes -- Nothing specific.

问题分析：

  • EventBridge是一个开放的架构，事件网关接收到的事件不一定会存储到RocketMQ，所以PushWorker在设计的时候，需要支持监听不同的MQ，因此这里我们需要定义一套标准的SPI，基于SPI实现不同的MQ监听组件；
  • PushWorker在BUS上监听到事件之后，会对事件进行过滤和转换，最终将事件推送到Rule中指定的目标端。推送之前，还会对事件进行过滤和转换，这些过程都需要定义好SPI，以便后期进行扩展，同时方便生态合作伙伴进行共建。

解决方案： 目前，OpenMessaging Connect API 已经定义了完整的SPI，并拥有一定的生态。所以，我们考虑复用OpenMessaging Connect API作为我们标准的SPI。

image

Compatibility, Deprecation, and Migration Plan

This proposal needs to modify the API specification of MessageStore to add asynchronous interfaces. This only involves changes inside the server side, without relying on a specific client version or changing the way that client is used. It is completely transparent to applications connected to RocketMQ.

Implementation Outline

We split this proposal into several tasks:

  • Task1: Push Runtime Implementation.
  • Monitor the EventRule that needs to be processed by the current Runtime, and the Bus associated with the EventRule.
  • Monitor the MQ component through long pooling. When a new event is detected, it will immediately write the event to the local Buffer, and the monitoring component will continue to monitor subsequent events; (event push does not block the listening thread)
  • The Poll component obtains events from the Buffer, and according to the context information (Rule), filters and converts the events, and then sends them to the SinkConnector.
  • Put can be an asynchronous operation or a synchronous operation.
  • Before the Runtime submits the site each time, it will call PreCommit to obtain the offset successfully submitted by the current event, and then submit the site through the MQ monitoring component.

image

  • Task2: Push Runtime Manger 实现；

Push Runtime Manager如何给Push Runtime分配Rule

  • 通过现有的event_target_runner表格，将EventRule分配给指定的Push Runtime运行

image

  • 增加event_push_worker表管理所有的worker节点

image

Push Manager 根据每个Worker的负载（如CPU、Memeory、Push延迟时间、线程池剩余大小）等Metrics信息给Rule-Target分配Worker，前期可以根据每个Worker分配的Rule- Target数量均匀分配；

Push Worker如何获取分配给他的Rule-Target

  • Worker可以提前创建好，然后配置到event_push_worker表中。如果底层基础设置支持自动创建容器的能力，则可以通过PushManager调用基础设施服务，动态创建Worker，并自动注册到event_push_worker表。
  • 所有创建好的Worker都有一个系统变量：worker-name，来指定当前worker的信息。Worker在启动的时候，可以根据worker-name来获取分配给他的Rule-Target。
  • 另外，运行过程中Rule-Target信息会发生变化，这个时候，PushManger需要将最新的变化的Rule-Target信息，通知给对应的Worker，Worker收到通知后，重新加载最新的Rule-Target。
  • Task3: Push Runtime 与 Openmessaging Connect 生态集成；

Rejected Alternatives

None.

How do alternatives solve the issue you proposed?

None.

Clone this wiki locally