开发者进阶中级259 次阅读
RPC 容灾：多节点、重试与降级策略
单一 RPC 是 DApp 最常见的单点故障；本文讲清为什么它致命，以及多节点、重试、降级与可观测性该怎么设计。
#RPC#容灾#可用性#降级#运维
一句话结论
前端只连一个 RPC 的 DApp，实际上把一个没有服务等级承诺的第三方服务放在了关键路径上：它一抖动，用户就会以为协议挂了。
为什么单点 RPC 特别致命
- 公共节点有限流：免费端点通常按请求量或频率限速，高峰期最先被牺牲的就是你；跨域策略还可能直接拒绝你的域名。
- 自建节点也会出问题：重启、升级、同步落后都会造成短时不可用，而且恢复时间不由你控制。
- 节点可能落后：读到偏旧的区块高度，会让你展示的余额、状态与用户钱包里的实际状态不一致。
- 地区与网络因素：用户所在网络或地区对某些端点的连通性差异很大，你在办公室测不出来。
对一个链上应用来说，RPC 挂掉的体感等同于「协议挂掉了」——即使合约本身运行得好好的。
多节点与重试策略
- 至少配置两家不同服务商的端点，按优先级和健康度轮询，而不是主备里备的那台永远没被验证过。
- 读写区别对待：读操作可以大胆重试和切换；写操作要小心中间状态，避免同一笔意图被发两次。发送交易的重试要注意 nonce 与已有交易的关系，不能在语义上重复扣款。
- 超时加退避：给每次请求设明确超时，失败后按退避重试，并设总次数上限，避免请求堆积拖垮页面。
- 状态一致性要交代清楚：不同节点返回的高度可能不同，展示数据时最好标注对应的区块高度，让用户知道数据的新鲜度。
- 把端点做成配置：不要硬编码在代码里，方便出问题时快速切换，也方便让高级用户自定义。
可观测与降级
记录每个端点的成功率、延迟和高度偏差。降级必须伴随日志和告警，否则你会长期在降级状态下运行而毫不知情。界面上要有明确的「网络异常、数据可能延迟」状态，而不是让用户对着转圈的界面等到放弃。
给你的教训
- 把 RPC 可用性当成一条正式的可用性指标来监控，它最容易被忽略。
- 关键读操作要有兜底：本地缓存加明确的延迟提示，好过一直转圈。
- 不要悄悄降级：降级要写日志、要告警、要在状态页上说。
- 定期验证备用端点：没被验证过的备用方案，等于没有备用方案。