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 最基本的几个需求。
