用于构建可预测且弹性程序的 supervisor-tree 库

Source: Dev.to

声明

经过实战检验的想法，而非 AI 产物。
我设计了整体架构并亲自实现了大部分代码（>80%）。AI 主要用于生成单元测试和独立工具。

我现在发布 Runsmith，这是一套面向 Python 服务/系统的 Erlang/OTP 风格的监督树框架，适用于由多个长期运行程序组成的系统。

Runsmith 提供的功能

• Worker 抽象 – 每个单元都成为一个具有明确有限状态机（FSM）生命周期的 worker。
• 监督树 – 持续监控每个 worker，检测卡顿、超时以及崩溃，并将重启限制在出错的单元上，使系统其余部分保持运行。
• 丰富的并发模型 – worker 可以在线程、协程或自定义执行后端中运行，而不仅限于独立进程。
• 细粒度健康探针 – 通过约束违规或健康检查来发现故障，而不仅仅是异常进程退出。
• 嵌套故障域 – Erlang/OTP 风格的监督树实现层级化故障隔离。

起源故事

我为一家制造工厂的安全防护摄像系统构建后端，该系统对任何停机都零容忍。系统由多个需要长期运行并在故障时相互独立恢复的进程组成：

• Web 应用 – 提供 HTTP API 与 Server‑Sent Events 流。
• 算法 worker – 对输入帧执行计算机视觉推理。
• 摄像头控制器 – 与摄像头设备库交互并轮询帧数据。
• 后台任务运行器 – 执行定时任务，如周期性数据清理。
• ONVIF 服务

开发过程中我遇到了如下问题：

• 算法 worker 在推理过程中因第三方驱动故障而卡住。
• FastAPI Web 应用的事件循环因编写不当的同步代码而被饿死。

我的最初实现是一堆状态标志、重试逻辑、看门狗和探针的“乱七八糟的汤”。虽然能跑，但难以维护和推理。我需要一个把监督作为一等概念、并且故障隔离是结构化而非后加的框架。

Runsmith 正是基于此需求诞生的——为建模长期运行、具状态的功能单元提供统一结构。

与 supervisord 的比较

不，Runsmith 不是 supervisord。

• supervisord 是一个操作系统层面的进程控制守护进程，通过 PID 和静态配置管理外部程序。
• Runsmith 是 进程内、可编程的 Python 库，受监督的单元是具有明确生命周期的类型化 worker。

相比 supervisord 的优势

1. 丰富的并发模型 – worker 可以在线程、协程或自定义后端中运行，而不仅限于独立的 OS 进程。
2. 细粒度健康探针 – 通过约束违规和健康检查来检测故障，而不仅仅是异常退出。
3. 监督树架构 – 支持嵌套故障域，实现层级化故障隔离，借鉴 Erlang/OTP 的做法。