[RIP-67] RocketMQ EventBridge Runtime Management

[2011shenlin]

When subscription rule increase, a single runtime worker cannot support it, we need to add more worker to provide services at the same time.Here are several key issues:

• How many workers are needed in the current system？
• How to manage the life cycle of these workers？
• How to assign tasks to workers in order to maximize performance?
• How to achieve elastic scaling?
• ... ...

[Jashinck]

show the Chinese version detail please

[2011shenlin]

问题背景

当订阅规则增加时，单个运行时worker无法支持，需要添加更多worker同时提供服务。这里有几个关键问题：

• 现有系统需要多少Worker？
• 如何管理这些worker的生命周期？
• 如何给Worker分配任务才能最大化性能？
• 如何实现弹性伸缩？
• 如何实现不同任务之间的隔离？
• ……

  整体架构设计

  

引入 Runner Task

当在规则中创建一个Target订阅时，EventBridge会为每个任务创建一个Target Runner，用来描述当前这个Target订阅的运行态信息，详细信息可以参考表 event_target_runner:

但是目前的方式存在几个问题：

• 所有的Target Runner 默认都运行在一个Worker节点上；
• 无法实现不同Worker，运行不同的Target Runner；
• 无法支持同一个Target Runner，在多个Worker上同时运行；

为了解决这个问题，我们在DB中，以声明的方式，引入表：event_runner_task 其中cluster_id、worker_id 指名了当前runner_name运行的集群信息和Worker信息：

虚拟Cluster 管理

Cluster 是一个虚拟的概念，用来标注同一类Worker，这类Worker拥有相同的资源配置，镜像版本等。引入Cluster的目的主要包括：

• 资源隔离：不同的Cluster管理不同规模的Worker，同一个Target Runner只能分配到一个Cluster中的一个或多个Worker上；
• 方便Worker管理：Worker的生命周期管理，以Cluster为粒度，我们可以Cluster方便的升级该Cluster下所有的Worker；也可以通过Cluster来控制Worker的数量；

为此，我们需要在DB中，同样以声明的方式，引入一张表 event_cluster：

Worker管理

Worker和Runtime的区别是：Runtime代表软件的运行时，而Worker是Runtime运行时的资源节点。这个关系类似进程和系统之间的关系。理论上，一个Worker可以包含多个Runtime，但是为了简化模型，常常一个Worker只包含一个Runtime进程。 为了方便worker的管理，我们在DB中引入一张表event_worker：

如何创建Worker

方式1: 直接注册物理Node到event_worker表中

• 当有新的Node加进来时，只需要注册到event_worker表，配置IP地址；

• 前提条件：新增的Node和现有集群在同一个网络中；

  方式2: 通过K8S创建资源节点

• 创建Depolyment, 默认replica为1：

  Worker如何获取被分配的Runner Task

  Runtime支持文件、API的方式加载Task配置，对应的我们有几种方式让Worker获取被分配的Runner Task：

• 方式1：Manager主动将Task 配置分发给Worker

  • 比如通过K8S configMap，将Task配置以文件的形式挂载到Pod某个文件目录

• 方式2: 通过Manager与Worker的通信

  如何升级Worker的镜像版本

  方式1: 如果是Node直接注册的Worker，则由客户自己管理和维护Worker的镜像 方式2: 如果是通过K8S创建的Worker，则由系统负责worker的镜像升级

• event_images

发布流程：

• 镜像发布时，在connect_images添加新发布的镜像版本，通过upper_limit限制本次发布更新的cluster数量；
• conductor定时JOB，每隔1分钟，扫描connect_cluster表，判断当前cluster是否需要更新：
• 首先，判断当前cluster指定了expect_image_id，如果指定了，则优先更新到此镜像版本。
• 否则，镜像更新到最新版本，但是必须同时满足：
  • 当前cluster对应的imageId不是最新的；
  • 当前cluster的升级优先级高于其他cluster；
  • upper_limit为达到上限；

如果都满足，则更新当前cluster下的worker到最新镜像。

[leehom]

问题背景 当订阅规则增加时，单个运行时worker无法支持，需要添加更多worker同时提供服务。 下面重点回答弹性资源问题：

• 现有系统需要多少Worker？
• 如何实现弹性伸缩？
• 如何实现不同任务之间的隔离？
• 如何新增加Worker
• 如何实现高可用

  技术架构

  总体架构是master-worker，master包括资源消费者(包括调度器)，资源管理器；worker是任务管理器，管有资源，上报资源。 数据架构，资源是组件的核心数据，分两条线a线 现有资源，b线 待定资源 a) 4资源请求->5a 分配可用资源-> 6a 请求使用资源-> 7a 提供资源->8a 提交任务 b) 4资源请求->5b 分配待定资源-> 6b 请求新worker-> 7b 启动任务管理器->8b 注册/报告资源 a线是分配现有资源；b线请求新资源，新资源注册后成为现有资源，在a线分配

现有系统需要多少Worker？

作业管理器询问所有connector task数量，总和就是资源槽数据量，Worker数量=资源槽数据量/每个Worker资源槽数

如何实现弹性伸缩/如何新增加Worker

两个问题其实是一个问题，弹性资源通过增减Worker实现；参考flink的声明式资源管理，资源使用分为，资源申请，检查资源请求/检查资源声明，资源提供

• 资源申请
  资源消费者向资源管理器提出申请资源，首先申请可用资源，如果未完全满足，申请新资源
• 检查资源请求/检查资源声明
  检查资源请求/检查资源声明是交汇点，检查资源请求，该分配的分配，该请求新的请求新的资源；检查资源声明 哪些资源可以释放，需要新资源请求新worker。
• 资源提供
  资源管理器向k8s集群管理器申请新建Worker，Worker启动后，注册/报告自身的资源槽；
• 资源消费 资源管理器申请了可用资源，向资源所在任务管理器提出使用资源请求，任务管理器向资源消费者确认提供资源，资源消费者可提交任务

如何实现不同任务之间的隔离？

使用docker的容器

高可用&健壮性设计

1. master的高可用是k8s的复制机制提供，选主机制k8s提供，资源消费者和资源管理器参与选主，资源消费者/任务管理器接入资源管理器主节点监听，获取最新资源管理器地址；任务管理器接入资源消费者主节点监听，获取最新的资源消费者主节点 2 资源消费者/资源管理器/任务管理器直接都有心跳检测，超时重连，保证连接有效性