Dubbo是一个分布式服务框架，提供高性能和透明化的RPC远程服务调用方案。
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看， Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。
为什么要使用Dubbo？
随着Internet的快速发展，Web应用程序的规模在不断的扩大，最终我们发现了，传统的垂直架构(单片机)无法再解决这个问题。分布式服务架构和流量计算架构势在必行，迫切的需要一个治理系统来确保架构的有序的演进。
单片架构：
当流量非常低下的时候，只有一个应用程序，所有功能都部署在一起，以减少部署的节点和成本。
垂直建筑：
当流量变大的时候，添加单片的应用程序无法很好的加速访问，提高效率是一种方法，将单片机拆为离散的应用程序，此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构：
当越来越多的垂直的应用程序，应用程序之间的交互是不可避免的，一些核心的业务被提取并作为独立服务，逐渐的形成一个稳定的服务中心，这样，前端的应用程序可以更多的响应市场需求的变化很快，此时，用于业务重用和集成的分布式的服务框架(RPC)是关键。
流量计算架构
当服务越来越多时，容量评估变得困难，小规模的服务也经常导致资源浪费。为了解决这些问题，应该添加一个调度中心来管理基于流量的集群容量，并提高集群的利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。
- 当服务越来越多，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。
并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
- 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
- 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。
其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
