RPC函数

RPC 想解决的问题很简单：让调用远程服务像调用本地函数一样容易。这个想法听起来很美好，但它建立在一个微妙的谎言之上。

距离依然存在

当你写下 result = getUserInfo(userId) 这样的代码，你可能没有意识到这个函数调用穿越了多少层网络。RPC 框架帮你隐藏了所有细节：参数的序列化、网络传输、服务端的查找、结果的返回。

但隐藏不等于消失。网络依然会延迟，服务端依然会宕机，数据包依然会丢失。RPC 只是让你在写代码时可以暂时忘记这些，但在运行时，这些问题全都会回来。

这就是 RPC 的第一个真相：它降低了心智负担，但不能消除真实的复杂度。

同步的幻觉

传统的函数调用是同步的。你调用一个函数，程序停下来等它返回，然后继续执行。这种确定性让代码容易理解。

RPC 尝试保持这种同步的感觉。当你调用远程函数，线程会阻塞等待结果，就像调用本地函数一样。但这个等待和本地函数的等待完全不同。

本地函数可能执行几微秒，RPC 调用可能需要几十甚至几百毫秒。在这个等待过程中，服务端可能重启了，网络可能断了，或者只是单纯地慢。你的线程在那里空等，什么也做不了。

失败是常态

本地函数调用很少失败。如果函数存在，参数类型正确，它大概率会返回结果或抛出业务异常。你不需要担心函数突然消失，或者执行到一半失去响应。

但 RPC 调用会失败，而且会经常失败。网络不可靠是分布式系统的基本事实。你需要处理超时、重试、降级。每次调用都可能失败,而且可能以各种意想不到的方式失败。

这意味着你不能像对待本地函数那样对待 RPC。你需要时刻准备着处理失败，需要设计降级方案,需要思考重试会不会导致副作用。

RPC 让调用变简单了,但让错误处理变复杂了。

接口即契约

本地函数可以随时修改签名。改个参数名、加个默认值、调整返回类型,只要调用方同步更新就行。

但 RPC 的接口是契约。服务端和客户端可能由不同团队维护,可能部署在不同时间,可能运行着不同版本的代码。一旦接口发布,就很难改变。

你需要考虑向后兼容:新版本能不能兼容旧客户端?你需要版本控制:如何让新老接口共存?你需要灰度发布:如何确保变更不会影响线上服务?

这就是为什么 Protocol Buffers、Thrift 这些 IDL (Interface Definition Language) 会存在。它们强制你显式定义接口,强制你思考兼容性,强制你认真对待每一个字段的增删。

选择决定架构

当你决定用 RPC,你就在做架构选择。你在说:这两个服务之间的关系足够紧密,值得用同步调用。

但紧密也意味着耦合。A 服务直接调用 B 服务,B 的性能和可用性会直接影响 A。如果 B 变慢, A 也会变慢。如果 B 挂了, A 可能也没法正常工作。

这就是为什么很多系统后来会改用消息队列。消息队列让服务之间解耦,让失败可以优雅降级,让流量可以削峰填谷。但代价是丧失了 RPC 的简单和直观。

没有完美的选择,只有适合的选择。RPC 适合那些需要实时响应、逻辑紧密、延迟敏感的场景。对于可以异步处理、能容忍延迟、需要解耦的场景,消息队列可能更好。

性能的代价

RPC 框架会宣传自己有多快:高效的序列化、优化的传输、智能的负载均衡。但再快的 RPC 也无法改变物理定律。

网络延迟通常是毫秒级的。这意味着一次 RPC 调用比本地函数调用慢几千倍甚至几万倍。如果你在循环里调用 RPC,性能会灾难性地下降。

这就是为什么批量接口这么重要。与其调用一百次 getUser(id),不如调用一次 getUsers([id1, id2, ...])。与其在每个元素上调用远程函数,不如把整个数据传过去一次处理。

但批量意味着复杂:你需要处理部分失败、需要拆分大请求、需要平衡批次大小。简单的代码又变复杂了。

抽象的意义

RPC 不是完美的抽象。它隐藏了一些东西,但让另一些东西变得更难处理。

但这不意味着 RPC 是个坏主意。恰恰相反,RPC 是分布式系统中最常用的通信方式之一。因为它在复杂度和易用性之间找到了一个平衡点。

关键在于知道你在用什么。当你写 RPC 调用时,要记得这不是普通的函数调用。当你设计 RPC 接口时,要记得这是一个长期契约。当你调试 RPC 问题时,要记得网络和服务端都可能出错。

理解 RPC 的局限,才能更好地使用 RPC。

最后

远程和本地从来就不一样。RPC 让它们看起来一样,但本质的差异不会因为抽象而消失。

你可以用 RPC 写出优雅的代码,但前提是你理解这层抽象下隐藏的复杂性。你需要处理失败、管理超时、设计降级、考虑性能。

这些都是分布式系统必须面对的问题。RPC 只是让你可以先专注于业务逻辑,然后再回来处理这些问题。它不是魔法,只是一个工具。

理解工具的边界,才知道何时使用它,何时寻找其他方案。