NocoBase 集群部署中的服务拆分用 WORKER_MODE 隔离请求节点与任务节点【免费下载链接】nocobaseNocoBase is an open-source AI no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase在 NocoBase 集群模式下所有服务默认运行在同一个 Node.js 实例中当工作流、异步导入导出等耗时服务与用户请求共享同一进程资源时容易造成性能相互干扰。本文讲解如何通过环境变量WORKER_MODE将应用服务拆分到不同节点运行——区分「请求节点」与「任务节点」、对指定服务做水平扩展、实现资源隔离并介绍插件开发者如何借助serving()接口为自己的服务接入这套拆分机制。为什么需要服务拆分通常情况下NocoBase 应用的所有服务都运行在同一个 Node.js 实例中。随着业务功能变复杂一部分耗时服务如复杂工作流的执行、大批量数据的导入导出会占用事件循环与 CPU 资源可能拖慢同一进程内的用户请求响应。NocoBase 在集群模式Cluster Mode下支持将不同服务拆分部署到不同节点上带来两类收益故障与性能隔离避免单个服务的性能问题影响整个应用导致无法正常响应用户请求针对性水平扩展可以只针对某类高负载服务例如工作流处理增加副本数提高集群资源利用率而不必整体扩容。在 Kubernetes 等编排环境中功能相同的节点使用相同的环境变量配置成一组 Deployment即可方便地针对某类服务单独扩缩容。哪些服务可以拆分NocoBase 目前内置支持拆分的后台服务有两类均通过「服务 KEY」标识1. 异步工作流服务 KEYworkflow:process异步模式的工作流在触发后会进入队列排队执行属于后台任务通常不需要用户等待结果返回。该标识定义在工作流服务端插件中参见 Plugin.tsexport const WORKER_JOB_WORKFLOW_PROCESS workflow:process;对于较为复杂且耗时的流程在触发量比较大的情况下建议将其拆分到独立节点上运行。此外工作流 JavaScript 任务恢复Task Recovery逻辑也会检查该标识若当前实例不处理workflow:process会主动跳过恢复并输出警告参见 TaskRecovery.ts。2. 其他用户级的异步任务服务 KEYasync-task:process包括异步导入、异步导出等由用户操作创建的任务其处理入口位于异步任务管理插件参见 base-task-manager.ts。在大数据量或并发较多的情况下建议将其拆分到独立节点上运行。WORKER_MODE 环境变量配置规则将不同服务拆分至不同节点通过配置环境变量WORKER_MODE实现。该变量的取值遵循以下规则WORKER_MODE 取值工作模式适用场景空未配置或为空与单实例相同接收所有请求也处理所有任务兼容此前未配置的应用!仅处理请求不处理任何任务纯请求节点Dispatcherworkflow:process,async-task:process仅处理列出的服务标识任务英文逗号分隔不处理请求专职任务节点*处理所有后台任务不分模块但不处理请求通用任务节点!,workflow:process处理请求同时只处理workflow:process任务混合节点-不处理任何请求和任务worker 进程内部的临时子进程transient 模式其中!表示「处理请求」多个标识以英文逗号分隔顺序无要求a,!与!,a等效。源码实现serving() 如何解析这些取值WORKER_MODE的解析逻辑集中在 worker-mode.ts其核心函数serving()的判定流程为export function serving(key?: string): boolean { const { WORKER_MODE } process.env; if (!WORKER_MODE) { return true; // 空单实例模式什么都做 } if (WORKER_MODE -) { return false; // transient 模式什么都不做 } const topics WORKER_MODE.trim().split(,); if (key) { if (WORKER_MODE *) return true; // 通配处理所有任务 return topics.includes(key); // 精确匹配服务标识 } else { return topics.includes(!); // 是否处理请求 } }同文件中还有isTransient()当且仅当WORKER_MODE -时返回true用于标识短生命周期的 worker 子进程。这两个函数均标注experimental即目前仍处于实验性 API 状态。Application类将该能力以实例方法形式暴露给插件代码见 application.tspublic serving(key?: string): boolean { return serving(key); }行为验证单元测试覆盖的六种模式serving() 的行为由完整的单元测试覆盖与文档规则一一对应可作为配置行为的可验证依据配置serving()请求serving(a)任务 aserving(b)任务 b空默认truetruetrue!truefalsefalsea,bfalsetruetrue*falsetruetrue!,a或a,!truetruefalse-falsefalsefalse测试还验证了顺序无关性!,a与a,!的判定结果完全一致见测试用例 dispatcher and specific services (with order)。配置示例示例一多节点分别处理假设有三个节点node1、node2、node3可按下表配置节点职责WORKER_MODEnode1仅处理用户 UI 请求!node2仅处理工作流任务workflow:processnode3仅处理异步任务async-task:process示例二多节点混合处理假设有四个节点可按「请求组 任务组」划分node1、node2处理所有常规请求配置WORKER_MODE!由负载均衡自动将请求分发到这两个节点node3、node4处理所有其他后台任务配置WORKER_MODE*。这种分组方式下请求组与任务组可以独立扩缩容请求高峰期增加请求节点副本任务积压时增加任务节点副本。开发参考为自己的插件服务接入拆分开发业务插件时可根据需求场景针对资源消耗较大的服务进行拆分实现方式分两步定义一个新的服务标识例如my-plugin:process用于环境变量配置并在插件文档中说明在插件服务端的业务功能中使用serving()接口判断当前节点是否提供该业务import { serving } from nocobase/server; const MY_PLUGIN_SERVICE_KEY my-plugin:process; // 在插件的服务端代码中 if (serving(MY_PLUGIN_SERVICE_KEY)) { // 处理该服务的业务逻辑 } else { // 不处理该服务的业务逻辑 }接入后即可在集群中通过WORKER_MODEmy-plugin:process将该插件的重负载逻辑调度到专职节点上。需要注意的是serving()与isTransient()目前标记为experimental见 worker-mode.ts 的 JSDoc 注释API 后续可能调整生产接入前建议关注版本更新。小结WORKER_MODE是 NocoBase 集群模式下区分请求节点与任务节点的唯一开关空值保持单实例全量行为!表示只接请求具体服务标识如workflow:process、async-task:process或*表示专职处理后台任务-用于 worker 内部子进程内置可拆分服务为异步工作流workflow:process与用户级异步任务async-task:process插件开发者通过serving(key)判断节点职责即可让自己的高消耗服务纳入同一套拆分与水平扩展体系。更多集群部署的准备工作、Kubernetes 编排与运维细节可参考同目录下的 集群部署概览、部署准备、Kubernetes 部署 与 运维 文档。【免费下载链接】nocobaseNocoBase is an open-source AI no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考