实现一个Actor系统的过程中，监控器（Supervisor）往往是最后一块也是最难啃的骨头。作者花了三周时间从零实现，最终代码量不到400行，却暴露了.NET生态在容错设计上的集体沉默。
这不是教程，是一个产品经理转型系统开发者的踩坑记录。
为什么监控器让开发者头疼
Actor模型里，监控器的职责很纯粹：盯着子Actor，出事时兜底。但"兜底"二字背后藏着大量决策——重启还是停掉？只处理出事的那个还是一锅端？失败次数有没有上限？
作者最初以为这是配置问题，后来发现是设计哲学问题。Erlang的OTP用了二十年证明监控策略值得单独成体系，而.NET开发者至今还在用try-catch模拟容错。
他给自己定的目标很明确：支持两种经典策略。一对一（OneForOne）只处理出事的子Actor，一对多（AllForOne）则连带重启所有兄弟节点。后者适用于强一致性场景，比如一个支付子系统崩溃，整个订单流程需要回滚重来。
三个枚举背后的决策树
代码层面，作者先定了三个基础构件。Strategy枚举二选一，FailureAction四选一（重启、停止、上报、忽略），RestartPolicy三选一（永久、异常时、永不）。
这三个枚举的组合，构成了Actor生命周期的控制面板。Permanent策略适合无状态服务，挂了随时重启；Transient区分正常退出和异常崩溃，避免无限重启僵尸进程；Temporary则用于一次性任务，比如定时报表生成。
作者特别强调了Restart的语义：在Actor模型和.NET语境下，重启意味着销毁实例和邮箱，但保留IActorReference（Actor引用）。这个设计让外部调用方无感知——地址不变，里面换了个全新的工人。
如果出事的Actor本身是监控器，事情更复杂。它需要先停掉所有子节点，让它们的引用失效，再自我重启。这种级联销毁是容错系统的必要之恶，作者用了"kill and dispose"这种硬核表述。
接口设计的克制与留白
ISupervisor接口极其精简：一个继承自IActor的身份标记，一个只读的Children集合。作者刻意没有暴露AddChild或RemoveChild方法，这些操作被隐藏在Actor创建流程内部。
配套引入的IChildSpecification接口则承担了工厂角色。它描述了一个子Actor该怎么造：类型、邮箱实现、重启策略。默认实现ChildSpecification用了C# 9的record类型，邮箱默认走ChannelMailbox——这是.NET Core时代的高性能异步通道。
这种设计让监控器的创建代码读起来像配置文件，而不是指令序列。作者的原话是"describe how a child should be created"，描述而非命令，是声明式编程在系统层的渗透。
代码片段里有个细节：ChildSpecification的构造函数只强制要求ActorType，邮箱和策略都有默认值。这意味着最简单的场景下，开发者只需要传一个类型参数。
但作者没有展示完整的监控器实现。文章停在接口定义阶段，像一部悬疑片在揭晓凶手前切到片尾字幕。他预告了后续会覆盖具体实现，包括如何处理消息执行异常、如何统计失败频率触发熔断。
这种连载式写作本身也是一种产品策略——保持读者回访，同时给自己留出重构空间。毕竟监控器的代码一旦发布，就会被各路开发者拿着放大镜审视。
从已公开的代码看，作者的实现思路偏向Akka.NET的简化版，但去掉了大量隐式魔法。没有HOCON配置，没有复杂的调度器注入，一切显式、可追踪。这对习惯了Spring式自动装配的Java开发者可能显得原始，对需要精确控制资源的游戏服务器或高频交易系统却是刚需。
文章最后没有总结，只有一张未完成的架构图和读者的追问：当重启策略用尽，系统是该优雅降级还是直接崩溃？这个问题，作者留给了下一篇。
热门跟贴