在上篇文章中,我们主要了解了Dubbo的架构路线,并对它有了一个比较简单点的印象和了解,而关于Dubbo基本需求是接下来要介绍的内容.
在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。
关于F5硬件可以参考 F5 Networks
(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
(2)当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
(3)接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
为了解决这些问题，
第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。
其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
下图是Dubbo的服务治理,在这里只需要先扫一眼这个治理图.等随后的再把Zookeeper注册中心和Dubbo的监控中心进行分享,那时候再回来看一下这个图,会比现在这个时候要好一些.
了解Dubbo的基本需求之后,下篇文章需要对Dubbo架构的内部逻辑和调用进行下一步的讲解.
原文地址：http://blog.csdn.net/jnqqls/article/details/42278401
