动态代理在 RPC 框架中起什么作用？

简化版

动态代理是 RPC 实现「像调用本地方法一样调用远程服务」的关键。RPC 框架给客户端的服务接口生成一个代理对象，你调用这个代理的方法时，代理拦截这次调用，在内部把「接口名、方法名、参数」封装成请求、序列化、走网络发给服务端、拿回结果——这一整套远程调用逻辑都被藏在代理里，对调用者完全透明。没有动态代理，就得手写这些网络通信代码。Java 实现动态代理主要有 JDK 动态代理（基于接口） 和 CGLIB（基于继承子类） 两种。

详细版

动态代理在 RPC 中的作用：

屏蔽远程调用细节：把序列化、网络传输、结果解析封装在代理里，调用者感知不到。
实现「本地调用」的假象：调用者拿到的是接口类型的代理对象，用法和本地对象一模一样。
统一织入通用逻辑：在代理里可以统一加超时、重试、负载均衡、监控等。

JDK 动态代理 vs CGLIB：

维度	JDK 动态代理	CGLIB
基础	基于接口（实现接口）	基于继承（生成子类）
要求	目标类必须有接口	目标类不能是 final
实现	`Proxy` + `InvocationHandler`	字节码生成子类，覆盖方法
性能	反射调用	生成子类，调用较快

RPC 里常用 JDK 动态代理（因为 RPC 都是面向接口的），示意：

UserService proxy = (UserService) Proxy.newProxyInstance(
    classLoader,
    new Class[]{UserService.class},
    (proxyObj, method, args) -> {
        // 拦截所有方法调用，转成远程调用
        RpcRequest request = new RpcRequest(method.getName(), args, ...);
        return rpcClient.send(request);   // 序列化 + 网络发送 + 拿结果
    }
);
proxy.getUser(1);   // 看似本地调用，实则远程

完整版教学

一、没有动态代理会怎样

先想象没有动态代理的 RPC 调用会有多繁琐。如果要调用远程的 userService.getUser(1)，你得手写：

// 手动构造请求、序列化、建连接、发送、接收、反序列化...
RpcRequest req = new RpcRequest("UserService", "getUser", new Object[]{1});
byte[] data = serialize(req);
Socket socket = new Socket(host, port);
socket.getOutputStream().write(data);
byte[] respData = readResponse(socket);
User user = (User) deserialize(respData);

每调一个远程方法都要写这一大堆网络通信代码，繁琐且到处重复。动态代理的作用就是把这些全部封装起来，让你只写 userService.getUser(1)——像调本地方法一样。

二、动态代理如何实现「透明的远程调用」

RPC 框架给服务接口（如 UserService）动态生成一个代理对象。这个代理对象实现了 UserService 接口，所以类型上就是 UserService，你可以像用本地实现一样用它。但它的方法实现不是真正的业务逻辑，而是：

拦截你的每一次方法调用；
从调用中拿到方法名、参数；
把它们连同接口名封装成一个 RPC 请求；
序列化 + 通过网络发给服务端；
等服务端执行完返回，反序列化结果；
把结果作为方法返回值返回给你。

这一整套「远程调用的脏活」全部藏在代理的方法实现里。对你（调用者）而言，你只是调了个接口方法、拿到了返回值，完全感知不到中间的网络通信——这就是「透明化」，动态代理是它的核心实现手段。

三、JDK 动态代理：基于接口

Java 实现动态代理最常用 JDK 动态代理，它基于接口：

核心是 java.lang.reflect.Proxy 和 InvocationHandler 接口。
Proxy.newProxyInstance(classLoader, interfaces, handler) 在运行时动态生成一个实现了指定接口的代理类。
代理对象的所有方法调用都会转到 InvocationHandler.invoke(proxy, method, args) 方法——你在这个 invoke 里写「转成远程调用」的逻辑。

RPC 框架天然面向接口（服务都是接口 + 实现），所以 JDK 动态代理是 RPC 的常用选择。上面详细版的代码就是典型：在 invoke 里把方法调用封装成 RpcRequest 发出去。

四、CGLIB：基于继承（子类）

CGLIB 是另一种动态代理方式，基于继承：

它通过生成目标类的子类（用字节码技术 ASM），在子类里覆盖父类方法来插入代理逻辑。
不要求目标类有接口（JDK 代理必须有接口），可以直接代理普通类。
但不能代理 final 类/final 方法（final 不能被继承/覆盖）。

JDK 代理 vs CGLIB：

JDK 代理基于接口（目标必须实现接口），CGLIB 基于继承（生成子类，无需接口）。
RPC 里服务都是接口，所以常用 JDK 动态代理；而像 Spring AOP，会根据目标有没有接口自动选择（有接口用 JDK、没接口用 CGLIB）。

五、动态代理还能织入通用逻辑

动态代理不只是「转发远程调用」，它是一个统一的拦截点，可以在这里织入各种通用逻辑（类似 AOP）：

负载均衡：在代理里从多个 Provider 地址选一个。
超时控制、重试、容错：在代理里包裹超时和失败重试逻辑。
监控埋点：记录调用次数、耗时。
参数校验、日志等。

所以 RPC 框架的代理层是很多治理能力的落地点——所有调用都经过代理，就能在这里统一加控制。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「RPC 动态代理」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着远程调用链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	动态代理负责制造本地接口对象，把方法调用拦截后转成远程请求	不要停在名词解释
流程机制	创建接口代理对象 -> 调用方法被 InvocationHandler 拦截 -> 封装服务名方法名参数 -> 发起网络调用 -> 反序列化结果并返回	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	调用 userService.getUser(1) 时，代理拿到 interface、method、args 三类信息并封装为请求	RPC 让调用写法像本地方法，但失败语义、网络延迟和版本兼容必须按远程系统处理

RPC 动态代理 面试拆解：
1. 创建接口代理对象
2. 调用方法被 InvocationHandler 拦截
3. 封装服务名方法名参数
4. 发起网络调用
5. 反序列化结果并返回

记忆钩子：先拆代理、序列化、传输、寻址、容错，再说明超时、重试、幂等这些工程边界；回答时一定要落到题目中的「RPC 动态代理」，不要把相邻中间件的能力混着讲。

误区：动态代理会在本地执行真实业务。 客户端代理只封装远程请求，真实业务在服务端实现类执行。
误区：RPC 必须用 JDK 动态代理。 JDK 代理适合接口，CGLIB、ByteBuddy 或代码生成也能实现代理。
误区：代理层不需要处理异常。 代理必须把网络异常、超时、业务异常区分包装，否则调用方无法正确处理。
追问：为什么代理能让调用透明？ 因为调用方拿到的是接口类型对象，方法调用被框架拦截并转换成远程调用。
追问：代理需要哪些元数据？ 接口名、方法名、参数类型、参数值、版本、分组和超时配置。
追问：动态代理的性能问题怎么处理？ 可缓存代理、使用生成字节码或方法句柄，避免每次反射查找。

七、加强记忆

动态代理是 RPC 实现「像调本地方法一样调远程服务」（透明化）的关键。RPC 给服务接口动态生成代理对象（实现该接口），你调它的方法时，代理拦截调用 → 拿到方法名和参数 → 封装成 RPC 请求 → 序列化 + 网络发送 → 反序列化结果返回，把所有远程通信细节藏在代理里，调用者无感知。Java 两种方式：JDK 动态代理（基于接口，Proxy+InvocationHandler，目标须有接口）——RPC 常用；CGLIB（基于继承生成子类，无需接口但不能代理 final）。代理层还是织入负载均衡、超时重试、监控等通用逻辑的统一拦截点。口诀：代理拦截方法调用、封装成请求走网络、藏起细节造本地假象。

简化版

详细版