iii Workers 详解Worker 如何接入 Engine、管理生命周期并检查实时注册表【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档 Workers 展开系统讲解 Worker 作为 iii 系统能力扩展单元的核心机制如何通过 WebSocket 连接 EngineIII_URL与register_worker、Worker 的生命周期状态流转、断连时调用方应如何处理invocation_stopped与发现事件、如何用engine::*::list系列函数和发现触发器检查实时注册表、iii.worker.yaml清单的写法以及如何运行一次性ephemeralWorker。读完后你可以独立部署一个 Worker 接入任意 iii 实例并编写健壮的调用方代码来应对 Worker 拓扑变化。Worker 如何扩展 iii 系统Worker 为 iii 系统添加能力每一个 Worker 都会贡献出一组函数Functions和触发器TriggersEngine 会将调用路由到这些注册项上。简言之你往 iii 系统里添加的任何功能最终都以 Worker 的形式存在。本篇聚焦的是部署与接线deploying and wiring即把 Worker 接入项目的工程实践Worker 内部用 SDK 注册函数和触发器的编写细节authoring surface请参考各语言的 Worker 编写指南见 Rust SDK、Python SDK、Node SDK 等参考文档。通过 WebSocket 连接 EngineWorker 通过 WebSocket 与 Engine 建立连接。引擎地址通过环境变量III_URL设置也可以把 URL 显式传给register_worker。这条连接字符串是 Worker 与其加入的 iii 实例之间唯一的耦合点因此 Worker 进程可以部署在网络上任意可达的位置——本地进程、容器、Kubernetes Job、serverless 容器皆可。三种语言的接入方式Node / TypeScriptimport { registerWorker } from iii-sdk; const worker registerWorker(process.env.III_URL);Pythonimport os from iii import register_worker, InitOptions worker register_worker( os.environ.get(III_URL), InitOptions(worker_namemy-worker), )Rustuse iii_sdk::{InitOptions, register_worker}; let url std::env::var(III_URL).expect(III_URL must be set); let worker register_worker(url, InitOptions::default());从 Rust SDK 源码可以看到地址解析的具体约定III_URL优先未设置时回退到默认地址ws://127.0.0.1:49134默认地址常量。注意源码特意使用 IPv4 回环地址127.0.0.1而非localhost因为某些主机上localhost会解析为 IPv6 的::1而 Engine 可能只监听 IPv4。SDK 还提供了零参形式register_worker_from_env由iii compose、容器运行时或 systemd 这类父进程负责设置III_URL与设置III_NAMESPACE、III_WORKER_NAME的方式相同Worker 直接读环境即可见 register_worker_from_env 文档注释。register_worker本身还支持InitOptions中的元数据、请求头、OTel 配置与命名空间等参数见 lib.rs 中的函数实现。Worker 生命周期状态Worker 连接后会经历一小组状态流转connecting → connected → available / busy → disconnected各状态的含义状态含义connectingWebSocket 握手中connectedWorker 已加入 Engine 的注册表available/busy描述 Worker 当前是否正在处理调用disconnectedWebSocket 关闭后的终态Engine 会跟踪这些状态迁移并通过其发现函数discovery functions把状态暴露给其他 Worker 和工具链从而让整个系统能对拓扑变化做出反应。处理 Worker 断连当某个 Worker 的 WebSocket 关闭时Engine 会自动完成清理该 Worker 的 Functions 和 Triggers 会离开实时注册表对这些函数正在进行中的调用会被取消。调用方需要处理两件事捕获invocation_stopped错误。正在等待某函数结果、而该函数所属 Worker 中途断开的调用方收到的是invocation_stopped错误而非超时。应把它当作**取消cancellation**处理而不是瞬时失败——在 Worker 重连并重新注册该函数之前重试都会失败。这个错误码在 Engine 源码中有明确定义见 invocation 模块。订阅发现事件若需要对拓扑变化做出反应engine::workers-availableWorker 连接或断开时立即触发engine::functions-available最终一致——当函数列表的哈希发生变化后在下一个轮询周期触发Engine 内置引擎函数的实现说明其轮询周期为 5 秒见 engine_fn README。这两个触发器名称在 Engine 源码中以常量定义TRIGGER_FUNCTIONS_AVAILABLE / TRIGGER_WORKERS_AVAILABLE注册一个针对它们中任意一个的 Trigger即可在自己的 Worker 中感知拓扑变化。检查实时注册表要查看当前有哪些组件接入了 Engine按快照还是订阅两种需求使用两种调用面读取快照——调用engine::*::list系列函数engine::workers::list列出所有已连接的 Worker 及其指标metricsengine::functions::list列出所有已注册的函数可用include_internal过滤内部函数默认不包含engine::*前缀的引擎函数engine::triggers::list列出所有已注册的触发器同样支持include_internal过滤engine::trigger-types::list列出所有已声明的触发器类型及其配置 schema 与调用 schema。从源码可以看到engine::functions::list实际支持的过滤参数比文档更丰富见 FunctionsListInput 定义除include_internal外还支持search对function_id和描述做不区分大小写的子串匹配、prefix对function_id做精确前缀匹配、worker/workers按 Worker 名精确匹配workers可一次查询多个 Worker 的函数。订阅变更——把 Trigger 注册到以下事件上engine::workers-availableWorker 连接或断开时触发engine::functions-available函数被注册或注销后触发最终一致语义见上一节。这些是高层调用面如需了解线上协议wire-level的具体报文结构请参考 Engine SDK 参考文档 中的 Engine discovery functions 一节。Worker 清单iii.worker.yaml当 Worker 被检入项目、由 iii 在本地拉起时Worker 根目录下的iii.worker.yaml告诉 iii 如何安装依赖、如何运行 Worker以及如何透传配置name: math-worker runtime: kind: python package_manager: pip entry: math_worker.py scripts: install: pip install -r requirements.txt start: python math_worker.py字段含义name是 Worker 在 iii 中的名字runtime.kind声明运行时此处为 Pythonpackage_manager声明依赖管理器entry是入口文件scripts.install在安装阶段执行scripts.start用于启动 Worker 进程。完整字段 schema 见 Using iii / Workers 参考页。关键在于理解清单的定位iii.worker.yaml只是关于启动Worker 的元数据。Worker 跑起来之后真正起作用的是它与 Engine 的 WebSocket 连接和函数注册行为。由iii worker add拉起的 Worker 与在容器里手工启动的 Worker在 Engine 看来行为完全一致——Engine 只认连接不认进程是怎么来的。Worker 连接后贡献了什么一个 Worker 连接成功后会向系统暴露两类资源Functions系统中任何位置都可以按function_id调用参见 Using iii / FunctionsTriggersWorker 声明的触发器其他 Worker 可以把函数绑定到这些触发器上参见 Using iii / Triggers。Worker 内部注册这两类资源所用的 SDK 调用是语言相关的各语言的 Worker 编写指南中有详细说明。运行一次性ephemeralWorker对于一次性任务Kubernetes Job、serverless 容器、定时脚本SDK Worker 可以连接到一个远程Engine、注册所需函数、完成工作后直接退出进程Engine 会在断连时自动清理该 Worker 的全部注册项。做法是设置III_URL指向远程 Engine见上文连接 Engine一节注册该任务需要暴露的函数任务完成后让进程自然退出。这种模式无需为短任务维持长连接或常驻进程配合 Engine 的自动清理机制注册表不会残留幽灵函数。实操补充本地管理 Worker 的 CLI 命令文档中提到的iii worker add只是 Worker 管理的入口。配合 Using iii / Workers 参考页日常运维还可以使用iii worker add name # 安装 Worker 到项目并自动启动 iii worker reinstall name # 强制重新下载等价于 add --force iii worker list # 列出 config.yaml 中声明的所有 Worker 及状态 iii worker start name # 启动 iii worker stop name # 停止 iii worker restart name # 停止后重启 iii worker status name # 查看配置、沙箱状态、近期日志 iii worker logs name # 流式查看 Worker 日志 iii worker exec name -- command # 在 Worker 沙箱内执行命令这些命令面向的是由项目config.yaml托管的 Worker而 Engine 侧对 Worker 的感知仍然只通过 WebSocket 注册表——这正呼应了本文的核心结论对 Engine 而言无论 Worker 如何被启动唯一重要的是那条连接和注册上来的函数与触发器。小结Worker 是 iii 系统能力的扩展单元唯一的耦合点是III_URL指向的 WebSocket 地址生命周期按connecting → connected → available/busy → disconnected流转Engine 通过发现函数对外暴露状态断连时 Engine 自动注销函数与触发器并取消在途调用调用方应把invocation_stopped当取消处理并订阅engine::workers-available/engine::functions-available感知拓扑变化engine::workers::list/functions::list/triggers::list/trigger-types::list提供注册表快照iii.worker.yaml只负责本地启动元数据不改变 Engine 侧行为一次性任务可用 ephemeral Worker 模式连接、注册、干活、退出注册由 Engine 在断连时自动清理。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 iii Workers 详解：Worker 如何接入 Engine、管理生命周期并检查实时注册表
iii Workers 详解Worker 如何接入 Engine、管理生命周期并检查实时注册表【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档 Workers 展开系统讲解 Worker 作为 iii 系统能力扩展单元的核心机制如何通过 WebSocket 连接 EngineIII_URL与register_worker、Worker 的生命周期状态流转、断连时调用方应如何处理invocation_stopped与发现事件、如何用engine::*::list系列函数和发现触发器检查实时注册表、iii.worker.yaml清单的写法以及如何运行一次性ephemeralWorker。读完后你可以独立部署一个 Worker 接入任意 iii 实例并编写健壮的调用方代码来应对 Worker 拓扑变化。Worker 如何扩展 iii 系统Worker 为 iii 系统添加能力每一个 Worker 都会贡献出一组函数Functions和触发器TriggersEngine 会将调用路由到这些注册项上。简言之你往 iii 系统里添加的任何功能最终都以 Worker 的形式存在。本篇聚焦的是部署与接线deploying and wiring即把 Worker 接入项目的工程实践Worker 内部用 SDK 注册函数和触发器的编写细节authoring surface请参考各语言的 Worker 编写指南见 Rust SDK、Python SDK、Node SDK 等参考文档。通过 WebSocket 连接 EngineWorker 通过 WebSocket 与 Engine 建立连接。引擎地址通过环境变量III_URL设置也可以把 URL 显式传给register_worker。这条连接字符串是 Worker 与其加入的 iii 实例之间唯一的耦合点因此 Worker 进程可以部署在网络上任意可达的位置——本地进程、容器、Kubernetes Job、serverless 容器皆可。三种语言的接入方式Node / TypeScriptimport { registerWorker } from iii-sdk; const worker registerWorker(process.env.III_URL);Pythonimport os from iii import register_worker, InitOptions worker register_worker( os.environ.get(III_URL), InitOptions(worker_namemy-worker), )Rustuse iii_sdk::{InitOptions, register_worker}; let url std::env::var(III_URL).expect(III_URL must be set); let worker register_worker(url, InitOptions::default());从 Rust SDK 源码可以看到地址解析的具体约定III_URL优先未设置时回退到默认地址ws://127.0.0.1:49134默认地址常量。注意源码特意使用 IPv4 回环地址127.0.0.1而非localhost因为某些主机上localhost会解析为 IPv6 的::1而 Engine 可能只监听 IPv4。SDK 还提供了零参形式register_worker_from_env由iii compose、容器运行时或 systemd 这类父进程负责设置III_URL与设置III_NAMESPACE、III_WORKER_NAME的方式相同Worker 直接读环境即可见 register_worker_from_env 文档注释。register_worker本身还支持InitOptions中的元数据、请求头、OTel 配置与命名空间等参数见 lib.rs 中的函数实现。Worker 生命周期状态Worker 连接后会经历一小组状态流转connecting → connected → available / busy → disconnected各状态的含义状态含义connectingWebSocket 握手中connectedWorker 已加入 Engine 的注册表available/busy描述 Worker 当前是否正在处理调用disconnectedWebSocket 关闭后的终态Engine 会跟踪这些状态迁移并通过其发现函数discovery functions把状态暴露给其他 Worker 和工具链从而让整个系统能对拓扑变化做出反应。处理 Worker 断连当某个 Worker 的 WebSocket 关闭时Engine 会自动完成清理该 Worker 的 Functions 和 Triggers 会离开实时注册表对这些函数正在进行中的调用会被取消。调用方需要处理两件事捕获invocation_stopped错误。正在等待某函数结果、而该函数所属 Worker 中途断开的调用方收到的是invocation_stopped错误而非超时。应把它当作**取消cancellation**处理而不是瞬时失败——在 Worker 重连并重新注册该函数之前重试都会失败。这个错误码在 Engine 源码中有明确定义见 invocation 模块。订阅发现事件若需要对拓扑变化做出反应engine::workers-availableWorker 连接或断开时立即触发engine::functions-available最终一致——当函数列表的哈希发生变化后在下一个轮询周期触发Engine 内置引擎函数的实现说明其轮询周期为 5 秒见 engine_fn README。这两个触发器名称在 Engine 源码中以常量定义TRIGGER_FUNCTIONS_AVAILABLE / TRIGGER_WORKERS_AVAILABLE注册一个针对它们中任意一个的 Trigger即可在自己的 Worker 中感知拓扑变化。检查实时注册表要查看当前有哪些组件接入了 Engine按快照还是订阅两种需求使用两种调用面读取快照——调用engine::*::list系列函数engine::workers::list列出所有已连接的 Worker 及其指标metricsengine::functions::list列出所有已注册的函数可用include_internal过滤内部函数默认不包含engine::*前缀的引擎函数engine::triggers::list列出所有已注册的触发器同样支持include_internal过滤engine::trigger-types::list列出所有已声明的触发器类型及其配置 schema 与调用 schema。从源码可以看到engine::functions::list实际支持的过滤参数比文档更丰富见 FunctionsListInput 定义除include_internal外还支持search对function_id和描述做不区分大小写的子串匹配、prefix对function_id做精确前缀匹配、worker/workers按 Worker 名精确匹配workers可一次查询多个 Worker 的函数。订阅变更——把 Trigger 注册到以下事件上engine::workers-availableWorker 连接或断开时触发engine::functions-available函数被注册或注销后触发最终一致语义见上一节。这些是高层调用面如需了解线上协议wire-level的具体报文结构请参考 Engine SDK 参考文档 中的 Engine discovery functions 一节。Worker 清单iii.worker.yaml当 Worker 被检入项目、由 iii 在本地拉起时Worker 根目录下的iii.worker.yaml告诉 iii 如何安装依赖、如何运行 Worker以及如何透传配置name: math-worker runtime: kind: python package_manager: pip entry: math_worker.py scripts: install: pip install -r requirements.txt start: python math_worker.py字段含义name是 Worker 在 iii 中的名字runtime.kind声明运行时此处为 Pythonpackage_manager声明依赖管理器entry是入口文件scripts.install在安装阶段执行scripts.start用于启动 Worker 进程。完整字段 schema 见 Using iii / Workers 参考页。关键在于理解清单的定位iii.worker.yaml只是关于启动Worker 的元数据。Worker 跑起来之后真正起作用的是它与 Engine 的 WebSocket 连接和函数注册行为。由iii worker add拉起的 Worker 与在容器里手工启动的 Worker在 Engine 看来行为完全一致——Engine 只认连接不认进程是怎么来的。Worker 连接后贡献了什么一个 Worker 连接成功后会向系统暴露两类资源Functions系统中任何位置都可以按function_id调用参见 Using iii / FunctionsTriggersWorker 声明的触发器其他 Worker 可以把函数绑定到这些触发器上参见 Using iii / Triggers。Worker 内部注册这两类资源所用的 SDK 调用是语言相关的各语言的 Worker 编写指南中有详细说明。运行一次性ephemeralWorker对于一次性任务Kubernetes Job、serverless 容器、定时脚本SDK Worker 可以连接到一个远程Engine、注册所需函数、完成工作后直接退出进程Engine 会在断连时自动清理该 Worker 的全部注册项。做法是设置III_URL指向远程 Engine见上文连接 Engine一节注册该任务需要暴露的函数任务完成后让进程自然退出。这种模式无需为短任务维持长连接或常驻进程配合 Engine 的自动清理机制注册表不会残留幽灵函数。实操补充本地管理 Worker 的 CLI 命令文档中提到的iii worker add只是 Worker 管理的入口。配合 Using iii / Workers 参考页日常运维还可以使用iii worker add name # 安装 Worker 到项目并自动启动 iii worker reinstall name # 强制重新下载等价于 add --force iii worker list # 列出 config.yaml 中声明的所有 Worker 及状态 iii worker start name # 启动 iii worker stop name # 停止 iii worker restart name # 停止后重启 iii worker status name # 查看配置、沙箱状态、近期日志 iii worker logs name # 流式查看 Worker 日志 iii worker exec name -- command # 在 Worker 沙箱内执行命令这些命令面向的是由项目config.yaml托管的 Worker而 Engine 侧对 Worker 的感知仍然只通过 WebSocket 注册表——这正呼应了本文的核心结论对 Engine 而言无论 Worker 如何被启动唯一重要的是那条连接和注册上来的函数与触发器。小结Worker 是 iii 系统能力的扩展单元唯一的耦合点是III_URL指向的 WebSocket 地址生命周期按connecting → connected → available/busy → disconnected流转Engine 通过发现函数对外暴露状态断连时 Engine 自动注销函数与触发器并取消在途调用调用方应把invocation_stopped当取消处理并订阅engine::workers-available/engine::functions-available感知拓扑变化engine::workers::list/functions::list/triggers::list/trigger-types::list提供注册表快照iii.worker.yaml只负责本地启动元数据不改变 Engine 侧行为一次性任务可用 ephemeral Worker 模式连接、注册、干活、退出注册由 Engine 在断连时自动清理。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考