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 <xin.victorw...@gmail.com> 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