java微服务rpc中方法被“伪装”成本地调用的核心是动态代理：启动时扫描注解生成代理对象，调用时拦截方法并封装为网络请求，经序列化、服务发现、网络传输、反序列化后返回结果，全程对业务透明。
Java 方法在微服务 RPC 框架中被“伪装”成本地调用，实际发出网络请求，核心靠的是动态代理 + 服务注册发现 + 序列化 + 网络通信。这不是编译期 magic，而是运行时拦截 + 封装转发。
动态代理生成“假本地接口实现”
RPC 框架（如 Dubbo、gRPC-Java、Spring Cloud Alibaba）会在启动时扫描 @DubboService、@GrpcService 或 @FeignClient 注解，为远程接口生成一个代理对象。这个对象不是你写的实现类，而是 JDK Proxy 或 Javassist/CGLIB 动态生成的字节码。
- 你写：
OrderService orderService = context.getBean(OrderService.class);，然后调用orderService.createOrder(...) - 实际执行的不是你本地的实现，而是代理对象的
invoke()方法 - 代理内部不执行业务逻辑，而是提取方法名、参数类型、参数值，组装成 RPC 请求体
把方法调用转成可传输的请求数据
代理拿到反射信息后，要让远端能理解并执行，必须标准化请求内容：
-
服务标识：接口全限定名（如
com.example.OrderService）+ 方法名（createOrder）+ 版本/分组（用于灰度或兼容） - 参数序列化：用 Hessian、JSON、Protobuf 等把 Java 对象转成二进制或文本。Dubbo 默认 Hessian2，gRPC 强制 Protobuf
- 元数据附加：透传 traceId、tenantId、超时时间等，通常放在 attachment 或自定义 header 中
找服务、发请求、收响应
有了请求数据，还得知道往哪发、怎么发：
- 服务寻址：查注册中心（ZooKeeper/Nacos/Consul），根据接口名拉取可用 provider 地址列表，再通过负载均衡策略（随机、轮询、一致性哈希）选一台
- 网络调用：用 Netty（Dubbo/gRPC）、OkHttp（OpenFeign）建立长连接，把序列化后的请求体发过去；支持同步等待、异步回调、CompletableFuture
- 结果反序列化：收到响应 byte[] 后，按约定协议反序列化成返回值对象，再包装成 Future 或直接返回 —— 对调用方完全透明
异常与超时如何“本地化”表现
网络问题不能暴露为 IOException 给上层业务，否则破坏 RPC 透明性：
- 超时触发时，代理主动抛出
RpcTimeoutException（Dubbo）或StatusRuntimeException（gRPC），语义接近本地方法超时 - 服务不可用、序列化失败等，统一包装为运行时异常（如
RpcException），避免强制 try-catch 检查异常 - 重试机制也由代理层完成（默认 2 次），业务代码无感知
整个过程对开发者来说就是写个接口、加个注解、注入使用 —— 代理、序列化、寻址、通信全部框架内闭环。真正关键的是协议设计是否统一、序列化是否高效、注册中心是否可靠、代理拦截是否无损。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
