跳转至

部署和维护 / 架构、扩容与限制资源

本文主要介绍 DataFlux Func 的整体架构，以及如何进行扩容来提高处理能力。

1. 架构

在系统内部，是典型的「生产者 -> 消费者」模型。任何一次 Python 函数的执行，都会经过「生成任务 -> 入队 -> 出队 -> 执行 -> 返回结果」的流程。

任何 Python 函数，实际都会先包装成「任务」进入其所属的「工作队列」（序号0 ~ 9），之后由对应的「工作单元」（序号0 ~ 9）从队列取出后执行。

flowchart TB
    用户 --HTTP 请求--> Server
    Server --函数执行任务入队--> Redis队列
    Redis队列 --函数执行任务出队--> Worker

    Beat --"函数执行任务入队\n（定时）"--> Redis队列

1.1 服务

DataFlux Func 包含多个服务，每个服务都有其不同的职责，具体服务如下：

服务 用途
server Web 服务，提供如下功能：
1. Web 界面
2. API 接口
3. 维护订阅器
worker-{队列序号} 工作单元，用于执行用户脚本，包括：
1. 同步 API（旧版「授权链接」）
2. 异步 API（旧版「批处理」）
3. 定时任务（旧版「自动触发配置」）
同时也会处理一些系统级后台任务
具体见队列说明
beat 定时任务的触发器
mysql 数据库
redis 缓存 / 工作队列

1.2 队列

对于服务 worker-{队列序号}（工作单元），每个 Worker 服务都仅监听特定的若干个队列：

工作单元 队列
独立部署版		 队列
观测云附属
worker-0 #0, #4, #7, #8, #9 #0
worker-1 #1 #1
worker-2 #2 #2
worker-3 #3 #3
worker-4 - #4
worker-5 #5 #5
worker-6 #6 #6
worker-7 - #7
worker-8 - #8
worker-9 - #9
工作单元 队列
worker-0 #0
worker-1-6 #1, #2, #3, #4, #5, #6
worker-7 #7
worker-8-9 #8, #9

2. 扩容

扩容需要所在服务器提供更高的性能要求，请根据实际情况调整

一般来说，对 DataFlux Func 的扩容实际只需要增加对应服务的副本数即可，因此，用于应当首先了解自己实际业务情况，以便针对性地进行扩容。

完整的服务及其职责、扩容说明如下：

服务 / 队列 职责 扩容说明
server Web 服务，提供如下功能：
1. Web 界面
2. API 接口
3. 维护订阅器		 一般不需要扩容
队列 #0 系统工作单元，不直接参与用户代码的处理 一般不需要扩容
队列 #1 负责执行来自同步 API 的函数任务
旧版「授权链接」		 需要提高同步 API 并发量时可扩容
旧版「授权链接」
队列 #2 负责执行来自定时任务 的函数任务
旧版「自动触发配置」		 需要提高定时任务 并发量时可扩容
旧版「自动触发配置」
队列 #3 负责执行来自异步 API 的函数任务
旧版「批处理」		 需要提高异步 API 并发量时可扩容
旧版「批处理」
队列 #4 预留 不需要扩容
队列 #5 负责调试代码处理（即在 Web 界面直接运行函数） 需要支持更多用户同时开发脚本时扩容
队列 #6 负责执行来自连接器订阅消息处理的函数任务 需要提高连接器订阅消息处理并发量时可扩容
队列 #7 预留 / 负责观测云一般业务、消息发送的函数任务 仅在观测云附属 Func 中，当消息发送量大时扩容
队列 #8 预留 / 负责观测云普通监控器相关的函数任务 仅在观测云附属 Func 中，当普通监控器数量较多时扩容
队列 #9 预留 / 负责观测云高级检测、智能监控的函数任务 仅在观测云附属 Func 中，当普通高级检测、智能监控器数量较多时扩容
beat 定时任务的触发器 不得扩容，保证全局单副本
mysql 数据库 不需要扩容。有实际需要可选择云服务
redis 缓存 / 工作队列 不需要扩容。有实际需要可选择云服务
服务 职责 扩容说明
server Web 服务，提供如下功能：
1. Web 界面
2. API 接口
3. 维护订阅器		 一般不需要扩容
队列 #0 系统工作单元，不直接参与用户代码的处理 一般不需要扩容
队列 #1, #2, #3, #4, #5, #6 默认情况下，负责函数同步调用处理，如：
1. 授权链接处理
2. 订阅消息处理		 需要提高授权链接、订阅消息处理并发数时可扩容
队列 #7 默认情况下，负责调试代码处理（即在 Web 界面直接运行函数） 需要支持更多用户同时开发脚本时扩容
队列 #8, #9 默认情况下，负责函数异步调用处理，如：
1. 自动触发处理
2. 批处理		 需要提高自动触发、批处理处理并发数时扩容
beat 定时任务的触发器 不得扩容，保证全局单副本
mysql 数据库 不需要扩容。有实际需要可选择云服务
redis 缓存 / 工作队列 不需要扩容。有实际需要可选择云服务

示例：当需要增强定时任务的处理能力时...

由上文可知，定时任务位于「队列 #8」，「队列 #8」对应「服务 worker-8」，因此扩容「服务 worker-8」即可

2.1 单机版

单机版部署的 DataFlux Func 可以通过修改配置（{安装目录}/docker-stack.yaml），增加对应服务的deploy.replicas实现扩容。

有关 deploy.replicas 选项的完整信息，请参考 Docker 官方文档：Docker Documentation / Compose file deploy reference / replicas

以提升worker-8处理能力为例，具体修改部分如下：

示例仅展示关键修改部分，实际操作时请注意配置完整

YAML
1
2
3
4
5
services:
  worker-8:
    deploy:
      # 同时启动【2个】处理队列 8 的工作单元
      replicas: 2

2.2 Helm 版

敬请期待

3. 限制资源

限制资源过小，可能会导致任务执行变长，或内存不足无法完成代码的执行，请根据实际情况调整

一般来说，对 DataFlux Func 限制资源只需要为工作单元（如：worker-8）增加资源限制的配置即可。

3.1 单机版

单机版部署的 DataFlux Func 可以通过修改配置（{安装目录}/docker-stack.yaml），增加对应服务的deploy.resources实现限制资源。

有关 deploy.resources 选项的完整信息，请参考 Docker 官方文档：Docker Documentation / Compose file deploy reference / resources

一般来说，只需要对工作单元 1 ~ 9 队列进行限制即可。

默认情况下，每个worker-*副本最多会占满 5 个 CPU 核心（即每个工作单元中，有 5 个工作进程）。

以限制worker-8占用资源为例，具体修改部分如下：

示例仅展示关键修改部分，实际操作时请注意配置完整

YAML
1
2
3
4
5
6
7
services:
  worker-8:
    deploy:
      resources:
        limits:
          cpus  : '2.50' # 限制 CPU 最多使用 2.5 个核心
          memory: 4G     # 限制内存 最多使用 4 GB

3.2 Helm 版

敬请期待

4. 拆分工作单元

在 3.2.0 及以后版本中，默认已经拆分了所有 Worker，不再需要用户自行拆分

特殊情况下，可以将默认合并的工作单元（如：worker-1-6）进行拆分，实现更细粒度的任务调度，实现对负责特定队列的工作单元扩容与资源限制。

假设根据业务需求，DataFlux Func 对订阅处理的性能要求较高，且希望订阅消息处理不和授权链接处理不会相互干扰，那么可以从worker-1-6将拆分为worker-1-5和worker-6。

4.1 单机版

单机版部署的 DataFlux Func 可以通过修改配置（{安装目录}/docker-stack.yaml），新增、修改对应服务，并修改command中指定的队列序号，即可实现拆分工作单元。

指定工作单元监听的队列，通过 ./run-worker-by-queue.sh 后的参数实现，服务名称本身主要作为标注使用，与实际监听队列一致即可

示例仅展示关键修改部分，实际操作时请注意配置完整

YAML
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
services:
  # 删除原先的「worker-1-6」，改为如下内容

  worker-1-5:
    # 指定工作单元处理 1 ~ 5 号工作队列
    command: ./run-worker-by-queue.sh 1 2 3 4 5

  worker-6:
    # 指定工作单元处理 6 号工作队列
    command: ./run-worker-by-queue.sh 6

4.2 Helm 版

敬请期待