iii 引擎配置实战--config参数、config.yaml结构与首启种子机制【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档《Engine》0.21.0 版展开完整讲解 iii 引擎的启动方式、config.yaml的结构语义、${VAR:default}环境变量展开以及默认配置行为并结合当前仓库engine/目录下的源码main.rs、workers/config.rs 等逐条印证文档描述背后的实现逻辑。读完本文你可以独立完成引擎启动、worker 声明、首启配置种子与环境变量化配置并理解配置热加载与“种子块被消费后自动剥离”的底层机制。引擎的定位一个路由器在 iii 的架构中引擎engine本身不承载业务逻辑它的职责是接收函数调用请求、将其路由到已连接的 worker、再把结果按需要路由回调用方。config.yaml中声明的 worker 只是引擎在启动时要拉起/纳管的服务清单而非整个系统的进程管理器。这一点是理解后续所有配置语义的前提。引擎启动config.yaml与--config参数引擎从项目根目录的config.yaml文件启动也可以用--config path指向其他文件iii --config config.yaml当文件尚不存在时iii会主动提示是否创建它适合首次运行和临时试用非交互会话容器、CI、服务管理器则会直接创建而不询问。源码印证--config的解析与缺省行为在 engine/src/main.rs 中--config被定义为根命令的一个OptionString参数同时带短选项-c注释明确说明默认回退到config.yaml且刻意用Option而非default_value以便引擎能区分显式指定的文件和缺省文件名。config_path_of()main.rs负责把显式值或缺省值解析成最终路径。文件缺失时的处理逻辑在ensure_config_file()main.rs中若 stdin 和 stderr 都是终端交互式打印提示No config.yaml found in dir. Create it and start the engine? [Y/n]用户拒绝则直接中止不落任何文件若不是终端容器、CI、服务管理器跳过询问直接写入初始模板初始模板由EngineConfig::starter_config_yaml()生成见下文默认配置一节。确认文件存在后run_serve()main.rs按以下链路启动let config EngineConfig::config_file(config_path)?; // 读文件 展开环境变量 解析 校验 logging::init_log_from_config(Some(config_path)); let engine EngineBuilder::new() .with_config(config) .with_config_path(config_path) // 记录路径启用文件监听与热重载 .build() .await?; engine.serve().await?;with_config_path是关键只有设置了文件路径引擎才会监听该文件并自动热重载以内存配置方式编程启动时文件监听是关闭的workers/config.rs。配置文件结构workers列表与 WorkerEntryconfig.yaml只有一个顶层键workers:列出引擎应当加载的 worker。每个条目包含nameregistry slug 或本地 worker 名可选的config块其结构由该 worker 自行定义且只被读取一次作为首启种子first-boot seed。一个裸的- name:条目即没有config块会以该 worker 的内建默认值启动。文档给出的完整示例如下workers: - name: http config: port: 3111 host: 127.0.0.1 - name: state config: adapter: name: kv config: store_method: file_based file_path: ./data/state_store.db各 worker 的config块 schema 定义在各自 worker 的 Worker Docs 页面上可在 Worker Registry 文档 中查找对应 worker 的配置参考。源码印证EngineConfig与WorkerEntry的结构定义EngineConfig的结构体定义在 engine/src/workers/config.rs#[derive(Debug, Deserialize)] #[serde(deny_unknown_fields)] pub struct EngineConfig { /// 新 worker 连接在多久内等待其 namespace 注册 /// 超时则被分配到 default #[serde(default default_registration_namespace_grace_ms)] pub registration_namespace_grace_ms: u64, #[serde(default)] pub modules: VecWorkerEntry, // 旧版顶层键与 workers 等价 #[serde(default)] pub workers: VecWorkerEntry, }几个值得注意的实现事实deny_unknown_fields顶层写错键名会直接解析失败并给出清晰错误避免拼错字段被静默忽略这类配置事故registration_namespace_grace_ms控制新 worker 连接等待 namespace 注册的宽限期缺省值来自 engine/src/engine/mod.rs 中的REGISTRATION_NAMESPACE_GRACE5 秒modules是历史遗留的等价顶层键构建时会与workers合并处理workers/config.rs。单条 worker 条目WorkerEntry的定义workers/config.rs#[derive(Debug, Deserialize, Clone, PartialEq)] pub struct WorkerEntry { pub name: String, #[serde(default)] pub image: OptionString, // 预留的镜像/外部进程字段 #[serde(default)] pub config: OptionValue, // 任意 JSON 值结构由具体 worker 定义 }config被解析为无类型约束的Value这正是config块的形状由各 worker 自己定义这一文档描述在代码层面的体现引擎不做逐字段校验worker 在自己的工厂函数中消费它。此外构建阶段EngineBuilder::build()还有两个细节强制 worker 自动注入注册时标记为mandatory的内置服务如 configuration、iii-worker-manager、可观测性等内部服务如果没在配置文件中声明会被自动补入 worker 列表workers/config.rs——这就是文档所说引擎以内置服务启动你只需为其余部分显式 opt-in的实现来源重名实例编号同名条目第二次出现起会被自动改写为name#1、name#2assign_instance_idsworkers/config.rs使热重载的 diff 能把每个实例独立追踪。首启种子config:块的生命周期这是该文档最核心、也最容易被误解的语义worker 下的config:块是首启种子不是长期配置。注册了配置 schema 的 worker 会读取它一次用它在 configuration worker 中创建自己的配置条目此后该 worker 的设置以每个 worker 一个文件的形式存放在./config/目录下可实时从磁盘、console 或configuration::set编辑引擎会把已消费的config:块从config.yaml中删除在原位置留下一条注释。源码印证种子块的剥离strip逻辑serve()启动路径中包含一段专门的消费块剥离逻辑engine/src/workers/config.rs对每个带config:块的条目调用configuration::get检查该 worker 的配置值是否已持久化到配置存储若已持久化说明首启种子已被消费调用config_rewrite::apply_strip实现见 engine/src/workers/config_rewrite.rs把config:块从 YAML 中剥离——保留- name:条目本身并在原位置写入一条面包屑注释指向./config/id.yaml这类实际存放位置同时把内存中对应条目的config置空确保后续热重载的 diff 不会把这次自写误判为配置变更而无谓重启 worker。注释中还说明了顺序讲究剥离动作发生在文件监听器创建之前因此这些自写永远不会触发一次重载。若值尚未持久化worker 还没启动过块会原样保留等待首启时再被读取——这与文档读一次作为种子的描述完全一致。完整生命周期参见 Configuration 文档。边界澄清引擎不读iii.lock文档特别强调引擎读取的是config.yaml并拉起磁盘上已安装的 worker它不读取iii.lock。锁文件是worker 安装层面的关注点由iii worker sync/update/verify写入与消费目的是让安装可复现。iii.lock的完整机制见 Workers 文档。换言之config.yaml回答这个引擎实例要运行哪些 worker、首启种子是什么iii.lock回答这些 worker 的二进制/包来自哪个版本两者互不读取、各管一段。worker 可以部署在任意位置另一个重要边界worker 无需与 iii 引擎同机运行。在config.yaml中声明 worker 只是一种便利引擎负责拉起它worker 也可以部署在任何地方只需一个到 iii 实例的连接串即可注册上线。连接方式见 Creating Workers / Connecting to the engine。这使 iii 天然支持引擎在一处、worker 分布式的部署形态。版本演进提示以上描述针对 0.21.0 文档。在当前仓库主线代码engine/Cargo.toml中版本为0.23.0-rc.9中workers:的允许范围已收紧为与引擎生命周期绑定的闭集其他 worker 需迁移到worker-compose.yaml引擎对不支持的声明会报UNSUPPORTED_CONFIG_WORKERS并给出迁移指引校验逻辑见 workers/config.rs同时iii worker子命令已从根 CLI 移除main.rs 测试。如果你的项目基于主线构建请以仓库 next 版本文档 为准。环境变量展开${VAR:default}config.yaml中的值支持${VAR:default}语法展开时取环境变量VAR的值变量未设置时回退到default。用它可以在不复制配置文件的前提下按环境切换端口、URL 和功能开关。同样的语法也适用于每个 worker 的持久化配置文件./config/下且占位符在每次读取时重新展开详见 Configuration 文档。文档示例workers: - name: http config: port: ${HTTP_PORT:3111} host: ${HTTP_HOST:127.0.0.1}源码印证展开的实现与失败行为展开逻辑集中在EngineConfig::expand_env_vars()engine/src/workers/config.rs用一个正则\$\{([^}:])(?::([^}]*))?\}匹配${VAR}与${VAR:default}两种形式变量存在 → 用其值替换变量不存在但有默认值 → 用默认值替换还有一个特殊令牌__III_ENGINE_VERSION__会被替换为引擎自身版本号变量不存在且没有默认值 → 记录 error 日志并 panic错误信息明确指出哪个变量未设置且未提供默认值。这是有意的快速失败设计配置中引用了必然为空的环境变量时引擎宁可启动失败也不带残缺配置运行。展开发生在config_file()workers/config.rs中顺序为读文件 →expand_env_vars→serde_yaml解析 → 声明校验。该函数同时被引擎启动和异步热重载路径调用源码注释特别强调它不得改动进程级环境变量状态tokio 运行时下set_var是未定义行为这也是占位符每次读取时重新展开而非缓存的原因。默认配置空workers:列表与热重载在没有config.yaml的目录中运行iii它提供创建该文件的选项非交互会话直接创建。创建出的文件以空workers:列表开始引擎以内置服务启动SDK worker 连接的 WebSocket 监听器、configuration worker、可观测性服务其余能力通过iii worker add name逐个 opt-in引擎监听该文件新增 worker 会被实时拉起。worker 以各自内建默认值启动运行期可通过 configuration worker 或./config/下的持久化文件定制端口、adapter、凭据。若想以初始配置作为种子则在 worker 首次启动前给对应条目加上config:块。源码印证初始模板与文件监听自动创建写入的模板由starter_config_yaml()生成workers/config.rs内容刻意保持极简——就是workers: []注释解释了为何写成[]而不是裸workers:键严格解析器拒绝 null 列表# iii engine configuration. # Declare project workers in worker-compose.yaml and run iii compose --up. # Configure engine workers at runtime through the configuration worker (configuration::set). workers: []空列表也能启动正是内置服务不需要条目的体现mandatory 服务由build()自动注入。文件监听picks new workers up live实现在serve()中workers/config.rs使用notify的RecommendedWatcher监听配置文件所在目录而非文件本身——因为 vim 等编辑器采用写临时文件再 rename的原子保存直接监听文件会漏掉事件事件回调中过滤掉未触及配置文件本身的变更config.rs避免同目录的引擎日志、SQLite WAL 等文件变动反复触发重建触发后做500ms 去抖合并连续写入再交由ReloadManager::reloadengine/src/workers/reload.rs重读配置、diff 出增减只重启受影响的 worker。仓库中 engine/config.yaml 与 sdk/fixtures/config-test.yaml 等文件可作为真实配置样例参考。附引擎内建的安全约束从源码结构看引擎还内建了一组针对出站 URL 的安全约束engine/src/config/mod.rs 定义了SecurityConfig包含url_allowlist默认[*]、block_private_ips默认true和require_https默认true并可转换为调用层的UrlValidatorConfig使用同文件impl FromSecurityConfig for UrlValidatorConfig。该结构同样启用了deny_unknown_fields并有完整的序列化回环与默认值测试mod.rs 测试是引擎侧对 URL 访问面的基础防护。小结机制行为源码位置--config path指定配置文件缺省config.yamlengine/src/main.rs、main.rs文件缺失交互询问 / 非交互直接创建空模板engine/src/main.rsworkers:条目name 可选config种子块engine/src/workers/config.rs首启种子消费后剥离config:块并留注释engine/src/workers/config.rs${VAR:default}启动与每次热加载时展开缺省值缺失则 panicengine/src/workers/config.rs热重载监听目录、500ms 去抖、diff 重启engine/src/workers/config.rs锁文件引擎不读iii.lock安装层专用见 Workers 文档理解种子一次性、持久化在别处、文件可热重载、锁文件不相干这四条主线就能准确掌握 iii 引擎的配置体系并在 0.21.x 与更新版本之间做配置迁移时不被表层变化迷惑。【免费下载链接】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 引擎配置实战：`--config` 参数、`config.yaml` 结构与首启种子机制
iii 引擎配置实战--config参数、config.yaml结构与首启种子机制【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档《Engine》0.21.0 版展开完整讲解 iii 引擎的启动方式、config.yaml的结构语义、${VAR:default}环境变量展开以及默认配置行为并结合当前仓库engine/目录下的源码main.rs、workers/config.rs 等逐条印证文档描述背后的实现逻辑。读完本文你可以独立完成引擎启动、worker 声明、首启配置种子与环境变量化配置并理解配置热加载与“种子块被消费后自动剥离”的底层机制。引擎的定位一个路由器在 iii 的架构中引擎engine本身不承载业务逻辑它的职责是接收函数调用请求、将其路由到已连接的 worker、再把结果按需要路由回调用方。config.yaml中声明的 worker 只是引擎在启动时要拉起/纳管的服务清单而非整个系统的进程管理器。这一点是理解后续所有配置语义的前提。引擎启动config.yaml与--config参数引擎从项目根目录的config.yaml文件启动也可以用--config path指向其他文件iii --config config.yaml当文件尚不存在时iii会主动提示是否创建它适合首次运行和临时试用非交互会话容器、CI、服务管理器则会直接创建而不询问。源码印证--config的解析与缺省行为在 engine/src/main.rs 中--config被定义为根命令的一个OptionString参数同时带短选项-c注释明确说明默认回退到config.yaml且刻意用Option而非default_value以便引擎能区分显式指定的文件和缺省文件名。config_path_of()main.rs负责把显式值或缺省值解析成最终路径。文件缺失时的处理逻辑在ensure_config_file()main.rs中若 stdin 和 stderr 都是终端交互式打印提示No config.yaml found in dir. Create it and start the engine? [Y/n]用户拒绝则直接中止不落任何文件若不是终端容器、CI、服务管理器跳过询问直接写入初始模板初始模板由EngineConfig::starter_config_yaml()生成见下文默认配置一节。确认文件存在后run_serve()main.rs按以下链路启动let config EngineConfig::config_file(config_path)?; // 读文件 展开环境变量 解析 校验 logging::init_log_from_config(Some(config_path)); let engine EngineBuilder::new() .with_config(config) .with_config_path(config_path) // 记录路径启用文件监听与热重载 .build() .await?; engine.serve().await?;with_config_path是关键只有设置了文件路径引擎才会监听该文件并自动热重载以内存配置方式编程启动时文件监听是关闭的workers/config.rs。配置文件结构workers列表与 WorkerEntryconfig.yaml只有一个顶层键workers:列出引擎应当加载的 worker。每个条目包含nameregistry slug 或本地 worker 名可选的config块其结构由该 worker 自行定义且只被读取一次作为首启种子first-boot seed。一个裸的- name:条目即没有config块会以该 worker 的内建默认值启动。文档给出的完整示例如下workers: - name: http config: port: 3111 host: 127.0.0.1 - name: state config: adapter: name: kv config: store_method: file_based file_path: ./data/state_store.db各 worker 的config块 schema 定义在各自 worker 的 Worker Docs 页面上可在 Worker Registry 文档 中查找对应 worker 的配置参考。源码印证EngineConfig与WorkerEntry的结构定义EngineConfig的结构体定义在 engine/src/workers/config.rs#[derive(Debug, Deserialize)] #[serde(deny_unknown_fields)] pub struct EngineConfig { /// 新 worker 连接在多久内等待其 namespace 注册 /// 超时则被分配到 default #[serde(default default_registration_namespace_grace_ms)] pub registration_namespace_grace_ms: u64, #[serde(default)] pub modules: VecWorkerEntry, // 旧版顶层键与 workers 等价 #[serde(default)] pub workers: VecWorkerEntry, }几个值得注意的实现事实deny_unknown_fields顶层写错键名会直接解析失败并给出清晰错误避免拼错字段被静默忽略这类配置事故registration_namespace_grace_ms控制新 worker 连接等待 namespace 注册的宽限期缺省值来自 engine/src/engine/mod.rs 中的REGISTRATION_NAMESPACE_GRACE5 秒modules是历史遗留的等价顶层键构建时会与workers合并处理workers/config.rs。单条 worker 条目WorkerEntry的定义workers/config.rs#[derive(Debug, Deserialize, Clone, PartialEq)] pub struct WorkerEntry { pub name: String, #[serde(default)] pub image: OptionString, // 预留的镜像/外部进程字段 #[serde(default)] pub config: OptionValue, // 任意 JSON 值结构由具体 worker 定义 }config被解析为无类型约束的Value这正是config块的形状由各 worker 自己定义这一文档描述在代码层面的体现引擎不做逐字段校验worker 在自己的工厂函数中消费它。此外构建阶段EngineBuilder::build()还有两个细节强制 worker 自动注入注册时标记为mandatory的内置服务如 configuration、iii-worker-manager、可观测性等内部服务如果没在配置文件中声明会被自动补入 worker 列表workers/config.rs——这就是文档所说引擎以内置服务启动你只需为其余部分显式 opt-in的实现来源重名实例编号同名条目第二次出现起会被自动改写为name#1、name#2assign_instance_idsworkers/config.rs使热重载的 diff 能把每个实例独立追踪。首启种子config:块的生命周期这是该文档最核心、也最容易被误解的语义worker 下的config:块是首启种子不是长期配置。注册了配置 schema 的 worker 会读取它一次用它在 configuration worker 中创建自己的配置条目此后该 worker 的设置以每个 worker 一个文件的形式存放在./config/目录下可实时从磁盘、console 或configuration::set编辑引擎会把已消费的config:块从config.yaml中删除在原位置留下一条注释。源码印证种子块的剥离strip逻辑serve()启动路径中包含一段专门的消费块剥离逻辑engine/src/workers/config.rs对每个带config:块的条目调用configuration::get检查该 worker 的配置值是否已持久化到配置存储若已持久化说明首启种子已被消费调用config_rewrite::apply_strip实现见 engine/src/workers/config_rewrite.rs把config:块从 YAML 中剥离——保留- name:条目本身并在原位置写入一条面包屑注释指向./config/id.yaml这类实际存放位置同时把内存中对应条目的config置空确保后续热重载的 diff 不会把这次自写误判为配置变更而无谓重启 worker。注释中还说明了顺序讲究剥离动作发生在文件监听器创建之前因此这些自写永远不会触发一次重载。若值尚未持久化worker 还没启动过块会原样保留等待首启时再被读取——这与文档读一次作为种子的描述完全一致。完整生命周期参见 Configuration 文档。边界澄清引擎不读iii.lock文档特别强调引擎读取的是config.yaml并拉起磁盘上已安装的 worker它不读取iii.lock。锁文件是worker 安装层面的关注点由iii worker sync/update/verify写入与消费目的是让安装可复现。iii.lock的完整机制见 Workers 文档。换言之config.yaml回答这个引擎实例要运行哪些 worker、首启种子是什么iii.lock回答这些 worker 的二进制/包来自哪个版本两者互不读取、各管一段。worker 可以部署在任意位置另一个重要边界worker 无需与 iii 引擎同机运行。在config.yaml中声明 worker 只是一种便利引擎负责拉起它worker 也可以部署在任何地方只需一个到 iii 实例的连接串即可注册上线。连接方式见 Creating Workers / Connecting to the engine。这使 iii 天然支持引擎在一处、worker 分布式的部署形态。版本演进提示以上描述针对 0.21.0 文档。在当前仓库主线代码engine/Cargo.toml中版本为0.23.0-rc.9中workers:的允许范围已收紧为与引擎生命周期绑定的闭集其他 worker 需迁移到worker-compose.yaml引擎对不支持的声明会报UNSUPPORTED_CONFIG_WORKERS并给出迁移指引校验逻辑见 workers/config.rs同时iii worker子命令已从根 CLI 移除main.rs 测试。如果你的项目基于主线构建请以仓库 next 版本文档 为准。环境变量展开${VAR:default}config.yaml中的值支持${VAR:default}语法展开时取环境变量VAR的值变量未设置时回退到default。用它可以在不复制配置文件的前提下按环境切换端口、URL 和功能开关。同样的语法也适用于每个 worker 的持久化配置文件./config/下且占位符在每次读取时重新展开详见 Configuration 文档。文档示例workers: - name: http config: port: ${HTTP_PORT:3111} host: ${HTTP_HOST:127.0.0.1}源码印证展开的实现与失败行为展开逻辑集中在EngineConfig::expand_env_vars()engine/src/workers/config.rs用一个正则\$\{([^}:])(?::([^}]*))?\}匹配${VAR}与${VAR:default}两种形式变量存在 → 用其值替换变量不存在但有默认值 → 用默认值替换还有一个特殊令牌__III_ENGINE_VERSION__会被替换为引擎自身版本号变量不存在且没有默认值 → 记录 error 日志并 panic错误信息明确指出哪个变量未设置且未提供默认值。这是有意的快速失败设计配置中引用了必然为空的环境变量时引擎宁可启动失败也不带残缺配置运行。展开发生在config_file()workers/config.rs中顺序为读文件 →expand_env_vars→serde_yaml解析 → 声明校验。该函数同时被引擎启动和异步热重载路径调用源码注释特别强调它不得改动进程级环境变量状态tokio 运行时下set_var是未定义行为这也是占位符每次读取时重新展开而非缓存的原因。默认配置空workers:列表与热重载在没有config.yaml的目录中运行iii它提供创建该文件的选项非交互会话直接创建。创建出的文件以空workers:列表开始引擎以内置服务启动SDK worker 连接的 WebSocket 监听器、configuration worker、可观测性服务其余能力通过iii worker add name逐个 opt-in引擎监听该文件新增 worker 会被实时拉起。worker 以各自内建默认值启动运行期可通过 configuration worker 或./config/下的持久化文件定制端口、adapter、凭据。若想以初始配置作为种子则在 worker 首次启动前给对应条目加上config:块。源码印证初始模板与文件监听自动创建写入的模板由starter_config_yaml()生成workers/config.rs内容刻意保持极简——就是workers: []注释解释了为何写成[]而不是裸workers:键严格解析器拒绝 null 列表# iii engine configuration. # Declare project workers in worker-compose.yaml and run iii compose --up. # Configure engine workers at runtime through the configuration worker (configuration::set). workers: []空列表也能启动正是内置服务不需要条目的体现mandatory 服务由build()自动注入。文件监听picks new workers up live实现在serve()中workers/config.rs使用notify的RecommendedWatcher监听配置文件所在目录而非文件本身——因为 vim 等编辑器采用写临时文件再 rename的原子保存直接监听文件会漏掉事件事件回调中过滤掉未触及配置文件本身的变更config.rs避免同目录的引擎日志、SQLite WAL 等文件变动反复触发重建触发后做500ms 去抖合并连续写入再交由ReloadManager::reloadengine/src/workers/reload.rs重读配置、diff 出增减只重启受影响的 worker。仓库中 engine/config.yaml 与 sdk/fixtures/config-test.yaml 等文件可作为真实配置样例参考。附引擎内建的安全约束从源码结构看引擎还内建了一组针对出站 URL 的安全约束engine/src/config/mod.rs 定义了SecurityConfig包含url_allowlist默认[*]、block_private_ips默认true和require_https默认true并可转换为调用层的UrlValidatorConfig使用同文件impl FromSecurityConfig for UrlValidatorConfig。该结构同样启用了deny_unknown_fields并有完整的序列化回环与默认值测试mod.rs 测试是引擎侧对 URL 访问面的基础防护。小结机制行为源码位置--config path指定配置文件缺省config.yamlengine/src/main.rs、main.rs文件缺失交互询问 / 非交互直接创建空模板engine/src/main.rsworkers:条目name 可选config种子块engine/src/workers/config.rs首启种子消费后剥离config:块并留注释engine/src/workers/config.rs${VAR:default}启动与每次热加载时展开缺省值缺失则 panicengine/src/workers/config.rs热重载监听目录、500ms 去抖、diff 重启engine/src/workers/config.rs锁文件引擎不读iii.lock安装层专用见 Workers 文档理解种子一次性、持久化在别处、文件可热重载、锁文件不相干这四条主线就能准确掌握 iii 引擎的配置体系并在 0.21.x 与更新版本之间做配置迁移时不被表层变化迷惑。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考