This is an automated email from the ASF dual-hosted git repository. wangxin pushed a commit to branch revert-344-asf-site in repository https://gitbox.apache.org/repos/asf/incubator-dubbo-website.git
The following commit(s) were added to refs/heads/revert-344-asf-site by this push: new 48a88f1 Update requirements.md 48a88f1 is described below commit 48a88f198926084d560fc94a1f5a000510ef77a2 Author: Xin Wang <xin.victorw...@gmail.com> AuthorDate: Mon Mar 25 19:38:35 2019 +0800 Update requirements.md --- docs/zh-cn/user/preface/requirements.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/zh-cn/user/preface/requirements.md b/docs/zh-cn/user/preface/requirements.md index 34167b0..06c25c3 100644 --- a/docs/zh-cn/user/preface/requirements.md +++ b/docs/zh-cn/user/preface/requirements.md @@ -4,10 +4,10 @@ 在大规模服务化之前,应用可能只是通过 RMI 或 Hessian 等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过 F5 等硬件进行负载均衡。 -**当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。** 此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。 +**当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。** 此时需要一个服务注册中心,动态地注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。 **当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。** 这时,需要自动画出应用间的依赖关系图,以帮助架构师理清理关系。 **接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?** 为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阈值,记录此时的访问量,再以此访问量乘以机器数反推总容量。 -以上是 Dubbo 最基本的几个需求。 \ No newline at end of file +以上是 Dubbo 最基本的几个需求。