java rmi与dubbo

首先得知道什么是分布式，以及和集群的区别？
分布式：一个业务分拆成多个子业务，部署在不同的服务器上，多半是为了业务解耦，不同的业务可以分别部署，互不干扰，只在需要时相互调用，提升效率。
集群：同一个业务，部署在多个服务器上，多半是为了解决高并发，高访问量，提高系统性能。
##RMI
RMI（Remote Method Invocation）即远程方法调用，是java在JDK1.1中实现的一组用于开发分布式应用程序的API，它大大增强了Java开发分布式应用的能力。
(RMI的具体用法这里不说了，在我另一篇文章中已经有讲解了)
知道了分布式，就知道RMI到底用来干嘛的了，就是用来让不同业务的子系统之间进行服务调用，例如A系统要调用B系统的某个方法，就可以用RMI实现。
但是RMI本身并没有集群的功能，就是同一个业务部署了多台服务器，他只会根据你配置的ip地址，端口去调用其中一台，不会去调用另外的，所以，
怎么去有规则的调用另外的服务器就是负载均衡的工作了，这需要你自己实现。
总结：RMI能实现分布式服务，但单凭他自己不支持集群。

当你的系统需要集群时，远程服务调用就不能用RMI了，他已经不在满足需求，除非你自己在他的基础上继续完善，使之起码可以完成负载均衡的工作，才能开始适应集群环境。
但这是比较麻烦的事情，有没有现有的框架可以代替呢，dubbo就是一个很好的选择！
##Dubbo
DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。

先来了解一下随着互联网的发展，应用架构的产生的变化：
##单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
##垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
##分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
##流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

通过上面的了解，我们知道了应用架构的发展变化：
就一个应用 -> 多个应用共同工作，但互不联系 -> 多个应用具有不同功能，相互协作，共同完成工作的分布式架构 -> 同一个功能也有多台服务器，集群部署后实时管理，均衡地调用各服务的流动计算分布式架构
显然之前介绍的RMI就是第三个(分布式服务架构)，而dubbo就是目前最前沿的流动计算架构，他通过自己的调度中心根据监控中心提供的访问压力可以实时告诉服务消费方到底调用哪一个服务提供方的服务。
dubbo的主要节点角色：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Scheduler: 调度中心基于访问压力自动增减服务提供者。