优雅のJava（四）—— 优雅的理解代理模式

文章目录

专栏导航
前言代理静态代理 RPC
静态代理 VS 装饰器 VS AOP
动态代理 VS 静态代理
RPC调用的例子
Why not Http?
动态代理实现AOP
JDK动态代理 VS CGLib动态代理字节码增强
后记思维 VS 实现
- RPC概念

专栏导航

优雅のJava（零）—— 面向问题的学习

前言代理静态代理 RPC

文如其名代理模式就是代理屏蔽细节客户用起来感觉是一样的
类似之前的客户只负责指定标准接口输入参数你怎么返回我不管我用起来感觉一样就行辣

静态代理的实现本身没啥技术你直接把要代理的实例对象引用过来 调用它的方法就行啦

比如本来是远程调用别人服务器的Hello方法然后回显数据客户可不想看到那些远程连接的一大堆代码于是我们需要实现客户只是这么调用Stub.hello(); 就能看到回显数据了那怎么办？Stub就是我们的代理类 这个名字是约定俗成的

这种远程调用也被称为RPC Remote Procedure Call 远程过程（过程：一段程序就叫过程）调用那其实平常我们调用函数就是“本地过程调用（我就叫他LPC）”咯

客户就想 RPC底层我不想看到我想使用起来好像本地调用一个函数一样简单这就是RPC的代理

静态代理 VS 装饰器 VS AOP

其实实现的套路接近都是拉别人的实例对象进来加东西（不加也行就套个壳那或许变成适配器模式了。。）

只不过装饰器侧重点在装饰所以是基于原来的做增强或者说添加特性 这样符合“合成”的思想而不是继承的思想

但是代理则是尽量和被代理对象同规范 因为客户指定的规范客户需要你这样和他对接所以侧重点是代理

现在代理往往都是往动态代理 转而往AOP增强的思路前进那自然必定也有增强但不是象装饰器那种装饰一层添加一个特性而是只是为了代理而增强功能而已

虽然两种都能达到一样的效果可能但是思维不同

动态代理 VS 静态代理

扯了这么多动态代理那为啥需要动态代理原来那个不够嘛？拉进来被代理实例前后做些操作就完事了啊

试想假设对面服务器上几百个组件类及其方法调用你得创造多少代理类啊。。。还有他们的方法等毕竟要遵守同一个规范来着这不折磨

更加折磨的是如果有个组件的某个方法改了名字那代码不符合开闭原则你将会在一堆代码里边修修补补最后迷失自己

其实我们可以发现静态代理很多重复的东西如果我们能够动态的生成类和被代理的类同一个规范那不是完事了吗？这就是所谓动态的代理

RPC调用的例子

我们看个简单的RPC调用的例子
首先我们的客户端使用起来还是很快乐我们远程的服务规范是UserService接口然后举例子使用的方法是findUserById

public class Client{public static main(String[] args) throws exception {IUserService service = Stub.getStub();sout(service.findUserById(123));}
}

那我们这个stub应该怎么动态代理法？我们先使用jdk原生的动态代理 也就是熟悉的invoke Proxy.newProxyInstance那一套

public class stub{public static UserService getStub(){// 匿名内部类写好Handler 配置好 要生成的动态类的信息InvocationHandler h = new InvocationHandler() {@Override public Object invoke(Object proxy, Method method, Object[] args) throws ThrowableException{Socket s = new Socket("127.0.0.1", 8888);ObjectOutputStream oos = new ObjectOutputStream(s.getOutputStream());oos.writeUTF(method.getName());oos.writeObject(method.getParameterTypes());oos.writeObject(args);oos.flush();}};Object o = Proxy.newProxyInstance(UserService.class.getClassLoader(), ... )return (UserService) o;}
}

这里 invoke里边就是远程通信的具体细节然后再使用newProxyInstance的方法获取代理生成的对象然后返回給客户使用
这里这个本地的 getStub返回的对象代理了远程服务器那个提供服务的对象（你可以这么理解）

当然了服务器那边其实就需要解析了解析出来反射一个对象执行然后返回结果即可

public class Skeleton{private static void process() throws Exception{Socket s = new Socket("127.0.0.1", 8888);InputStream in = s.getInputStream();OutputStream out = s.getOutputStram();ObjectInputStream oos = new ObjectInputStream(in);DataOutputStream dos = new DataOutputStream(out);// 开始解包 解出来name 接口参数等等String methodName = oos.readUTF();Class[] parameterTypes = (Class[])oos.readObject();Object[] args = (Object[]）oos.readObject();UserService service = new UserServiceImpl();// 反射 获取方法Method method = service.getClass().getMethod(methodName, parameterTypes);// 调用 获取结果User user = (User)method.invoke(service, args);// ... 利用结果做什么 返回给client 比如说dos.writeInt(user.getId());dos.writeInt(user.getName());dos.flush();}
}

Why not Http?

这个问题其实很简单按理来说我们实际上把需要的对象对象的方法以及执行需要的参数传过去然后对面返回一个JSON结果就好了啊没啥东西就是普通的Http请求然后controller回复就完事儿。。。

所以那个时候客户端可以这么调用：

 public class Client{public static main(String[] args) throws exception {IUserService service = Stub.getStub();sout(service.RPC("findUserById", 123)); // 举例 当然参数的封装自然用些复杂数据结构 更具有兼容性}}

确实！而且这个和动态代理无关其实我们invoke方法也可以这样来只不过是接口规范改变了

注意代理的关键是同一个规范那自然原来那种就好像调用本地对象本地方法的思路更符合代理模式的精髓

动态代理实现AOP

实际上技术层面而言动态代理比较关键的是能够实现AOP增强的代理！

之前RPC的那个远程服务的代理没有增强只是屏蔽了底层细节

 public Object creatProxy() {// ...InvocationHandler invocationHandler = new InvocationHandler() {@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {beforeAdvice.before(); // 前置增强Object result = method.invoke(targetObject, args);//调用目标对象的目标方法afterAdvice.after(); // 后置增强return result;}};Object proxyObject = Proxy.newProxyInstance(classLoader, interfaces, invocationHandler);return proxyObject; // 返回增前的代理对象}

这里我们在原有的被代理对象前后加了东西这才是前置后置增强用AOP的思想来说就是织入

而这么做的好处是比如实现所有方法的前后打印日志你动态代理所有的对象給每个组件对象来个AOP增强不就成了？

JDK动态代理 VS CGLib动态代理字节码增强

首先各位不要小看了的动态代理以为这玩意也就是类似静态代理一样前置引用执行结果后置完事

关键一点在于静态代理只是代理一段过程首先被代理的对象存在然后静态代理用个所谓代理对象的方法调用被代理的对象完成套壳的操作但是动态代理被代理的对象压根就没出来过！

它是通过织入字节码的方式我们任何类方法 本质都是字节码 我往里边改改不就完事了吗：）改完再用对应的classLoader 类加载器就能实现运行的时候产生新的类而不是只能程序一启动那个时候加载类

这种技术统称字节码增强技术只是JDK和CGLib的思路有所不同

JDK动态代理专注于同一种规范所以要求提供被代理类的

接口
类加载器

如果被代理类没有接口那根本操作不了如果有那我可以用反射套出来这个类里边有啥方法方法参数属性等等然后增强等同于造一个新的类一个符合同一规范的类然后用类加载器加载出来你可以发现代理类往往叫“$proxy-序号” 序号只是为了造出来的类不重名罢了

而CGLib动态代理 使用的是子类继承父类从而获取到被代理（父类）的信息再继承增强其功能的所以出来的类就是被代理类的子类哈哈

实际中两种方法并列 Spring源码里边有以下片段

可以发现使用哪个有三个条件

第一配置 config写啥就是啥
第二通过这个注解（标记）这个属性配置的

在 createAopProxy方法里边根据这个条件选择使用哪个
第三个条件就是 hasNoUserSuppliedProxyInterfaces
即 bean组件如果有接口 使用JDK 字节码增强技术 $proxy
没接口使用CGLib

所以看情况使用但是核心不变代理增强动态的造类运动

后记思维 VS 实现

这篇其实技术讲的尽量少了关键是思维

其实你说技术上静态代理和装饰器区别有吗没有啊关键不是实现的技术而是思路为什么要代理什么是所谓代理而什么又是“装饰” 装饰可以叠加可以像前端那种mixin 代理只能是代理原有的

RPC概念

同样的道理 RPC框架的使用上有人提问为啥不使用HTTP？问的人可能太专注与技术本身而没有管思维 RPC调用是种思维不是技术具体实现的方式他只是接口就类似代理模式这个概念一样。

RPC当然可以使用HTTP技术来实现你制定好访问的接口传递参数的数据格式有什么不可以的呢？你甚至可以使用TCP UDP实现。。。之所以使用各种各样的所谓RPC框架那是因为他们框架包含更好的序列化技术实现信息传输的技术实现

RPC框架的实现依赖两步序列化和网络信息传输

序列化用java自带的serializable自然是效率底下的替代方案JSON传输速度一般不适用于分布式高效的数据传输而Thrift | Hessian | ProtoBuf 这些就符合要求
传输层面 HTTP1.1问题很大使用HTTP2.0就很舒服

我们著名的gRPC 其实是结合了HTTP2.0 和 Protobuf 所以gRPC的优点也主要是后面两个大哥提供的

所以思维是关键怎么实现又是另外一回事不能混为一谈

专栏
优雅のJava（零）—— 面向问题的学习