我们为什么需要知道Dubbo框架？

作为一个开发者，早期开发的时候，我们只需要一个服务器，将程序打包丢上去就可以了，但是随着互联网的巨变，对于流量的要求非常之高，像这种垂直应用架构早已无法应对。比如说Tomcat，其默认配置的最大请求数是 150（同时支持150个并发），当然了，我们也可以将其参数改大。

但是并非参数越高越好，具体能承载多少并发还需要看服务器的硬件配置，CPU多大，能分配给JVM的内存多大，就算CPU性能超好，可分配给JVM的内存也很高，但是无形中，GC的活儿就干不完了。所以，当某个应用达到250以上并发的时候，就应该考虑应用服务器的集群。我们可以看一下开发的历史演变过程，大概如下：

1、单一应用架构（统一部署）

2、应用和数据库单独部署（各用一台服务器）

3、应用和数据库集群部署（多台服务器）

4、数据库压力变大，读写分离（同样基于集群基础）

5、使用缓存技术加快速度（比如Redis）

6、数据库分库分表

7、应用分为不同的类型拆分（分布式）

总结起来，就是随着技术的发展，我们会发现应用与应用之间的关系会变得相当复杂，大致有以下几个问题：

① 当服务越来越多时，服务URL配置管理变得相当困难，F5 硬件负载均衡器的单点压力也越来越大。

② 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构关系繁杂。

③ 当服务的调用量越来越大，服务的容量问题就暴露出来，服务需要多少机器支撑？什么时候加机器？

伴随着这些问题的产生，Dubbo就产生了，那么什么是Dubbo呢？

Dubbo是远程服务调用的开源分布式框架，由阿里巴巴提供，使得应用可通过高性能的RPC 实现服务的输出和输入功能（以服务者与消费者的方式在dubbo上注册），可以和Spring框架无缝集成。

Dubbo可以做什么？

Dubbo三大核心能力:

1.远程通讯(面向接口的远程方法调用)
提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2.集群容错(智能容错和负载均衡)
提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3.自动发现(服务自动注册和发现)
基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

上一张图乃摘自官网的介绍图，其中各角色表示如下：

Provider————暴露服务的服务提供方

Consumer————调用远程服务的服务消费方

Registry————服务注册与发现的注册中心

Monitor—————统计服务的调用次数和调用时间的监控中心

Container———服务运行容器

所以，Dubbo大致就是生产者-消费者加注册中心和监控中心，用于管理提供方提供的url，以及管理整个过程的框架，其具体能做的事情大致如下：
1）透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。      
2）软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3）服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

其优势在于：

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。