从零手写RPC框架：深入理解分布式远程调用的核心原理

如果你在技术团队里混过几年，大概率会反复听到一个词：RPC。我印象很深的是第一次接触它的时候——那时候系统正从单机往分布式改造，服务拆成了好几个进程，互相之间要调数据、要同步状态。当时最直接的反应就是：这不就是网络通信嘛，跟平时用HTTP调接口有什么区别？为什么大家都叫它RPC，还专门搞了一套框架出来？

后来因为工作需要，我自己动手写了一个玩具版的RPC框架，才算把这层窗户纸彻底捅破。写完那一刻才明白，RPC真正想做的事情不是“能调通”，而是“让你感觉不到它在远程”。这篇文章我就从零开始，把这几年对RPC的理解、踩过的坑、还有那段手写框架的完整经过分享出来。

这篇内容适合两类人：一类是刚接触分布式、微服务，想搞明白Dubbo、gRPC这类框架底层到底在做什么的新人；另一类是已经在用RPC框架，但遇到问题只能上网搜、没法自己排查的开发者。看完之后，你会具备自己动手实现一个最小RPC框架的能力，也能真正理解生产环境里那些超时、重试、连接池配置为什么那么重要。

1. 先搞清楚RPC到底在解决什么问题

1.1 从本地调用到远程调用，变的是什么

先想一个最简单的场景：你在同一个进程里调用一个方法，比如calculator.add(3, 5)。这个调用是“本地调用”，它走的是进程内的函数调用栈，参数直接压栈，方法执行完返回值传回来，整个过程是微秒级的，而且不会失败——至少不会因为网络问题失败。

但一旦系统变成多个服务、分布在多台机器上，问题就来了。服务A要调用服务B的方法，数据得先变成字节流，从A的进程发到B的进程，B反过来也要把结果传回去。中间隔着一张物理网络，什么丢包、延迟、超时、对端宕机都可能遇到。

我常跟人打的一个比方是这样的：本地调用就像你在办公室直接走到隔壁工位问同事要数据，而远程调用就像你要给另一家公司的合作方打电话要数据。最大的区别不是“电话”这个动作本身，而是你希望打电话的时候，体验上跟走过去说一句话一样自然。RPC解决的核心问题，就是让远程调用尽量像本地调用一样简单和透明。

这个“透明”是关键。调用方不需要关心对方在哪台机器、什么端口、用什么序列化格式，他只需要拿着接口调方法就行。至于底层怎么建立连接、怎么把参数传过去、怎么把返回值传回来，是RPC框架的职责。

1.2 一次RPC调用的完整旅程

把一次RPC调用拆开，它大概是这样的流程：

• 客户端拿到一个“代理对象”，这个代理长得很像那个远程服务接口。
• 调用方法时，代理拦截住这次调用，把方法名、参数类型、参数值这些信息打包成一个请求对象。
• 请求对象被序列化成字节流，通过Socket或HTTP连接发送到服务端。
• 服务端收到字节流，反序列化成请求对象，根据接口名和方法名找到对应的实现类。
• 通过反射执行真正的方法逻辑，拿到返回值。
• 返回值再被序列化，通过网络传回客户端。
• 客户端反序列化得到结果，返回给调用方。

整个过程走下来，调用方只做了一件事：调了一个普通方法。后面那一长串繁琐的逻辑全是框架包的。这也解释了为什么RPC的核心是“过程调用”（Procedure Call）——它要模拟的就是那个“过程”，而不是单纯的“收发消息”。

在这个旅程里，有几个环节是决定性能和稳定性的关键：序列化方式、传输层协议、服务如何被找到、代理怎么生成。下面一个一个拆开讲。

2. 拆开看：一个RPC框架的四个关键模块

2.1 序列化：把内存对象变成字节流

序列化这个模块，在所有RPC框架里都是重中之重，因为它直接决定了传输的数据量、CPU开销和跨语言能力。

为什么需要序列化？因为你的参数在内存里是一个对象，对象里面有各种字段、类型信息、嵌套结构。但网络传输是一根管道，管道里只能流通字节。所以发送前要把对象“拍扁”成字节数组，接收端再把字节数组“恢复”成对象。前者叫序列化，后者叫反序列化。

常见的序列化方案有这么几类：

• JSON：简单直观，调试方便，任何语言都能解析。但缺点是体积偏大，解析性能一般，对数字精度、日期类型支持不好。
• Protobuf：需要先定义proto文件，通过工具生成代码。优点是压缩率高、序列化速度快、有严格的Schema约束，非常适合内部服务间的高频调用。缺点是学习成本高，改字段要管理版本。
• Hessian：老牌的二进制序列化协议，兼容性好，很多Java系RPC框架在用，但跨语言能力一般。
• Java原生序列化：最简单，类实现Serializable就能用，但体积大、性能差，还有安全问题，基本不建议用在生产环境。

我的建议很明确：如果是内部系统、追求性能和稳定性，选Protobuf这一类带Schema的二进制协议；如果是一个小项目、几个服务之间调一调，或者需要方便调试，先用JSON也没什么可丢人的。我自己写的那个玩具RPC框架，图省事用的就是Java自带的序列化，因为我只求把流程跑通。一旦要上生产，第一个要换的就是它。

注意：序列化格式决定了RPC框架的“兼容性边界”。一旦你的服务被调方升级了序列化协议，而调用方没升级，两边就会互相看不懂。生产环境里改序列化格式，要按“灰度兼容”的思路来，保证新旧两种格式能共存一段时间。

2.2 传输层：走TCP还是走HTTP

传输层是RPC的第二个关键选择。这一步决定了连接怎么建立、数据怎么流过网络。

很多人会问：我直接用HTTP调不就行了？严格来说，HTTP调用也是一种远程调用，但它跟RPC的定位不同。HTTP/REST更强调资源的语义、无状态、通用性，适合对外提供API；而RPC更强调方法调用的语义、高性能、低延迟，适合内部服务间的密集调用。

具体到传输协议，常见的有两种思路：

• 直接基于TCP：自己定义请求/响应格式，通过Socket传输。TCP是面向连接的，可以建立长连接，避免每次请求都重新握手。Dubbo这类框架就是这样做的。优点是性能高、可控性强，缺点是要自己处理粘包、半包、连接管理这些问题。
• 基于HTTP/2：gRPC就是把这个思路做到极致的代表。HTTP/2支持多路复用、头部压缩、双向流，既能复用HTTP生态的成熟工具链，又能获得接近于TCP的传输效率。

我对这个选择的看法是：不要盲目迷信“TCP一定比HTTP快”。如果是HTTP/1.1，每次请求都要建立和断开连接，光握手开销就够受的，确实拼不过长连接TCP。但HTTP/2把这些问题解决了大半，尤其是在流式传输和跨语言场景下，HTTP/2反而是更省心的选择。关键在于你的团队更熟悉哪套生态，以及你需不需要浏览器、外部客户端也能直接接入。

2.3 服务寻址：怎么找到对方在哪台机器

在只有两台机器、IP固定的时候，客户端直接把IP和端口写死就行。但真实环境里，一个服务往往有几十个实例，它们动态启停、扩容缩容、随时可能挂掉。这时候“服务在哪儿”就变成了一个动态问题，需要注册中心来解决。

注册中心的核心逻辑其实不复杂：服务端启动时把自己的地址（IP+端口）登记到注册中心，并定期发送心跳保活；客户端调用前先去注册中心拉取服务地址列表，本地缓存起来；注册中心发现某个服务节点心跳超时，就把这个节点剔除并通知订阅方更新。

我自己在实践里最大的体会是：注册中心不是一个存储系统，它是一个“状态同步”系统。这决定了你在选型和设计时要考虑CAP的取舍、推送机制、健康检查策略。而且客户端不能完全依赖注册中心的推送，本地缓存和失败重试的兜底机制必须有，否则注册中心一抖动，整条调用链就断了。

2.4 动态代理：让远程调用“隐形”的魔法

前面我说RPC的核心是“透明”，而透明这个效果，很大程度是靠动态代理实现的。

以Java为例，JDK自带的Proxy类可以根据接口动态生成一个实现类。调用方拿到的其实是一个代理对象，这个对象内部并不含真正的业务逻辑，但实现了那个接口。当调用方调用接口方法时，代理对象会拦截这次调用，把方法的信息提取出来，交给RPC客户端去做网络发送。

这就是整个设计的精妙之处：业务代码里调的是接口里的add方法，而代理把“调方法”这件事偷换成了“发请求”。方法名、参数类型、参数值都可以被序列化传出去，服务端用反射去匹配并执行真正的方法。

如果没有动态代理，那调用方就得自己去拼请求包、处理网络收发，代码会非常难受。有了代理，RPC真正做到了“看起来像本地调用”。

3. 动手实操：写一个最小可用的RPC框架

3.1 准备工作与整体结构

下面这个例子我建议你跟着敲一遍，它可能说明不了生产级的全部问题，但能让你把上面说的四个模块串成一条完整的链路。

语言我选了Java，原因有两个：一是Java生态的RPC框架最多，二来JDK自带的动态代理和反射是实现RPC最顺手的工具，不需要引入任何第三方依赖。整个工程我分了三个部分：

• 公共模块：存放接口、请求对象、响应对象。
• 服务端：注册服务、监听端口、反射调用。
• 客户端：动态代理、发送请求、接收结果。

先定义一个服务接口和实现类：

public interface CalculatorService { int add(int a, int b); }

public class CalculatorServiceImpl implements CalculatorService { @Override public int add(int a, int b) { return a + b; } }

3.2 定义RPC协议对象

RPC请求要传给服务端的信息包括：接口名、方法名、参数类型、参数值。还要加上一个请求ID，用来把请求和响应配对，这在异步场景下尤其重要。

public class RpcRequest implements Serializable { private String requestId; private String interfaceName; private String methodName; private Class<?>[] parameterTypes; private Object[] parameters; // 省略 getter/setter }

响应对象则需要携带返回值或者异常：

public class RpcResponse implements Serializable { private String requestId; private Object result; private Throwable error; // 省略 getter/setter }

请求和响应都实现了Serializable，这意味着我要用Java原生序列化。前面吐槽过它不适合生产，但为了把链路跑通，它是最短路径。

3.3 服务端实现

服务端要做的三件事：注册服务、监听端口、处理请求。我写一个简化版本：

public class RpcServer { private final Map<String, Object> serviceMap = new ConcurrentHashMap<>(); private final ExecutorService executor = Executors.newFixedThreadPool(16); public void register(Class<?> interfaceClass, Object impl) { serviceMap.put(interfaceClass.getName(), impl); } public void start(int port) throws IOException { ServerSocket serverSocket = new ServerSocket(port); System.out.println("RPC服务器已启动，端口：" + port); while (true) { Socket socket = serverSocket.accept(); executor.submit(() -> processRequest(socket)); } } private void processRequest(Socket socket) { try (ObjectInputStream in = new ObjectInputStream(socket.getInputStream()); ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream())) { RpcRequest request = (RpcRequest) in.readObject(); RpcResponse response = new RpcResponse(); response.setRequestId(request.getRequestId()); try { Object service = serviceMap.get(request.getInterfaceName()); Method method = service.getClass().getMethod( request.getMethodName(), request.getParameterTypes()); Object result = method.invoke(service, request.getParameters()); response.setResult(result); } catch (Throwable t) { response.setError(t); } out.writeObject(response); out.flush(); } catch (Exception e) { System.err.println("处理请求失败：" + e.getMessage()); } } }

这里有几个点值得展开说。

第一，为什么要用线程池处理请求？如果采用“每来一个连接就开一个线程”的写法，短连接场景下大量线程的创建和销毁会带来巨大的开销，而且线程数一高，CPU全耗在线程切换上。用一个固定线程池可以把并发控制住，避免服务端被突发流量打爆。不过我这个例子用的是线程池而不是NIO，意味着一个线程同时只能处理一个连接，高并发场景下会有瓶颈。生产级的框架这时候会引入Netty这类基于NIO的通信框架，用少量线程处理大量连接。

第二，反射调用这一行是整个服务端的核心。服务注册的时候存的是接口名到实现类的映射，请求来了以后，先用接口名找到实现类，再通过getMethod匹配方法名和参数类型，最后invoke执行。参数类型数组parameterTypes在这里必不可少，因为Java方法重载是靠参数类型区分的，光有方法名可能会撞车。

3.4 客户端动态代理实现

客户端的关键是用JDK动态代理拦截方法调用。我写一个简化版本：

public class RpcClient { @SuppressWarnings("unchecked") public static <T> T getProxy(Class<T> interfaceClass, String host, int port) { return (T) Proxy.newProxyInstance( interfaceClass.getClassLoader(), new Class<?>[]{interfaceClass}, (proxy, method, args) -> { RpcRequest request = new RpcRequest(); request.setRequestId(UUID.randomUUID().toString()); request.setInterfaceName(interfaceClass.getName()); request.setMethodName(method.getName()); request.setParameterTypes(method.getParameterTypes()); request.setParameters(args); // 发送请求并等待响应 RpcResponse response = send(request, host, port); if (response.getError() != null) { throw new RuntimeException(response.getError()); } return response.getResult(); }); } private static RpcResponse send(RpcRequest request, String host, int port) throws Exception { try (Socket socket = new Socket(host, port); ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream()); ObjectInputStream in = new ObjectInputStream(socket.getInputStream())) { out.writeObject(request); out.flush(); return (RpcResponse) in.readObject(); } } }

这里最值得琢磨的就是那行Lambda表达式——它是一个InvocationHandler，每当代理对象有方法被调用，它就会执行。这个方法拿到了method对象，就能取到方法名和参数类型，然后构造一个RpcRequest发给服务端。整个加密、传输、解码的细节全被包在了send方法里。

还有一个细节是interfaceClass.getName()。我用的是接口的全限定类名来做服务标识，服务端注册时也按这个存。派生的关键就在这里：同一个接口在客户端和服务端都在同一个包路径下，名字才能对上。这也解释了为什么很多RPC框架对Provider和Consumer的接口包名有严格约定。

3.5 跑通一次完整调用

写一个Demo类把两端跑起来：

public class RpcDemo { public static void main(String[] args) throws Exception { // 启动服务端（在实际项目中通常是独立启动） RpcServer server = new RpcServer(); server.register(CalculatorService.class, new CalculatorServiceImpl()); server.start(8080); // 客户端调用 CalculatorService calculator = RpcClient.getProxy( CalculatorService.class, "127.0.0.1", 8080); int result = calculator.add(3, 5); System.out.println("调用结果：" + result); } }

先启动服务端，再跑客户端，控制台会输出调用结果：8。整个调用流程经过了：代理拦截、序列化、Socket传输、服务端反射执行、序列化返回、客户端反序列化。一个最小的RPC闭环就跑通了。

我在第一次跑通的时候，那种感觉还是挺奇妙的——你明明调的是一个接口的add方法，真正执行的逻辑却在另一个进程里。这也是我在前文强调的“透明”：业务代码根本感知不到网络的存在。

3.6 这个玩具框架的局限

写完之后我顺手列了一下它跟生产级框架的差距，这些差距其实就是后面要讲的重点：

• 没有注册中心，IP和端口写死，没法做服务发现和动态扩缩容。
• 没有连接池，每次调用都新建Socket，性能很差。
• 没有超时控制，如果服务端卡死，客户端会一直阻塞。
• 没有重试、负载均衡、熔断，任何一个节点挂了，调用就直接失败。
• 用了Java原生序列化，跨语言和性能都不行。
• 线程模型也很初级，高并发下撑不住。

看到这份清单，你大概就能理解为什么生产环境要用成熟的RPC框架了——不是人家炫技，而是那些看似不起眼的能力，每一个都是在真实故障里打磨出来的。

4. 生产环境的坑：超时、重试、连接与并发

4.1 超时为什么必须设置

先讲一个我碰到过多次的场景：线上报警说某个接口响应很慢，一看线程池，线程全部卡在等待远程调用结果上。再一追，下游服务因为数据库连接耗尽，每个请求都要堵几十秒，而上游又没有设置超时时间，于是所有上游线程都被拖死，紧接着上游的依赖方也全被拖死——这就是典型的“故障蔓延”。

RPC调用的超时设置听起来简单，但里面有两个维度的超时要分开看：

• 连接超时：建立TCP连接最多等多久。通常设1到3秒就够，因为内网建连是毫秒级。如果设太长，下游宕机时，你会把大量线程耗在connect上。
• 读超时：连接建立后，等待响应数据返回最多等多久。这个要结合业务耗时和P99延迟来定，不是越大越好。设太大，故障时服务端堆积的请求迟迟不释放；设太小，正常的慢请求会被误杀。

我的经验是：初设时参考历史P99延迟再乘以3到5倍，然后通过压测和线上监控逐步收紧。宁可先放宽一点，也不要一上来就激进导致误杀，等你有足够的延迟数据后再慢慢调优。

4.2 重试不是万能的

超时了怎么办？最常见的动作就是“重试一次”。但重试是个双刃剑，我见过太多因为盲目重试导致的线上事故。

重试最大的风险是重复执行。比如服务端已经执行完扣款逻辑，但在返回响应之前网络断了，客户端收到超时异常后发起重试。如果服务端这个操作不是幂等的，就会扣两次款。这种事情在支付、库存扣减、定时任务补偿这些场景里都是灾难。

所以我对重试的建议是分情况处理：

• 重试连接超时：一般来说连接没建起来，服务端根本不会执行任何操作，这种重试相对安全。
• 重试读超时：非常危险，因为你不知道服务端到底执行完了没有。
• 业务异常不重试：比如参数校验失败、余额不足，重试一万次结果都一样，纯属浪费资源。

如果业务上确实需要重试，那正确姿势是：给请求带上唯一的业务ID，服务端做幂等校验。没有幂等设计，重试就是抱着炸弹跑。

4.3 连接管理和连接池

我在上面的Demo里每次调用都新建一个Socket，这在生产环境是行不通的。建立TCP连接要三次握手，如果每次RPC调用都来一遍，光握手的时间就占了大头，长连接的优势完全发挥不出来。

生产级框架普遍的做法是用连接池：客户端启动时与服务端建立若干个长连接，放进池子里，调用时从池子里借一个连接，用完还回去。池子本身负责连接的创建、存活校验、空闲回收、异常剔除。

连接池的几个关键参数我也列一下，供你配置参考：

• 最大连接数：不是越多越好。连接数太多会导致服务端线程和内存被耗尽，一般根据压测结果定。
• 最小空闲连接数：保证调用低谷时也有可用连接，避免突发流量来了现建连接。
• 空闲超时时间：超过这个时间没使用的连接会被回收关闭。
• 连接最大存活时间：定期替换掉可能已经被服务端单方面关闭的连接，防止“死连接”。

这里面有个很坑的点叫“连接假死”：服务端因为某些原因把连接关闭了，但客户端不知道，下次调用时往一个已经关闭的连接上写数据，会出现奇怪的异常。解决的办法就是连接池里的空闲检测和重连机制，这也是为什么选型时建议优先选成熟的框架，而不是自己土法炼钢。

4.4 服务端的线程模型与并发上限

服务端能支撑多少并发，通常不取决于CPU，而取决于线程模型和IO模型。

我曾经把一个基于“线程每请求”的RPC服务压测到一定QPS就上不去了，瓶颈不是业务代码，而是线程上下文切换和内存占用。后来改成基于NIO的事件驱动模型，同样的机器和代码，QPS翻了好几倍。原因很简单：线程是昂贵的资源，一个8核机器上如果你起几百个线程做纯IO等待，绝大部分都在阻塞，资源利用率是极低的。而NIO用少量Selector线程处理成千上万个连接，只有当数据真正可读写时才分配线程去处理，单位资源的吞吐量高得多。

当然，线程模型的选择也跟业务类型有关。如果你的服务逻辑本身就是CPU密集型，那再好的IO模型也变不出花来。如果你大多数时间都在等待下游响应、等待数据库返回，那IO模型的优化空间就很大。说到底，RPC框架的选型不是越潮越好，得看你的瓶颈到底在哪儿。

4.5 负载均衡、熔断与集群容错

一个服务有多个实例时，客户端怎么选一个节点去调用？这就是负载均衡的事。简单的轮询、加权轮询，复杂的按响应时间动态调整权重、一致性哈希，都是常见策略。但负载均衡做得好，只是保证了“正常情况下”的调度，真正考验容错能力的是节点异常时怎么办。

熔断是这里最值得讲的一个机制。它的思路很朴素：如果某个服务节点连续失败率达到阈值，那客户端就暂时不再把流量打给它，让它“冷静”一段时间，等它恢复后再逐步放量试探。熔断能防止一个半死不活的下游服务把整个调用链路拖垮，是保护“调用方”的，不是保护“被调用方”的。

我遇到过的最经典的一个事故就是：下游服务因为性能下降，很多调用超时，但因为没有熔断，上游还在拼命打流量，结果下游负载越高、响应越慢，成了一个死亡螺旋。后来加上熔断，把故障节点的流量掐掉，整个系统才稳定下来。这个教训让我对“RPC不止是通信框架，更是分布式系统的治理框架”这句话有了切身的理解。

5. 常见问题排查实录

5.1 一条排查思路：先分类，再定位

RPC出问题，是远程调用特有的高发问题区。我自己的排查习惯是先把异常分类，再按类别去找根因，这样最快。

我把常见的RPC异常分成三类：

• 连接类异常：连不上、连接被重置、连接池里借不到连接。这类问题先看网络，再看服务端是否活着。
• 传输类异常：读超时、写超时、粘包拆包错误。这类问题要看两端配置是否一致，数据量是否太大。
• 语义类异常：找不到接口、方法签名不匹配、反序列化失败、版本不一致。这类问题几乎都是两端契约不统一。

定位的时候我主张“从外到内”：先看网络通不通，再看服务端进程在不在，然后看服务端日志里有没有接收到请求，最后看业务线程有没有在跑。很多时候问题根本不在RPC框架本身，而是下游业务逻辑慢、数据库连接泄露这些外围问题。

5.2 典型问题速查表

下面这个表是我这些年积累下来的高频问题清单，直接对照排查：

5.3 两个印象深刻的排查案例

第一个案例是关于序列化版本不一致的。当时一个服务升级了内部类，增加了几个字段，但提供方的发布和调用方的发布没有同步推进。上线后调用方不断抛序列化失败。我刚开始以为是网络问题，排查了半天连包抓了一堆，最后发现是依赖包里两个库的版本对不上。从那以后我养成一个习惯：任何RPC接口的变更，第一件事先检查两端依赖版本是否锁定一致，线上的包必须在发版前对过SHA值。

第二个案例更隐蔽。某个服务接口偶尔超时，单看日志上一片正常，延迟曲线很平稳。直到我把客户端和服务端的耗时日志拉出来对比，才发现服务端实际执行只要几十毫秒，但那段时间网络恰好出现周期性抖动。最后靠的是全链路追踪把客户端发送时间和服务端接收时间对齐，才发现问题出在中间的网络设备上。这个案例给我的教训是：RPC问题不一定在应用层，网络层、内核参数、连接池配置都可能是罪魁祸首。排查的时候不要预设答案，要用链路追踪工具把每个阶段的时间戳都标出来。

6. 写在最后的一点经验

如果你问我在RPC这件事上最大的收获是什么，我会说：一定要亲手写一个最小的实现。哪怕它又丑又简陋，但你只要亲手写过一遍动态代理、反射调用、序列化传输这条链路，再去看Dubbo、gRPC的源码，就不会再觉得它们是黑盒。读完文档你会知道Proxy是在干什么，看到Invoker会明白那个拦截器在做什么，遇到超时配置也不会再瞎猜参数含义。

最后再分享一个小技巧：遇到RPC问题别急着改配置，先接上链路追踪和Metrics监控，把调用链路上每个节点的耗时、成功率、连接数这些基础数据沉淀下来。这些数据积累得越多，下次排查问题时的方向就越清晰。RPC要学的不仅是一套协议和框架，更是一套面对分布式系统故障的思维方式——连接、调度、容错、稳定性，每个词背后的坑，都是值得花时间亲自踩一遍的。