在国企干了 5 年 Java居然不知道 RPC这正常吗最近在技术社群里看到一个帖子一位在国企工作了 5 年的 Java 开发者坦言自己完全不了解 RPC。评论区瞬间炸开了锅有人嘲讽这是“养老式编程”也有人表示理解“国企项目大多是单体架构RPC 用不上很正常。”那么这个问题背后究竟反映了什么技术认知差异RPC 真的离我们很远吗今天我们从原理到代码彻底拆解 RPC 的底层逻辑。## 一、RPC 的本质让远程调用像本地调用一样简单RPCRemote 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{id123, 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{id123, name张三}调用结果: User{id123, 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。关键是——你愿意开始吗
在国企干了 年 Java，居然不知道 RPC？这正常吗？
在国企干了 5 年 Java居然不知道 RPC这正常吗最近在技术社群里看到一个帖子一位在国企工作了 5 年的 Java 开发者坦言自己完全不了解 RPC。评论区瞬间炸开了锅有人嘲讽这是“养老式编程”也有人表示理解“国企项目大多是单体架构RPC 用不上很正常。”那么这个问题背后究竟反映了什么技术认知差异RPC 真的离我们很远吗今天我们从原理到代码彻底拆解 RPC 的底层逻辑。## 一、RPC 的本质让远程调用像本地调用一样简单RPCRemote 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{id123, 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{id123, name张三}调用结果: User{id123, 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。关键是——你愿意开始吗
