设计模式之代理模式（Proxy Pattern）_远程代理解析

时间：2024-03-05 18:15:55

一.什么是代理模式？

顾名思义，代理就是第三方，比如明星的经纪人，明星的事务都交给经纪人来处理，明星只要告诉经纪人去做什么，经纪人自然会想办法去做，做完之后再把结果告诉明星就好了

本来是调用者与被调用者之间的直接交互，现在把调用者与被调用者分离开，由代理负责传递信息来完成调用

二.代理模式有什么用？

代理模式是一个很大的模式，所以应用很广泛，从代理的种类就能看出来了：

远程代理：最经典的代理模式之一，远程代理负责与远程JVM通信，以实现本地调用者与远程被调用者之间的正常交互

虚拟代理：用来代替巨大对象，确保它在需要的时候才被创建

保护代理：给被调用者提供访问控制，确认调用者的权限

此外还有防火墙代理，智能引用代理，缓存代理，同步代理，复杂隐藏代理，写入时复制代理等等，都有各自特殊的用途

P.S.远程代理是最基础的代理模式，有必要单独拿出来说说，所以本文对其作以详细解释，其余代理会在补充的博文中详述

三.远程代理

有些事情不用代理也能轻松解决，但有些事情必须得依靠代理来完成，比如要调用另一台机器上的一个方法，我们可能就不得不用代理

远程代理的内部机制是这样的：

解释一下，Stub是“桩”也有人称之为“存根”，代表了Server对象

Skeleton是“骨架”（不知道为什么叫“桩”和“骨架”，当然，也没必要知道），代表了Client

Stub明明在客户那边，为什么不是客户的代理而是服务的代理？因为客户是要与服务器交互，现在服务在远程JVM中，无法交互，所以用Stub来代表Server，调用Stub就等同于调用Server（内部通信机制对Client透明，对Client来说，调用Stub和直接调用Server没什么区别，而这正是代理模式的优点之一）

具体流程是这样的：

  1. Client向Stub发送方法调用请求（Client以为Stub就是Server）
  2. Stub接到请求，通过Socket与服务端的Skeleton通信，把调用请求传递给Skeleton
  3. Skeleton接到请求，调用本地Server（听起来有点奇怪，这里Server相当于Service）
  4. Server作出对应动作，把结果返回给调用者Skeleton
  5. Skeleton接到结果之后通过Socket发送给Stub
  6. Stub把结果传递给Client

P.S.第2步与第5步都需要通过Socket通信，相互传递的东西都必须在发送前序列化，接收后反序列化，这也就解释了为什么Server中的public方法返回值都必须是可序列化的

四.远程代理的实现

有两种方式可以实现远程代理：

  • 自定义Stub与Skeleton（实现其内部通信）
  • 利用Java支持的RMI（Remote Method Invocation）来实现，可以省去很多麻烦，但不容易弄明白内部原理

首先给出自定义方式的例子，有一篇关于这个的博文很不错，就擅自记录下了链接，点我跳转>>

原文给出了一个完整的例子，因此这里不再赘述，给原文补充一个伪类图，方便理解：

（不要问我类图为什么这么画，说了是“伪”类图。。）

仔细看看原文的话不难理解远程代理，Stub和Skeleton负责通信，类似于用Socket编写的聊天程序，除此之外没什么特别的

-------

下面给出利用Java支持的RMI来实现代理模式，能够明显的感受到隐藏了很多细节

 首先要定义远程接口：

package ProxyPattern;

import java.rmi.RemoteException;

/**
 * 定义服务接口（扩展自java.rmi.Remote接口）
 * @author ayqy
 */
public interface Service extends java.rmi.Remote{
	/* 1.方法返回类型必须是可序列化的Serializable
	 * 2.每一个方法都要声明异常throws RemoteException（因为是RMI方式）
	 * */
	
	
	/**
	 * @return 完整的问候语句
	 * @throws RemoteException
	 */
	public String greet(String name) throws RemoteException;
}

注意：服务接口中public方法的返回类型必须是可序列化的（换言之，自定义的返回类型必须实现Serializable接口），而String类型已经实现了Serializable接口

为什么要定义这样一个扩展自java.rmi.Remote的接口？API文档中给出了清晰的解释：

The Remote interface serves to identify interfaces whose methods may be invoked from a non-local virtual machine. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a "remote interface", an interface that extends java.rmi.Remote are available remotely. 

说白了就是为了告诉编译器：我们的Service对象可以被远程调用，仅此而已

-------

定义好了远程接口，当然还需要一个具体实现：

package ProxyPattern;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

/**
 * 实现远程服务（扩展自UnicastRemoteObject并实现自定义远程接口）
 * @author ayqy
 */
public class MyService extends UnicastRemoteObject implements Service{

	/**
	 * 用来校验程序版本（接收端在反序列化是会验证UID，不符则引发异常）
	 */
	private static final long serialVersionUID = 1L;

	/**
	 * 空的构造方法，只是为了声明异常（默认的构造方法不会声明异常）
	 * @throws RemoteException
	 */
	protected MyService() throws RemoteException {
	}

	@Override
	public String greet(String name) throws RemoteException {
		return "Hey, " + name;
	}
}

P.S.服务继承UnicastRemoteObject类是为了自动生成Stub类（UnicastRemoteObject封装了具体生成细节，我们省去了一个类的工作量）

-------

服务端有了服务还不够，我们需要一个Server帮助我们启动RMI注册服务，并注册远程对象，供客户端调用：

package ProxyPattern;

import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;

/**
 * 实现服务器类，负责开启服务并注册服务对象
 * @author ayqy
 */
public class Server {
	public static void main(String[] args){
		try {
			//启动RMI注册服务，指定端口为1099　（1099为默认端口）
			LocateRegistry.createRegistry(1099);
			//创建服务对象
			MyService service = new MyService();
			//把service注册到RMI注册服务器上，命名为MyService
			Naming.rebind("MyService", service);
		} catch (RemoteException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (MalformedURLException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
}

注意，除了使用LocateRegistry.createRegistry()方式开启服务外，还可以用命令行方式开启（rmiregistry命令），效果一样

服务端代码到这里就完成了，就像Socket聊天程序一样，我们需要写两部分代码，Server与Client

-------

下面开始做客户端的实现，非常简单，就像一个测试类：

package ProxyPattern;

/* 参考资料:
 * 1.JAVA RMI怎么用
 * http://blog.csdn.net/afterrain/article/details/1819659
 * 2.RMI内部原理
 * http://www.cnblogs.com/yin-jingyu/archive/2012/06/14/2549361.html
 * */
import java.rmi.Naming;

/**
 * 实现客户类
 * @author ayqy
 */
public class Client {
	/**
	 * 查找远程对象并调用远程方法
	 */
	public static void main(String[] argv)
	{
		try
		{
			//如果要从另一台启动了RMI注册服务的机器上查找MyService对象，修改IP地址即可
			Service service = (Service) Naming.lookup("//127.0.0.1:1099/MyService");

			//调用远程方法
			System.out.println(service.greet("SmileStone"));
		}
		catch (Exception e)
		{
			System.out.println("Client exception: " + e);
		}
	}
}

P.S.我们直接用Naming.lookup()来获取Stub对象（没错，是Stub，真正的对象还在另一台机器上呢，当然拿不到，这里得到的只是Service的Stub代理），再调用代理的方法获取结果

注意这个细节：

//如果要从另一台启动了RMI注册服务的机器上查找MyService对象，修改IP地址即可
Service service = (Service) Naming.lookup("//127.0.0.1:1099/MyService");

虽然只是一句话，但隐藏了两个细节：

  1. 客户端必须知道服务接口Service，这里由于是在本地同一个package下，所以不用关心，在真正应用中Client与Server是分离的，所以Client需要拿到一份Service接口的Copy，否则无法调用
  2. 客户端必须知道服务器的IP和端口号（通信嘛，没有这个可不行）

-------

忙活了半天了，看看运行结果（先运行Server，再运行Client）：

P.S.利用Java支持的RMI来实现远程代理部分，参考的资料是别人的一篇博文，里面解释的更详细一些

P.S.至于命令行方式启动RMI注册服务，太麻烦了，而且需要先生成Stub类，不建议用这种方式，具体操作细节，上面的链接博文中也有详细介绍，不再赘述

注意：直到我们亲眼看到测试结果为止，始终没有自定义Stub与Skeleton类，不是吗？对，没错，它们确实存在，只是被RMI隐藏起来了（据说Java1.5之后RMI中没有了Skeleton，甚至更高的版本中连Stub都没有了。。不过这都没关系，我们已经清楚了最原始的远程代理）

五.总结

回过头去想一想远程代理做了些什么：

  1. 拦截并控制方法调用（这也是代理模式最大的特点，最典型的，防火墙代理。。）
  2. 远程对象的存在对客户是透明的（客户完全把Stub代理对象当做远程对象了，虽然客户有点好奇为什么可能会出现异常。。）
  3. 远程代理隐藏了通信细节

当我们需要调用另一台机器（JVM）上指定对象的方法时，使用远程代理是一个不错的选择。。

相关文章