架构设计:系统间通信(9)——通信管理与RMI 下篇

接上文《架构设计:系统间通信(8)——通信管理与RMI 上篇》。之前说过,JDK中的RMI框架在JDK1.1、JDK1.2、JDK1.5、JDK1.6+几个版本中做了较大的调整。以下我们讨论的RMI工作原理都是基于JDK1.6+版本的。

3、JAVA RMI 工作原理

通过上面的两组代码,我们大概知道了RMI框架是如何使用的。下面我们来讲解一下RMI的基本原理。本人翻阅网上的众多RMI资料基本上代码都是一大抄(甚至变量名、语法错误都一样),还有很多资料存在误导读者的情况。下图描述了整个RMI框架的几个核心概念:

3-1、Registry和Stub、Skeleton的关系

  • 一定要说明,在RMI Client实施正式的RMI调用前,它必须通过LocateRegistry或者Naming方式到RMI注册表寻找要调用的RMI注册信息。找到RMI事务注册信息后,Client会从RMI注册表获取这个RMI Remote Service的Stub信息。这个过程成功后,RMI Client才能开始正式的调用过程。
  • 另外要说明的是RMI Client正式调用过程,也不是由RMI Client直接访问Remote Service,而是由客户端获取的Stub作为RMI Client的代理访问Remote Service的代理Skeleton,如上图所示的顺序。也就是说真实的请求调用是在Stub-Skeleton之间进行的。
  • Registry并不参与具体的Stub-Skeleton的调用过程,只负责记录“哪个服务名”使用哪一个Stub,并在Remote Client询问它时将这个Stub拿给Client(如果没有就会报错)。
  • 为了验证上文描述的调用过程,我们编写一个简单的程序验证一下Registry、Stub和Skeleton的关系。在下面的实验程序中,我们将Registry、Stub、Skeleton分布于三个独立的JVM上。然后当Remote Client在Registry上成功查询到Remote Service的Stub后,将Registry JVM终止掉。验证一下Stub-Skeleton交互过程会不会受到影响。

以下是一个独立运行的Registry程序(注意,它只负责注册、查询工作):

package testRMI;

import java.rmi.registry.LocateRegistry;

/**
 * 就是一个RMI注册仓库,不负责其它事情。<br>
 * 创建仓库后,锁住WAITOBJECT对象,保证整个程序不会退出
 * @author yinwenjie
 */
public class SingleRegistry {

    private static final Object WAITOBJECT = new Object();

    public static void main(String[] args) throws Exception {
        LocateRegistry.createRegistry(1099);
        synchronized (WAITOBJECT) {
            WAITOBJECT.wait();
        }
    }
}

RMI 服务接口的定义还是 RemoteServiceInterface,里面的方法定义和上文一样没有发生变化(RemoteServiceInterface接口的实现和上文一样,没有改变。为了节约篇幅这里就不下贴出代码了):

package testRMI;

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.List;

import testRMI.entity.UserInfo;

public interface RemoteServiceInterface extends Remote {
    /**
     * 这个RMI接口负责查询目前已经注册的所有用户信息
     */
    public List<UserInfo> queryAllUserinfo() throws RemoteException;
}

下面的代码是另外一个运行的JVM,它负责提供RMI Remote Service的注册功能。实际上就是具体的服务提供者。代码如下:

package testRMI;

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class RemoteRegistryUnicastMain {
    public static void main(String[] args) throws Exception {
        /*
         * 我们通过LocateRegistry的get方法,寻找一个存在于远程JVM上的RMI注册表
         * */
        Registry registry = LocateRegistry.getRegistry("192.168.61.1", 1099);

        // 以下是向远程RMI注册表(绑定/重绑定)RMI Server的Stub。
        // 同样的远程RMI注册表的JVM-classpath下,一定要有这个RMI Server的Stub
        RemoteUnicastServiceImpl remoteService = new RemoteUnicastServiceImpl();

        /*
         *
         * 注册的服务仓库存在于192.168.61.1这个IP上
         * 使用注册表registry进行绑定或者重绑定时,不需要写完整的RMI URL
         * */
        registry.bind("queryAllUserinfo" , remoteService);
    }
}

最后一个JVM是RMI Client。一共有两件工作需要RMI Client完成:首先查询Registry注册表服务,获得Remote Service的Stub,然后通过Stub代理进行正式的请求。为了保证实验程序的连续性,在获取Stub后,对Remote Service进行不间断的连续请求。

package testRMI;

import java.rmi.Naming;
import java.util.List;

import testRMI.entity.UserInfo;

/**
 * 客户端调用RMI测试
 * @author yinwenjie
 *
 */
public class RemoteClient {

    private static Object WAITOBJECT = new Object();

    public static void main(String[] args) throws Exception {
        // 您看,这里使用的是java名称服务技术进行的RMI接口查找。
        RemoteServiceInterface remoteServiceInterface = (RemoteServiceInterface)Naming.lookup("rmi://192.168.61.1/queryAllUserinfo");

        // 保证连续请求,好观察SingleRegistry关闭后的请求情况
        for(;;) {
            List<UserInfo> users = remoteServiceInterface.queryAllUserinfo();
            System.out.println("users.size() = " +users.size());
            synchronized (RemoteClient.WAITOBJECT) {
                RemoteClient.WAITOBJECT.wait(1000);
            }
        }
    }
}

以下是记录的测试情况,首先我们分别启动SingleRegistry和RemoteRegistryUnicastMain。可以看见,Remote Service在远程Registry上注册成功,并处于工作状态:

请注意上面的截图中,RemoteRegistryUnicastMain Application只有一个线程在工作。这个和我们随后讲到的RMI-Service的线程管理方式有关。接下来我们启动RMI Client:

特别注意Client向RMI Registry查询得到remoteServiceInterface实例,这并不是RemoteServiceInterface接口的具体实现,而是RMI Stub代理。其中的endpoint端点指向RMI Service的具体服务提供位置(这个位置由RMI Service上的Skeleton提供代理服务)。

接下来开始持续调用。在这里过程中,我们关闭RMI Registry服务:

显然SingleRegistry停止工作并没有影响RemoteClient发起的调用

3-2、Remote-Service线程管理

在上文中的演示我们看到了RemoteRegistryUnicastMain处理请求时,使用了线程池。这是JDK1.5到JDK1.6+版本中RMI框架的做的一个改进。包括JDK1.5在内,之前的版本都采用新建线程的方式来处理请求;在JDK1.6版本之后,改用了线程池,并且线程池的大小是可以调整的:

  • sun.rmi.transport.tcp.maxConnectionThreads:连接池的大小,默认为无限制。无限的大小肯定是有问题,按照Linux单进程可打开的最大文件数限制,建议的设置值为65535(生产环境)。如果同一时间连接池中的线程数量达到了最大值,那么后续的Client请求将会报错。测试环境/开发环境是否设置这个值,就没有那么重要了。
  • sun.rmi.transport.tcp.threadKeepAliveTime:如果当线程池中有闲置的线程资源的话,那么这个闲置线程资源多久被注销(单位毫秒),默认的设置是1分钟。

如果您使用的是linux或者window的命令控制台执行的话,您可以通过类似如下语句进行参数设置:

java -Dsun.rmi.transport.tcp.maxConnectionThreads=2 -Dsun.rmi.transport.tcp.threadKeepAliveTime=1000 testRMI.RemoteRegistryUnicastMain

如果您使用的是eclipse控制台进行执行的话,可以通过Debug configuration -> Arguments对话框进行设置,如下图所示:

3-3、Registry和Naming

在这两篇文章所列举的代码中,Registry和Naming都有出现过,在代码的注释中也提醒大家要注意这两者的使用方法。Registry和Naming都可以进行RMI服务的bind/rebind/unbind,都可以用lookup方法查询RMI服务。

Naming实际上是对Registry的封装。使用完整的URL方式对已注册的服务名进行查找。我们通过Naming类中lookup方法的源代码对Naming的工作方式进行说明。以下是Naming类中lookup方法的源代码:

/**
* Returns a reference, a stub, for the remote object associated
 * with the specified <code>name</code>.
 *
 * @param name a name in URL format (without the scheme component)
 * @return a reference for a remote object formatted URL
 * @since JDK1.1
 */
public static Remote lookup(String name)
    throws NotBoundException,
        java.net.MalformedURLException,
        RemoteException {
    ParsedNamingURL parsed = parseURL(name);
    Registry registry = getRegistry(parsed);

    if (parsed.name == null)
        return registry;
    return registry.lookup(parsed.name);
}

在这个静态方法中,首先对传入的URL信息进行解析(parseURL(name)私有方法),解析完成后,将返回ParsedNamingURL私有类的一个对象parsed。我们来看看ParsedNamingURL的定义:

/**
 * Simple class to enable multiple URL return values.
 */
private static class ParsedNamingURL {
    String host;
    int port;
    String name;

    ParsedNamingURL(String host, int port, String name) {
        this.host = host;
        this.port = port;
        this.name = name;
    }
}

如果解析过程中,发现URL格式问题,那么将会抛出异常;如果成功解析,则调用Registry的lookup方法。RMI Naming服务所使用的完整URL格式为:

rmi://host:port/name

其中rmi为固定格式 ,host是RMI Registry注册表所在服务地址;port为Registry注册表访问端口,默认端口为1099;name表示RMI Remote Service的注册名,在之前的代码中RMI Remote Service注册名是queryAllUserinfo。

Naming名字服务只提供RMI服务注册信息的查询,您不能使用Naming创建一个注册服务

3-3、UnicastRemoteObject和Activatable

在上篇文章中初次讲解RMI工作原理的时候,我提到“图中呈现的是JDK1.5版本中,RMI框架其中一种运行方式”。也就是说,除了这种工作模式外RMI还有其他的工作模式?

是的,在JDK1.2版本中,由Ann Wollrath执笔加入了一种新的RMI工作方式。即通过RMI“活化”模式,将Remote Service的真实提供者移植到RMI Registry注册表所在的JVM上。

要使用这种工作模式的Remote Service实现不再继承UnicastRemoteObject类,而需要继承Activatable类(其他的业务代码不需要改变):

package testRMI;

import java.rmi.MarshalledObject;
import java.rmi.RemoteException;
import java.rmi.activation.Activatable;
import java.rmi.activation.ActivationException;
import java.rmi.activation.ActivationID;
import java.util.ArrayList;
import java.util.List;

import testRMI.entity.UserInfo;

/**
 * RMI Service的一个具体实现。注意这里我们继承的是Activatable父类
 * @author yinwenjie
 */
public class RemoteActivationServiceImpl extends Activatable implements RemoteServiceInterface {    

    /**
     * 这个构造函数式必须的,不然客户端会报:<br>
     * java.lang.NoSuchMethodException: testRMI.RemoteActivationServiceImpl.<init>(java.rmi.activation.ActivationID, java.rmi.MarshalledObject) 异常<br>
     * 在这个方法里面,您可以调用任何一个Activatable父级的构造函数。这里我们调用的是最简单的一个
     * @throws RemoteException
     * @throws ActivationException
     */
    public RemoteActivationServiceImpl(ActivationID id, MarshalledObject<?> data) throws RemoteException, ActivationException {
        super("file://E:\\testworkspace\\testBSocket\\target\\classes", data, false , 0);
    }

    /**
     *
     */
    private static final long serialVersionUID = 6797720945876437472L;

    /* (non-Javadoc)
     * @see testRMI.RemoteServiceInterface#queryAllUserinfo()
     */
    @Override
    public List<UserInfo> queryAllUserinfo() throws RemoteException {
        List<UserInfo> users = new ArrayList<UserInfo>();

        UserInfo user1 = new UserInfo();
        user1.setUserAge(21);
        user1.setUserDesc("userDesc1");
        user1.setUserName("userName1");
        user1.setUserSex(true);
        users.add(user1);

        UserInfo user2 = new UserInfo();
        user2.setUserAge(21);
        user2.setUserDesc("userDesc2");
        user2.setUserName("userName2");
        user2.setUserSex(false);
        users.add(user2);
        return users;
    }
}

向RMI Registry注册表进行注册的方式也需要进行更改:

package testRMI;

import java.rmi.MarshalledObject;
import java.rmi.RMISecurityManager;
import java.rmi.activation.Activatable;
import java.rmi.activation.ActivationDesc;
import java.rmi.activation.ActivationGroup;
import java.rmi.activation.ActivationGroupDesc;
import java.rmi.activation.ActivationGroupID;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.util.Properties;

import testRMI.entity.UserInfo;

public class RemoteActivationMain {

    public static void main(String[] args) throws Exception {
        System.setSecurityManager(new RMISecurityManager());
        System.setProperty("java.rmi.activation.port","1099");

        // 设置各种参数
        Properties props = new Properties();
        // 最重要的参数是给rmi 激活服务相应的权限
        // all.policy文件的配置在后文中说明
        props.put("java.security.policy", "E:/testworkspace/testBSocket/src/all.policy");

        /*
         * 这里对ActivationDesc构造函数中的参数进行一下说明:
         * groupID:就是在registerGroup时系统生成的ActivationGroupID对象
         * className:这里就是testRMI.RemoteActivationServiceImpl具体的RemoteServiceInterface接口
         * location:相当于classpath。这样注册程序才知道如何序列化类.
         * 实际上之前我们建立RemoteActivationServiceImpl的构造函数时,实际上已经location写死了
         * 这里只是为了讲解desc和RemoteActivationServiceImpl中构造函数的关系,又进行了一次参数指定
         *
         * MarshalledObject:一种序列化和反序列化方式,参见:
         * http://download.oracle.com/technetwork/java/javase/6/docs/zh/api/java/rmi/MarshalledObject.html
         * */
        ActivationGroupDesc groupdesc = new ActivationGroupDesc(props, null);
        ActivationGroupID groupid = ActivationGroup.getSystem().registerGroup(groupdesc);
        UserInfo userinfo = new UserInfo();
        ActivationDesc desc = new ActivationDesc(groupid, "testRMI.RemoteActivationServiceImpl", "file://E:\\testworkspace\\testBSocket\\target\\classes", new MarshalledObject<UserInfo>(userinfo));

        /*
         * 是不是与UnicastRemoteObject的注册方式不一样啊。
         * 之所以比较复杂,是因为这个Remote Object将会序列化到RMI Registry所在的JVM进行运行。
         * 并适时被“激活”运行
         * */
        RemoteServiceInterface server = (RemoteServiceInterface)Activatable.register(desc);
        /*
         * 和执行UnicastRemoteObject注册的情况不同,这里绑定Remote Object成功后,这个JVM将会退出
         * 因为之后的RMI调用将和它没有一点关系了。
         * */
        //Naming.bind("rmi://192.168.61.1:1099/queryAllUserinfo",server);
        Registry registry = LocateRegistry.getRegistry("192.168.61.1",1099);
        registry.bind("queryAllUserinfo", server);
    }
}

还需要做一个进行JVM权限描述文件all.policy:

grant {

permission java.security.AllPermission “”, “”;

};

当然这是比较简单的描述(主要是为了偷懒,哈哈)。您还可以使用JDK安装目录下自带的权限描述文件,当然要进行一些修改。文件存放路径为$JAVA_HOME\jre\lib\security\java.policy,里面有一些权限信息要根据您自己的实际情况进行修改。

之后我们启动rmib——一个支持RMI“活化”模式的注册表程序:

rmid -J-Djava.security.policy=E:\testworkspace\testBSocket\src\all.policy -port 1099 -J-Djava.rmi.server.codebase=file:/E:/testworkspace/testBSocket/target/classes/

如果您使用的是Linux系统的话,命令形式如下:

export CLASSPATH=$CLASSPATH:/root/java/classes/

rmid -J-Djava.security.policy=/usr/jdk1.7.0_71/all.policy -port 1099

客户端的代码和运行方式是不需要更改的。直接运行之前的RMI Client程序就可以看到效果了。这里注意以下几个问题;

  • 使用RMI的“活化”工作模式,原有的RMI Remote Service真实服务提供者就不再需要对RMI Client的调用进行响应了。所以您会看到在RemoteActivationMain完成注册工作后,RemoteActivationMain所在的JVM会退出,而不会像之前的RemoteUnicastMain一样,在完成注册后一直等待。如下图所示:

  • 另外,Client请求到的Stub,其中的endPoint不再指向Remote Service的真实服务提供者了,而是指向Registry注册服务提供者。这是因为Registry将负责真实服务的实现。如下图所示:

请注意Client获取的Stub的endPoint指向。

3、RMI——一种特殊的RPC服务实现

通过这两篇文章的讲解,我们将RMI的基本使用、工作原理、工作模式向您进行了简要的介绍。之所以介绍RMI,是因为要通过介绍RMI引出一种重要的系统间通讯管理框架RPC。从下一篇文章开始,我们将进入RPC规范的讲解,并介绍几款主流的RPC框架的使用和工作原理。

当然通过两篇文章对RMI技术的介绍,并不能将RMI技术的全部内容都囊括进来,后面有时间我将回头继续向您介绍RMI技术的特性。感谢您持续关注我的博客。

版权声明:欢迎转载,但是看在我辛勤劳动的份上,请注明来源:http://blog.csdn.net/yinwenjie

时间: 2024-10-06 11:13:09

架构设计:系统间通信(9)——通信管理与RMI 下篇的相关文章

ios app架构设计系统文章

三. iOS应用架构谈(三):网络层设计方案(上) http://www.infoq.com/cn/articles/ios-app-arch-3-1?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

架构设计:系统间通信(32)——其他消息中间件及场景应用(下2)

(接上文<架构设计:系统间通信(31)--其他消息中间件及场景应用(下1)>) 5-3.解决方案二:改进半侵入式方案 5-3-1.解决方法一的问题所在 方案一并不是最好的半侵入式方案,却容易理解架构师的设计意图:至少做到业务级隔离.方案一最大的优点在于日志采集逻辑和业务处理逻辑彼此隔离,当业务逻辑发生变化的时候,并不会影响日志采集逻辑. 但是我们能为方案一列举的问题却可以远远多于方案一的优点: 需要为不同开发语言分别提供客户端API包.上文中我们介绍的示例使用JAVA语言,于是 事件/日志采集

架构设计:系统间通信(22)——提高ActiveMQ工作性能(上)

接上文<架构设计:系统间通信(21)--ActiveMQ的安装与使用> 3.ActiveMQ性能优化思路 上篇文章中的两节内容,主要介绍消息中间件ActiveMQ的安装和基本使用.从上篇文章给出的安装配置和示例代码来看,我们既没有修改ActivieMQ服务节点的任何配置,也没有采用任何的集群方案.这种情况只适合各位读者熟悉ActiveMQ的工作原理和基本操作,但是如果要将ActivieMQ应用在生产环境下,上文中介绍的运行方式远远没有挖掘出它的潜在性能. 根据这个系列文章所陈述的中心思想,系统

架构设计:系统间通信(15)——服务治理与Dubbo 上篇

1.上篇中"自定义服务治理框架"的问题 在之前的文章中(<架构设计:系统间通信(13)--RPC实例Apache Thrift 下篇(1)>.<架构设计:系统间通信(14)--RPC实例Apache Thrift 下篇(2)>),我们基于服务治理的基本原理,自己实现了一个基于zookeeper + thrift的服务治理框架.但实际上前文中我们自行设计的服务治理框架除了演示基本原理外,并没有多大的实际使用价值,因为还有很多硬性需求是没有实现的: 访问权限:在整个

架构设计:系统间通信(10)——RPC的基本概念

1.概述 经过了详细的信息格式.网络IO模型的讲解,并且通过JAVA RMI的讲解进行了预热.从这篇文章开始我们将进入这个系列博文的另一个重点知识体系的讲解:RPC.在后续的几篇文章中,我们首先讲解RPC的基本概念,一个具体的RPC实现会有哪些基本要素构成,然后我们详细介绍一款典型的RPC框架:Apache Thrift.接下来我们聊聊服务治理和DUBBO服务框架.最后总结一下如何在实际工作中选择合适的RPC框架. 2.RPC概述 2-1.什么是RPC RPC(Remote Procedure

架构设计:系统间通信(43)——自己动手设计ESB(4)

============================== 接上文<架构设计:系统间通信(42)--自己动手设计ESB(3)> 5.Borker Server选择 在本文之前的三篇文章中,我们介绍了自行设计的ESB中间件的顶层设计.介绍了主控服务如何对多个ESB-Brokers动态节点进行日志采集和监控.还介绍了ESB-Broker节点如何进行动态路由定义的加载管理.这篇文章我们主要讨论关于ESB-Client的一些关键设计. 在我们自行设计的ESB中间件中为了保证ESB服务不会成为整个软件

架构设计:系统间通信(5)——IO通信模型和JAVA实践 下篇

接上篇:<架构设计:系统间通信(4)--IO通信模型和JAVA实践 中篇>,我们继续讲解 异步IO 7.异步IO 上面两篇文章中,我们分别讲解了阻塞式同步IO.非阻塞式同步IO.多路复用IO 这三种IO模型,以及JAVA对于这三种IO模型的支持.重点说明了IO模型是由操作系统提供支持,且这三种IO模型都是同步IO,都是采用的"应用程序不询问我,我绝不会主动通知"的方式. 异步IO则是采用"订阅-通知"模式:即应用程序向操作系统注册IO监听,然后继续做自己

架构设计:系统间通信(38)——Apache Camel快速入门(下1)

======================= (接上文<架构设计:系统间通信(37)--Apache Camel快速入门(中)>) 3-5-2-3循环动态路由 Dynamic Router 动态循环路由的特点是开发人员可以通过条件表达式等方式,动态决定下一个路由位置.在下一路由位置处理完成后Exchange将被重新返回到路由判断点,并由动态循环路由再次做出新路径的判断.如此循环执行直到动态循环路由不能再找到任何一条新的路由路径为止.下图来源于官网(http://camel.apache.or

架构设计:系统间通信(26)——ActiveMQ集群方案(下)

(接上文<架构设计:系统间通信(26)--ActiveMQ集群方案(上)>) 3.ActiveMQ热备方案 ActiveMQ热备方案,主要保证ActiveMQ的高可用性.这种方案并不像上节中我们主要讨论的ActiveMQ高性能方案那样,同时有多个节点都处于工作状态,也就是说这种方案并不提高ActiveMQ集群的性能:而是从集群中的多个节点选择一个,让其处于工作状态,集群中其它节点则处于待命状态.当主要的工作节点由于各种异常情况停止服务时,保证处于待命的节点能够无缝接替其工作. 3-1.Acti