跳转至

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

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

1. 架构

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

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

默认配置下，工作队列及工作单元的分配如下：

工作队列 独立部署版 Func 中
对应工作单元		 观测云附属 Func 中
对应工作单元		 函数任务
#0 worker-0 worker-0 系统任务
#1 worker-1 worker-1 用户函数任务（一般用途）
#2 worker-2 worker-2 用户函数任务（自动触发）
#3 worker-3 worker-3 用户函数任务（批处理）
#4 worker-0 worker-4 预留
#5 worker-5 worker-5 Web 界面中运行脚本的调试任务
#6 worker-6 worker-6 消息订阅
#7 worker-0 worker-7 预留 / 观测云专用（一般用途）
#8 worker-0 worker-8 预留 / 观测云专用（自动触发配置）
#9 worker-0 worker-9 预留 / 观测云专用（自动触发配置-复杂任务）
工作队列 对应工作单元 函数任务
#0 worker-0 系统任务
#1 worker-1-6 调用授权链接
#2、#3、#4、#5 worker-1-6 预留
#6 worker-1-6 订阅消息执行
#7 worker-7 Web 界面直接运行
#8 worker-8-9 自动触发执行
#9 worker-8-9 预留

因此，在着手扩容之前，应当了解自己实际业务情况，以便针对性地进行扩容。

2. 服务

运行 DataFlux Func 需要同时运行多个服务，每个服务都有其不同的职责。

以单机版 DataFlux Func 默认参数部署的情况为例，DataFlux Func 所包含的服务如下：

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

3. 扩容

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

一般来说，对 DataFlux Func 的扩容实际只需要增加对应服务（如：worker-8）的副本数即可。

3.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

3.2 Helm 版

敬请期待

4. 限制资源

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

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

4.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

4.2 Helm 版

敬请期待

5. 拆分工作单元

在 3.2.0 及以后版本中，默认已经拆分了所有 Worker，理论上不再需要手工拆分

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

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

5.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

5.2 Helm 版

敬请期待