模块 09查看课程目录
09
生产高级BEAMOTP
分布式与可运维性
节点能连上，不代表系统自动获得一致性与可靠性。
4检查点
6 小时预计完成
为什么先学这个
先修正心智模型，再增加 API
分布式 Erlang 让节点通信极其自然，也因此容易掩盖网络边界。节点名、cookie 和消息透明性解决了连接体验，却没有解决分区、一致性、容量和安全。
学完你能做到
可验证的学习目标
- 能启动并连接两个命名节点
- 能解释 nodedown、远程 PID 与注册名边界
- 能用结构化日志和指标定位 mailbox 增长
前置知识
- 理解进程协议、监督树与背压
- 会打包基本 OTP 应用
最小心智模型
先抓住三个词
node
运行中的分布式 BEAM 实例，名称通常形如 `name@host`。进程 PID 包含节点身份。
cookie
节点建立分布式连接时使用的共享秘密之一，不应当作完整的网络安全边界。
Telemetry
Elixir 生态常用的事件度量库。业务代码发事件，handler 决定如何聚合或导出。
双语代码桥
先对齐协议，再看标点
节点事件也是消息。收到 nodedown 后如何降级、重试或拒绝请求，是应用协议的一部分。
Elixir
:net_kernel.monitor_nodes(true)
receive do
{:nodeup, node} ->
Logger.info("node connected", node: node)
{:nodedown, node} ->
Logger.warning("node disconnected", node: node)
endErlang
net_kernel:monitor_nodes(true),
receive
{nodeup, Node} ->
logger:info("node connected", #{node => Node});
{nodedown, Node} ->
logger:warning("node disconnected", #{node => Node})
end.LAB
约 15–25 分钟可运行实验
亲手制造网络分区
启动两个本地节点，建立连接后停掉其中一个。观察 monitor、远程进程和未完成请求分别如何表现。
- 01
以相同 cookie 启动 `a@127.0.0.1` 与 `b@127.0.0.1`
- 02
从 A ping B，并 monitor_nodes
- 03
停止 B，记录 A 收到的事件与未完成请求结果
在终端 / shell 中运行
Node.ping(:"b@127.0.0.1")预期观察
- 连接成功返回 `:pong`
- B 停止后 A 收到 nodedown
- 应用必须决定请求是否重试或失败
故意弄坏
给两个节点配置不同 cookie。确认失败发生在连接认证，而不是你的业务消息 handler。
这个实验能证明
节点连接状态可被观察并转化为应用事件。
这个实验不能证明
本机停节点不能模拟真实网络的丢包、延迟、半开连接与脑裂组合。
快速自测
分布式 Erlang 的透明 PID 消息发送自动提供了什么？
本章挑战
双节点健康采集器
每个节点定期上报 scheduler、内存与关键 mailbox。聚合节点断开时标记 stale，不伪造 0。
提示 1轻推一下
指标值与采样时间一起传递。
提示 2缩小问题
断开后保留最后值和 stale 标记。
提示 3接近实现
为 mailbox 设置趋势告警，不只看单点阈值。
提示 4用验收标准反推
从下面每一条验收标准倒推一个最小测试。若某条无法写成测试，先把表述改成可观察结果。
完成标准
- 节点断开不会被显示为健康零值
- 日志包含 node、process、request/reference 上下文
- 重连后状态能恢复且不重复注册
带走这三句话
复习卡
- 1分布式透明性简化调用，不消除网络事实。
- 2断连、超时与陈旧数据必须进入协议。
- 3mailbox、延迟、重启和拒绝率是比“进程还活着”更有用的信号。
继续核对