副标题 / 摘要

RPC 看似像本地调用，但它的失败模式与成本完全不同。本文总结 RPC 的通用缺点与工程应对策略。

目标读者

  • 设计微服务通信的工程师
  • 需要评估 RPC 成本的技术负责人
  • 想避免分布式陷阱的开发者

背景 / 动机

RPC 把“跨网络调用”伪装成本地函数。
这会导致开发者低估失败概率与性能成本，从而引发稳定性问题。

核心概念

  • 网络不可靠性：超时、丢包、抖动
  • 部分失败：某些节点失败，其他正常
  • 重试风暴：错误重试导致雪崩
  • 版本演进：接口变更与兼容性问题

实践指南 / 步骤

  1. 为 RPC 设置超时与重试策略
  2. 避免级联调用
  3. 引入熔断与降级
  4. 做好可观测性（日志/追踪）
  5. 管理版本兼容性

可运行示例

import time
import random


def rpc_call():
    time.sleep(random.random() * 0.2)
    if random.random() < 0.2:
        raise TimeoutError("rpc timeout")
    return "ok"


if __name__ == "__main__":
    try:
        print(rpc_call())
    except TimeoutError as e:
        print("fail", e)

解释与原理

RPC 的本质是网络调用，失败概率远高于本地函数。
把它当作本地调用，会导致过度耦合与错误传播。

常见问题与注意事项

  1. RPC 一定比消息队列好吗？
    不一定，取决于一致性与解耦需求。

  2. 为什么重试会导致雪崩？
    因为失败请求叠加更多压力。

  3. RPC 的最大风险是什么？
    部分失败与不可预测延迟。

最佳实践与建议

  • 所有 RPC 都必须设置超时
  • 设计幂等与重试策略
  • 限制同步链路长度

小结 / 结论

RPC 的缺点来自网络不可靠性与分布式复杂性。
只有理解并控制这些成本，才能安全使用 RPC。

参考与延伸阅读

  • The Fallacies of Distributed Computing
  • gRPC 官方指南
  • 分布式系统设计最佳实践

元信息

  • 阅读时长：7~9 分钟
  • 标签：RPC、分布式系统、可靠性
  • SEO 关键词：RPC, 分布式系统, 超时
  • 元描述：总结 RPC 的通用缺点与工程应对策略。

行动号召（CTA）

检查一次你的 RPC 调用链，看看是否存在超时与重试配置缺失。