（二）Dubbo背景

背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直结构已经不能满足需求，分布式服务架构以及流动计算架构势在必行，而目前针对和spring容器相结合的分布式，就是dubbo了。

 

演变过程

单一应用架构

当网站需要的流量很小时，只需要一个应用，我们可以把这个应用部署在一台机器上，以减少部署节点和成本。

当流量较小的时候，业务逻辑不是很复杂的时候，我们可以使用ORM（对象关系映射）数据库框架，以减少开发成本。

 

垂直应用架构

当访问量逐渐增大，一个项目通过增加机器来负载均衡，而增加机器的加速度越来越小，我们可以将应用拆分成几个互不相关的应用，以提高效率，我们使用的是MVCweb框架。（根据业务拆分成多个web项目）

 

分布式服务架构

当垂直应用越来越多，应用之间的交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能快速响应适应多变的市场需求。

此时，用于使用提高业务复用及整合的分布式服务框架（RPC）。（业务层抽象出来，view层采用RPC远程调用service）

 

流动计算机构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐明显，此时需要一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

   此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。（增加调度中心来控制）

 

dubbo服务治理

 

需求

（1）当服务越来越多时，服务URL配置管理比较困难，F5硬件负载均衡的单点压力也越来越大。

可是使用一个注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡的依赖，减少部分成本。

 

（2）当服务间的依赖关系变得错综复杂，甚至分不清哪个应用在哪个应用之前启动，架构师也不能完整描述应用之间的架构关系。

   需要一个可以自动画出应用之间的依赖关系的图，以帮助架构师处理清理关系。

（3）当服务的调用量越来越大，服务的容量问题就暴露出来，这个服务要多少机器支撑？什么时候加机器呢？

   将服务现在每天的掉用量，响应时间，都统计出来，作为容量规划的参考指标。其次，动态调整权重，在线上，将某台机器的权重一直加大，并在加大过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

     综上：这就提到了dubbo的调度中心，在调度中心的基础上，dubbo内部的业务逻辑更加完善，下一篇dubbo的工作原理。