在国企干了 年 Java，居然不知道 RPC？这正常吗？
在国企干了 5 年 Java，居然不知道 RPC？这正常吗？
最近在技术社群里看到一个帖子，一位在国企工作了 5 年的 Java 开发者坦言自己完全不了解 RPC。评论区瞬间炸开了锅，有人嘲讽这是“养老式编程”，也有人表示理解：“国企项目大多是单体架构，RPC 用不上很正常。”那么，这个问题背后究竟反映了什么技术认知差异？RPC 真的离我们很远吗？今天我们从原理到代码，彻底拆解 RPC 的底层逻辑。## 一、RPC 的本质：让远程调用像本地调用一样简单RPC（Remote Procedure Call，远程过程调用）的核心思想是：让程序员调用远程服务的方法时，感觉就像调用本地方法一样自然。这句话听起来简单，但实现起来需要解决三个关键问题：1.网络通信：如何将方法名、参数传输到远程服务器？2.序列化：内存中的 Java 对象如何变成能在网络上传输的字节流？3.服务发现：如何知道远程服务在哪里？我们先来看一个最原始的远程调用方式——通过 Socket 直接传输字符串。这段代码展示了没有 RPC 框架时，你需要手动处理的细节：javaimport java.io.*;import java.net.*;public class RawRemoteCall { // 模拟远程调用的客户端 public static void main(String[] args) throws Exception { // 1. 创建Socket连接 try (Socket socket = new Socket("192.168.1.100", 8080); BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter out = new PrintWriter(socket.getOutputStream(), true)) { // 2. 手动构建调用请求（方法名+参数） String request = "getUserById:123"; out.println(request); // 3. 手动解析响应 String response = in.readLine(); System.out.println("调用结果：" + response); } }}这段代码的问题显而易见：你需要自己处理网络异常、数据格式、连接管理。当系统有几十个远程服务时，这种“手工造轮子”的方式会让代码变得异常臃肿。## 二、RPC 框架的演进：从 Stub 到动态代理现代 RPC 框架（如 Dubbo、gRPC）通过动态代理技术解决了上述痛点。它的工作原理是：1.客户端代理：生成一个接口的本地代理对象2.透明调用：开发者调用代理对象的方法时，代理负责序列化、网络传输3.服务端代理：接收请求后反序列化，调用真实实现下面是一个简化版的 RPC 客户端代理实现，用 Java 动态代理模拟这个过程：javaimport java.lang.reflect.InvocationHandler;import java.lang.reflect.Method;import java.lang.reflect.Proxy;import java.io.*;// 定义服务接口interface UserService { String getUserById(int id);}// 模拟的远程调用处理器class RpcInvocationHandler implements InvocationHandler { private String host; private int port; public RpcInvocationHandler(String host, int port) { this.host = host; this.port = port; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 构造请求：方法名 + 参数序列化（简化版使用JSON） String request = method.getName() + ":" + args[0]; System.out.println("[客户端代理] 发送请求: " + request); // 2. 模拟网络传输（实际应使用Socket） // 这里假设服务端返回固定结果 String response = "User{id=123, name='张三'}"; System.out.println("[客户端代理] 收到响应: " + response); return response; }}public class RpcClientDemo { public static void main(String[] args) { // 通过动态代理创建UserService的本地代理 UserService proxy = (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, new RpcInvocationHandler("192.168.1.100", 8080) ); // 调用时完全感觉不到远程调用的存在 String result = proxy.getUserById(123); System.out.println("调用结果: " + result); }}运行这段代码，你会看到输出：[客户端代理] 发送请求: getUserById:123[客户端代理] 收到响应: User{id=123, name='张三'}调用结果: User{id=123, name='张三'}## 三、RPC 与微服务架构的深度绑定在国企项目中，很多系统仍然是“大单体”架构——一个 WAR 包部署到 Tomcat 上，所有逻辑都在同一个 JVM 进程内。这种情况下，方法调用直接通过 JVM 栈帧完成，确实不需要 RPC。但现代互联网架构中，微服务化几乎是必然趋势。假设一个电商系统被拆分为：订单服务、库存服务、用户服务，它们部署在不同服务器上。这时，服务间通信必须通过 RPC 或 HTTP 调用。RPC 的优势在于：-高性能：使用 TCP 长连接，二进制序列化（如 Protobuf）比 HTTP 的 JSON 格式更高效-强类型：接口定义清晰，IDE 自动补全，编译期检查错误-服务治理：负载均衡、熔断降级、链路追踪等能力## 四、为什么国企 Java 开发者容易忽视 RPC？这不是技术能力问题，而是业务场景决定技术栈。国企项目的典型特征：1.业务稳定：核心系统可能用 Java 6/7 编写，十年不重构2.流量可控：日均几万请求，单机 Tomcat 完全扛得住3.安全合规：不允许引入未经信创认证的开源组件4.组织隔离：不同部门系统通过数据库共享数据，而非接口调用但问题在于：技术视野的局限会限制职业发展。如果你只会写 CRUD 和 SQL，遇到系统拆分时就会手足无措。## 五、从 RPC 到分布式系统的必修课理解 RPC 只是第一步，真正掌握分布式系统还需要：-序列化协议：JSON、Protobuf、Hessian 的性能差异-网络模型：BIO/NIO/AIO 的区别（Netty 的 Reactor 模式）-服务发现：Zookeeper、Nacos、Consul 的选型对比-负载均衡：随机、轮询、一致性哈希的实现原理实战建议：下载 Dubbo 源码，从ReferenceConfig类开始分析动态代理的创建过程。或者用 gRPC 编写一个简单的 Hello World 服务，感受 Protobuf 的编译流程。## 总结在国企工作 5 年不知道 RPC，完全正常，但绝非理所当然。正常是因为业务场景可能不需要；不正常是因为技术人应该保持对行业主流技术的敏感度。RPC 不是高深莫测的概念，它只是分布式系统的基础设施。就像你不会因为每天用电灯就要求理解发电厂原理一样，但如果你是一名电工，不懂交流电和变压器的区别，那就说不过去了。技术人的核心竞争力，从来不在于你用过多少框架，而在于你能否在任何场景下，快速理解并解决新问题。如果你现在开始学习 RPC，一周时间就能写出一个简单的 DEMO。关键是——你愿意开始吗？