This is an automated email from the ASF dual-hosted git repository.
wangxin pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/incubator-dubbo-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 92fe7f0 Revert "修改错别字" (#345)
92fe7f0 is described below
commit 92fe7f051f9906f900f18a38b8b36f22137c57ca
Author: Xin Wang <[email protected]>
AuthorDate: Mon Mar 25 19:39:14 2019 +0800
Revert "修改错别字" (#345)
* Update requirements.md
---
docs/zh-cn/user/preface/requirements.md | 4 ++--
zh-cn/docs/user/preface/requirements.html | 4 ++--
2 files changed, 4 insertions(+), 4 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 最基本的几个需求。
diff --git a/zh-cn/docs/user/preface/requirements.html
b/zh-cn/docs/user/preface/requirements.html
index f7a4187..50b8edc 100644
--- a/zh-cn/docs/user/preface/requirements.html
+++ b/zh-cn/docs/user/preface/requirements.html
@@ -15,7 +15,7 @@
<div id="root"><div class="documentation-page"
data-reactroot=""><header class="header-container header-container-normal"><div
class="header-body"><a href="/zh-cn/index.html"><img class="logo"
src="/img/dubbo_colorful.png"/></a><div class="search search-normal"><span
class="icon-search"></span></div><span class="language-switch
language-switch-normal">En</span><div class="header-menu"><img
class="header-menu-toggle" src="/img/menu_gray.png"/><ul><li class="menu-item
menu-item-normal"><a [...]
<p><img src="../sources/images/dubbo-service-governance.jpg" alt="image"></p>
<p>在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5
等硬件进行负载均衡。</p>
-<p><strong>当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。</strong>
此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5
硬件负载均衡器的依赖，也能减少部分成本。</p>
+<p><strong>当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。</strong>
此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5
硬件负载均衡器的依赖，也能减少部分成本。</p>
<p><strong>当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。</strong>
这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。</p>
<p><strong>接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？</strong>
为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。</p>
<p>以上是 Dubbo 最基本的几个需求。</p>
@@ -36,4 +36,4 @@
gtag('config', 'UA-112489517-1');
</script>
</body>
-</html>
+</html>
\ No newline at end of file
