rmi什么是RMI原则呢？

rpc框架都有哪些rmi dubbo

Dubbo分层 config（配置层 ） proxy（服务代理层） registry（ 注册中心层） cluster（ 路由层） monitor（ 监控层） protocol（ 远程调用层） exchange（ 信息交换层） transport（ 网络传输层） serialize（ 数据序列化层） 对外配置接口 以ServiceConfig, ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类 Javassist ProxyFactory Jdk ProxyFactory 服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton 以ServiceProxy为中心，扩展接口为ProxyFactory 选择 Zookeeper Redis Multicast Simple 支持基于网络的集群方式，有广泛周边开源产品，建议使用dubbo-2.3.3以上版本（推荐使用） 依赖于Zookeeper的稳定性 支持基于客户端双写的集群方式，性能高 要求服务器时间同步，用于检查心跳过期脏数据 去中心化，不需要安装注册中心 依赖于网络拓普和路由，跨机房有风险 Dogfooding，注册中心本身也是一个标准的RPC服务 没有集群支持，可能单点故障 封装服务地址的注册与发现 以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService 选择 Spring Jetty Log4j 自动加载META-INF/spring目录下的所有Spring配置 启动一个内嵌Jetty，用于汇报状态 大量访问页面时，会影响服务器的线程和内存 自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录 用户不能控制log4j的配置，不灵活 条件路由 脚本路由 基于条件表达式的路由规则，功能简单易用 有些复杂多分支条件情况，规则很难描述 基于脚本引擎的路由规则，功能强大 没有运行沙箱，脚本能力过于强大，可能成为后门 Random RoundRobin LeastActive ConsistentHash 随机，按权重设置随机概率（推荐使用） 在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均 轮循，按公约后的权重设置轮循比率 存在慢的机器累积请求问题，极端情况可能产生雪崩 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求 不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量 一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动 压力分摊不均 Failover Failfast Failsafe Failback Forking Broadcast 失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用） 重试会带来更长延迟 快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作 如果有机器正在重启，可能会出现调用失败 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作 调用信息丢失 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作 不可靠，重启丢失 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作 需要浪费更多服务资源 广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态 速度慢，任意一台报错则报错 封装多个提供者的路由及负载均衡，并桥接注册中心 以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance Cluster选择 Router选择 路由规则 容器 RPC调用次数和调用时间监控 以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService Dubbo协议 Rmi协议 Hessian协议 连接个数：单连接 连接方式：长连接 传输协议：TCP 传输方式：NIO异步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。

适用场景：常规远程服务方法调用 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用） 适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况 Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低 Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接 为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护 在大文件传输时，单一连接会成为瓶颈 总结 可与原生RMI互操作，基于TCP协议 偶尔会连接失败，需重建Stub 参数及返回值需实现Serializable接口 参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失 连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件 适用场景：页面传输，文件传输，或与原生hessian服务互操作 提供者用Dubbo的Hessian协议暴露服务，消费者直接用标准Hessian接口调用 或者提供方用标准Hessian暴露服务，消费方用Dubbo的Hessian协议调用 基于Hessian的远程调用协议 可与原生Hessian互操作，基于HTTP协议 需hessian.jar支持，http短连接的开销大 Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现 可以和原生Hessian服务互操作 总结 约束 封装RPC调用 以Invocation, Result为中心，扩展接口为Protocol, Invoker, Exporter 选择 封装请求响应模式，同步转异步 以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel,ExchangeClient, ExchangeServer Netty Mina Grizzly 性能较好（推荐使用） 一次请求派发两种事件，需屏蔽无用事件 老牌NIO框架，稳定 待发送消息队列派发不及时，大压力下，会出现FullGC Sun的NIO框架，应用于GlassFish服务器中 线程池不可扩展，Filter不能拦截下一Filter 抽象ty为统一接口 以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec 选择 Hessian Dubbo Json Java 性能较好，多语言支持（推荐使用） Hessian的各版本兼容性不好，可能和应用使用的Hessian冲突，Dubbo内嵌了hessian3.2.1的源码 通过不传送POJO的类元信息，在大量POJO传输时，性能较好 当参数对象增加字段时，需外部文件声明 纯文本，可跨语言解析，缺省采用FastJson解析 性能较差 Java原生支持 性能较差 可复用的一些工具 扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool 选择 Business RPC Remoting Service Config Proxy Registry Cluster Monitor Protocol Exchange Transport Serialize 层次结构 层说明

远程方法调用RMI的问题

RMI远程方法调用是一种计算机之间利用远程对象互相调用实现双方通讯的一种通讯机制。

使用这种机制，某一台计算机上的对象可以调用另外一台计算机上的对象来获取远程数据。

RMI是Enterprise JavaBeans的支柱，是建立分布式Java应用程序的方便途径。

　　简单实例： 　　1、首先为服务建立一个Model层，注意因为此对象需要现实进行远程传输，所以必须继承Serializable 　　2、创建远程接口PersonService,注意远程接口需要继承Remote 　　3、建立PersonServiceImpl实现远程接口，注意此为远程对象实现类，需要继承UnicastRemoteObject 　　4、建立服务器端，在服务器端注册RMI通讯端口与通讯路径，然后通讯javac命令编译文件，通过java -server 命令注册服务。

　　5、以下面代码为例，如果将项目建立于D:\RMIRemotingService文件夹上时，则先输入D:\RMIRemotingServicesrc>javac rmi/remotingservice/Program.java获取Program.class，然后输入D:\RMIRemotingServicesrc>javarmi/remotingservice/Program启动服务。

　　6、最后建立客户端进行测试，注意客户调用的RMI路径必须服务器配置一致。

Corba和RMI有区别之处.

显而易见，RMI比CORBA简单，开发者不需要熟悉IDL。

通常，CORBA与RMI有下列不同： 接口定义不同，CORBA用IDL，而RMI用JAVA。

CORBA的参数有输入，输出类型。

CORBA设计与语言无关。

是不同语言开发系统的桥梁。

CORBA对象不能垃圾收集。

象我们提到的那样，CORBA与语言无关。

象C++不支持垃圾收集那样。

这是CORBA的缺点。

一旦我们创建CORBA对象，它将一直存在，知道你亲自去处它。

而RMI是自动收集。

让RMI程序能正确运行有哪些步骤？

为了让RMI程序能正确运行必须要包含以下几个步骤： 1、编译所有的源文件。

2、使用rmic生成stub。

3、启动rmiregistry。

4、启动RMI服务器。

5、运行客户端程序。

什么是RMI原则呢？

什么是RMI Java RMI （Remote Method Invocation 远程方法调用）是用Java在JDK1.1中实现的，它大大增强了Java开发分布式应用的能力。

Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。

其实它可以被看作是RPC的Java版本。

但是传统RPC并不能很好地应用于分布式对象系统。

而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。

RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。

JRMP是专为Java的远程对象制定的协议。

因此，Java RMI具有Java的"Write Once,Run Anywhere"的优点，是分布式应用系统的百分之百纯Java解决方案。

用Java RMI开发的应用系统可以部署在任何支持JRE（Java Run Environment Java，运行环境）的平台上。

但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。

不能与用非Java语言书写的对象进行通信。