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