[dubbo-website] branch master updated: 删掉多余的字 (#539)

[il...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

iluo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git


The following commit(s) were added to refs/heads/master by this push:
     new 769e90b  删掉多余的字 (#539)
769e90b is described below

commit 769e90be6fca7e5d0e07dd0cbe2bf611db623ce9
Author: xurui <30...@users.noreply.github.com>
AuthorDate: Mon Dec 9 22:31:48 2019 +0800

    删掉多余的字 (#539)
---
 docs/zh-cn/user/preface/requirements.md | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/docs/zh-cn/user/preface/requirements.md b/docs/zh-cn/user/preface/requirements.md
index 06c25c3..2c8b921 100644
--- a/docs/zh-cn/user/preface/requirements.md
+++ b/docs/zh-cn/user/preface/requirements.md
@@ -1,3 +1,9 @@
+---
+title: 需求
+keywords: 服务注册中心，依赖关系，机器支撑
+description: 本文介绍了dubbo要解决的需求
+---
+
 # 需求
 
 ![image](../sources/images/dubbo-service-governance.jpg)
@@ -5,9 +11,9 @@
 在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。
 
 **当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。** 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。
-      
-**当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。**  这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
-      
+
+**当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。**  这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。
+
 **接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？**  为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
-    
+
 以上是 Dubbo 最基本的几个需求。