作为一个开发者，早期开发的时候，我们只需要一个服务器，将程序打包丢上去就可以了，但是随着互联网的巨变，对于流量的要求非常之高，像这种垂直应用架构早已无法应对。比如说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扩展进行加载。
