[25/51] incubator-servicecomb-website git commit: updated statements for blog legacy system reform

[jbonofre]

updated statements for blog legacy system reform

Signed-off-by: Eric Lee <dagang...@huawei.com>


Project: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/commit/8b91b1a7
Tree: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/tree/8b91b1a7
Diff: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/diff/8b91b1a7

Branch: refs/heads/asf-site
Commit: 8b91b1a7827a4d4d9e38ad9b6d85418decbba02c
Parents: 0edcb90
Author: Eric Lee <dagang...@huawei.com>
Authored: Tue Nov 14 17:28:19 2017 +0800
Committer: Willem Jiang <jiangni...@huawei.com>
Committed: Tue Nov 14 18:29:51 2017 +0800

----------------------------------------------------------------------
 .../2017-10-23-how-to-reform-a-legacy-system.md |  69 ++++++++++++-------
 .../2017-10-23-how-to-reform-a-legacy-system.md |  69 ++++++++++++-------
 assets/images/case_mengtuo_new_mode.png         | Bin 71137 -> 22686 bytes
 .../case_mengtuo_reform_before_and_after.png    | Bin 169124 -> 39806 bytes
 assets/images/case_mengtuo_traditional_mode.png | Bin 63155 -> 24621 bytes
 5 files changed, 86 insertions(+), 52 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/8b91b1a7/_posts/2017-10-23-how-to-reform-a-legacy-system.md
----------------------------------------------------------------------
diff --git a/_posts/2017-10-23-how-to-reform-a-legacy-system.md 
b/_posts/2017-10-23-how-to-reform-a-legacy-system.md
index 54d1c0f..1fe3518 100644
--- a/_posts/2017-10-23-how-to-reform-a-legacy-system.md
+++ b/_posts/2017-10-23-how-to-reform-a-legacy-system.md
@@ -11,16 +11,17 @@ redirect_from:
   - /theme-setup/
 ---
 
-随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œå¾®æœåŠ¡ï¼ˆMicroservices）逐渐成为系统架构的一个代名词。那么微服务是否是业界期å¾
…已久的企业架构解决方案？在对遗留系统进行微服务的改造
过程中存在怎æ 
·çš„困难和挑战，应该注意些什么？在该分享中，王磊将通过实é™
…的案例，跟大家探讨使用微服务改造遗留系统的实践之路。
-1. 什么是微服务
-2. 微服务的诞生背景
-3. 遗留系统的微服务改造策略
-4. 微服务改造之路
+随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œå¾®æœåŠ¡ï¼ˆMicroservices）逐渐成为系统架构的一个代名词。那么微服务是否是业界期å¾
…已久的架构解决方案？在对遗留系统进行微服务的改造
过程中存在怎æ 
·çš„困难和挑战，应该注意些什么？在该分享中，王磊将通过实é™
…的案例，跟大家探讨使用微服务改造遗留系统的实践之路。
+
+* 什么是微服务
+* 微服务的诞生背景
+* 遗留系统的微服务改造策略
+* 微服务改造之路
 
 ## 背景
-首先，请大家思考什么是系统架构设计？
+什么是系统架构设计？
 
-一直以来，系统架构设计是IT领域经久
不衰的话题之一，是每个系统构建过程中极其å…
³é”®çš„一部分，它决定了系统是否能够被正确、有效的构建。大家也一直在探索，寻找更优秀的架构设计方式来构建系统。
+一直以来，系统架构设计是IT领域经久
不衰的话题之一，是每个系统构建过程中极其å…
³é”®çš„一部分，它决定了系统是否能够被正确、有效的构建。架构师们也一直在持续探索，寻找更优秀的架构设计方式来构建系统。
 
 
那什么是系统的架构设计？对于这个问题，我相信每个朋友都会有不同的定义，实é™
…上，也并没有一个标准的答案来解释什么是架构设计。
 
@@ -29,7 +30,7 @@ redirect_from:
 随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œ**微服务架构逐渐成为系统架构的一个代名词**。
 
 ## 什么是微服务架构
-2015年，微服务架构这个词，以相当高的频率出现在各种演讲、文ç«
 
、会议、社区上。这里，我就和大家快速回顾一下，老马（Martin
 Folwer）对微服务的定义。
+2015年，微服务架构这个词，以相当高的频率出现在各种演讲、文ç«
 ã€ä¼šè®®ã€ç¤¾åŒºä¸Šã€‚这里，我先和大家快速回顾一下，Martin 
Fowler对微服务的抽象。
 
 ![](/assets/images/microservice_definition_by_martin_folwer.jpeg)
 
@@ -42,11 +43,11 @@ redirect_from:
 ## 微服务的诞生背景
 2015年，微服务突然火了，为什么？
 
-å…
¶å®žå¾®æœåŠ¡æž¶æž„并不是什么技术创新，而是IT发展到现阶段对技术架构的要求。
+å…
¶å®žå¾®æœåŠ¡æž¶æž„并不是技术创新，而是IT发展到现阶段对技术架构的一种阐释。
 
-这个要求包
括**快速和业务对齐（alignbusiness）、快速理解和抽象业务（DDD）、快速开发（Lean、Agile）、快速反馈和交付（CI、CD、DevOps）**。
+它要求包括**快速和业务对齐（aligning 
business）、理解和抽象业务（基于领域建模）、快速开发（Lean、Agile）、快速反馈和交付（CI、CD、DevOps）**。
 
-所以我认为微服务并不是技术，而是将化整为零（或称分治）思想换了一种说法，æ—
 
论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个团队，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。
+所以说，微服务并不是技术，而是将化整为零（或称分治）思想换了一种说法，æ—
 
论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个团队，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。
 
 当然，任何新事物的诞生，总会有一个推动因素
。微服务的诞生也并非偶然。它是互联网高速发展，技术日新月异的变化以及ä¼
 ç»Ÿæž¶æž„无法适应快速变化等多重因素
的推动下所诞生的产物。
 
@@ -184,14 +185,29 @@ redirect_from:
 
 ### 系统概览
 
-系统为典型的三层单块架构，所有业务共用一个数据库。
+系统为å…
¸åž‹çš„三层单块架构，使用MySQL数据库存储数据。运行在服务器上的应用处理性能较低，为了应对短暂的访问高峰，额外购置了较多的服务器资源，访问高峰过后，服务器资源闲置é€
 æˆè¾ƒå¤§æµªè´¹ï¼Œä¸”需要较多人员维护。
 
 ### 相关数据
 
-* 代码约3万行，测试覆盖率为80%，集成测试时间为一个月
-* 营销预案需提前1个月准备资源
-* 业务耦合紧，新业务上线>半年
-* 上百种业务，2-3种开发语言，运维团队>20人
+* 代ç 
çº¦**100万**行，测试覆盖率为**10%**，集成测试时间为**一个月**
+
+   代码臃肿，无效遗留代ç 
è¾ƒå¤šï¼Œä¸”业务间紧耦合，测试覆盖率较低，测试出问题了难以定位，导致测试耗时较长。
+
+* 营销预案需**提前1个月**准备资源
+
+   
为应对访问高峰，每次都需要预购大量的服务资源，重新部署环境，并运行相å
…³æµ‹è¯•ã€‚
+
+* 业务耦合紧，新业务上线**>半年**
+
+   
每次测试都要多个业务团队联合测试，问题定位较耗时，测试效率低。
+
+* 上百种业务，2-3种开发语言
+
+   业务复杂，且语言不一，系统联调时耗时较多且需相互é…
åˆï¼Œæ—¶é—´å‘¨æœŸè¾ƒé•¿ã€‚
+
+* 运维团队**>20人**
+
+   臃肿的团队导致问题定位需多方配合，沟通成本高。
 
 **基于之前定义的改造策略，我们的改造
过程大致如下所示：**
 
@@ -199,9 +215,11 @@ redirect_from:
 
    * 将原房地产CRM平台按业务类别拆分为多个微服务。
 
+      ![](/assets/images/case_mengtuo_reform_before_and_after.png)
+
 功能剥离：
 
-   * 按ç…
§DDD设计理念，从单体CRM系统中逐步拆分出业务模块（服务网å
…³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
+   * 从单体CRM系统中逐步拆分出业务模块（服务网å…
³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
 
 数据解耦
 
@@ -211,28 +229,27 @@ redirect_from:
 
    * 
在负载较低时，将数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务。
 
-改造过程中，ServiceComb的微服务示例项目[Company 
Workshop](https://github.com/ServiceComb/ServiceComb-Company-WorkShop)提供了架构和实é™
…代码参考。复用Company Workshop中的网关，只需更改路由é…
ç½®ï¼Œ 一天内完成了网关服务。参考Company 
Workshop的架构，我们用网关接å…
¥æ‰‹æœºç«¯APP请求，路由给后端服务。**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
+改造
过程中，基于ServiceComb，**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
 
-微服务的改造
也很容易，参考[微服务快速开发博文](http://servicecomb.io/docs/linuxcon-workshop-demo/)，**基于ServiceComb，简单4步，
 1天改造1个微服务：**
+**单个服务的构建并没有那么复杂，基于ServiceComb，通过如下的简单4步，即可快速完成改é€
 ï¼š**
 
 1. 引入[ServiceComb Java 
Chassis](https://github.com/ServiceComb/ServiceComb-Java-Chassis)框架依赖
 2. 定义服务接口端点
 3. 添加服务配置文件
 4. 注释服务启动入口
 
-![](/assets/images/case_mengtuo_reform_before_and_after.png)
 
 另外，通过Company Workshop中提供的Docker插件配置，10分钟内
完成了服务容器化，自动生成镜像。
 
-作为[华为ServiceStage](https://www.huaweicloud.com/product/servicestage.html)的开源微服务解决方案，利用ServiceComb开发的微服务应用可æ—
 ç¼æŽ¥å…
¥ServiceStage，同时享受到微服务治理、容器虚机混编、应用拓扑等能力。
+同时，利用ServiceComb开发的微服务应用，可同时无缝接å…
¥[ServiceStage](https://www.huaweicloud.com/product/servicestage.html)，享受到微服务治理、容器虚机混编、应用拓扑等能力。
 
-盟拓容器虚机混编应用云化方案是盟拓软件基于华为ServiceStage的以云应用为中心的混编管理方案。通过华为的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ ã€æ··ç¼–方案、 
编排调度算法等，帮助系统做云化改造
，云化后的产品和解决方案能够随着参与人数增加
而秒级伸缩，支撑业务峰值和资源利用率。
+为应对短暂的业务高峰，经常需要预购大量的资源来提前部署和验证环境，花费大量的人力物力，且资源利用率极低。å›
 æ­¤ï¼Œè¿›è¡Œäº‘化改造后的产品和解决方案需要å…
·å¤‡éšç€å‚与人数增加
而秒级伸缩，支撑业务峰值和资源利用率的能力。盟拓软件基于华为ServiceStage的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ 
、混编方案、编排调度算法等进行容器虚机混编应用云化改é€
 
，实现了应用的秒级部署和弹性伸缩能力，极大地提高了资源的利用率。
 
 **改造后效果：**
 
-* 运维人力减少80%
-* 资源利用率提升50%，降低运营成本
-* 每秒万级调用链分析能力
+* 运维人力**减少80%**
+* 资源利用率**提升50%**，大幅降低运营成本
+* **每秒万级**调用链分析能力
 * 传统系统和应用平滑改造上云
 * 互联网营销模式，天粒度业务快速创新
 
@@ -246,7 +263,7 @@ redirect_from:
 ![](/assets/images/best_practices_for_legacy_system_reform.jpeg)
 
 ### 基础设施自动化
-原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用AWS作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究AWS以及相关的DevOps配套工具。
+原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用华为ServiceStage作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究华为ServiceStage以及相关的DevOps配套工具。
 
 目前，国内
外有很多优秀的云平台，可以方便的为用户提供基础设施的自动化机制。
 

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/8b91b1a7/_posts/cn/2017-10-23-how-to-reform-a-legacy-system.md
----------------------------------------------------------------------
diff --git a/_posts/cn/2017-10-23-how-to-reform-a-legacy-system.md 
b/_posts/cn/2017-10-23-how-to-reform-a-legacy-system.md
index 2df95d8..3a33c4a 100644
--- a/_posts/cn/2017-10-23-how-to-reform-a-legacy-system.md
+++ b/_posts/cn/2017-10-23-how-to-reform-a-legacy-system.md
@@ -11,16 +11,17 @@ redirect_from:
   - /theme-setup/
 ---
 
-随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œå¾®æœåŠ¡ï¼ˆMicroservices）逐渐成为系统架构的一个代名词。那么微服务是否是业界期å¾
…已久的企业架构解决方案？在对遗留系统进行微服务的改造
过程中存在怎æ 
·çš„困难和挑战，应该注意些什么？在该分享中，王磊将通过实é™
…的案例，跟大家探讨使用微服务改造遗留系统的实践之路。
-1. 什么是微服务
-2. 微服务的诞生背景
-3. 遗留系统的微服务改造策略
-4. 微服务改造之路
+随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œå¾®æœåŠ¡ï¼ˆMicroservices）逐渐成为系统架构的一个代名词。那么微服务是否是业界期å¾
…已久的架构解决方案？在对遗留系统进行微服务的改造
过程中存在怎æ 
·çš„困难和挑战，应该注意些什么？在该分享中，王磊将通过实é™
…的案例，跟大家探讨使用微服务改造遗留系统的实践之路。
+
+* 什么是微服务
+* 微服务的诞生背景
+* 遗留系统的微服务改造策略
+* 微服务改造之路
 
 ## 背景
-首先，请大家思考什么是系统架构设计？
+什么是系统架构设计？
 
-一直以来，系统架构设计是IT领域经久
不衰的话题之一，是每个系统构建过程中极其å…
³é”®çš„一部分，它决定了系统是否能够被正确、有效的构建。大家也一直在探索，寻找更优秀的架构设计方式来构建系统。
+一直以来，系统架构设计是IT领域经久
不衰的话题之一，是每个系统构建过程中极其å…
³é”®çš„一部分，它决定了系统是否能够被正确、有效的构建。架构师们也一直在持续探索，寻找更优秀的架构设计方式来构建系统。
 
 
那什么是系统的架构设计？对于这个问题，我相信每个朋友都会有不同的定义，实é™
…上，也并没有一个标准的答案来解释什么是架构设计。
 
@@ -29,7 +30,7 @@ redirect_from:
 随着RESTful、云计算、DevOps、持续交付等概念的深å…
¥äººå¿ƒï¼Œ**微服务架构逐渐成为系统架构的一个代名词**。
 
 ## 什么是微服务架构
-2015年，微服务架构这个词，以相当高的频率出现在各种演讲、文ç«
 
、会议、社区上。这里，我就和大家快速回顾一下，老马（Martin
 Folwer）对微服务的定义。
+2015年，微服务架构这个词，以相当高的频率出现在各种演讲、文ç«
 ã€ä¼šè®®ã€ç¤¾åŒºä¸Šã€‚这里，我先和大家快速回顾一下，Martin 
Fowler对微服务的抽象。
 
 ![](/assets/images/microservice_definition_by_martin_folwer.jpeg)
 
@@ -42,11 +43,11 @@ redirect_from:
 ## 微服务的诞生背景
 2015年，微服务突然火了，为什么？
 
-å…
¶å®žå¾®æœåŠ¡æž¶æž„并不是什么技术创新，而是IT发展到现阶段对技术架构的要求。
+å…
¶å®žå¾®æœåŠ¡æž¶æž„并不是技术创新，而是IT发展到现阶段对技术架构的一种阐释。
 
-这个要求包
括**快速和业务对齐（alignbusiness）、快速理解和抽象业务（DDD）、快速开发（Lean、Agile）、快速反馈和交付（CI、CD、DevOps）**。
+它要求包括**快速和业务对齐（aligning 
business）、理解和抽象业务（基于领域建模）、快速开发（Lean、Agile）、快速反馈和交付（CI、CD、DevOps）**。
 
-所以我认为微服务并不是技术，而是将化整为零（或称分治）思想换了一种说法，æ—
 
论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个团队，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。
+所以说，微服务并不是技术，而是将化整为零（或称分治）思想换了一种说法，æ—
 
论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个团队，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。
 
 当然，任何新事物的诞生，总会有一个推动因素
。微服务的诞生也并非偶然。它是互联网高速发展，技术日新月异的变化以及ä¼
 ç»Ÿæž¶æž„无法适应快速变化等多重因素
的推动下所诞生的产物。
 
@@ -184,14 +185,29 @@ redirect_from:
 
 ### 系统概览
 
-系统为典型的三层单块架构，所有业务共用一个数据库。
+系统为å…
¸åž‹çš„三层单块架构，使用MySQL数据库存储数据。运行在服务器上的应用处理性能较低，为了应对短暂的访问高峰，额外购置了较多的服务器资源，访问高峰过后，服务器资源闲置é€
 æˆè¾ƒå¤§æµªè´¹ï¼Œä¸”需要较多人员维护。
 
 ### 相关数据
 
-* 代码约3万行，测试覆盖率为80%，集成测试时间为一个月
-* 营销预案需提前1个月准备资源
-* 业务耦合紧，新业务上线>半年
-* 上百种业务，2-3种开发语言，运维团队>20人
+* 代ç 
çº¦**100万**行，测试覆盖率为**10%**，集成测试时间为**一个月**
+
+   代码臃肿，无效遗留代ç 
è¾ƒå¤šï¼Œä¸”业务间紧耦合，测试覆盖率较低，测试出问题了难以定位，导致测试耗时较长。
+
+* 营销预案需**提前1个月**准备资源
+
+   
为应对访问高峰，每次都需要预购大量的服务资源，重新部署环境，并运行相å
…³æµ‹è¯•ã€‚
+
+* 业务耦合紧，新业务上线**>半年**
+
+   
每次测试都要多个业务团队联合测试，问题定位较耗时，测试效率低。
+
+* 上百种业务，2-3种开发语言
+
+   业务复杂，且语言不一，系统联调时耗时较多且需相互é…
åˆï¼Œæ—¶é—´å‘¨æœŸè¾ƒé•¿ã€‚
+
+* 运维团队**>20人**
+
+   臃肿的团队导致问题定位需多方配合，沟通成本高。
 
 **基于之前定义的改造策略，我们的改造
过程大致如下所示：**
 
@@ -199,9 +215,11 @@ redirect_from:
 
    * 将原房地产CRM平台按业务类别拆分为多个微服务。
 
+      ![](/assets/images/case_mengtuo_reform_before_and_after.png)
+
 功能剥离：
 
-   * 按ç…
§DDD设计理念，从单体CRM系统中逐步拆分出业务模块（服务网å
…³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
+   * 从单体CRM系统中逐步拆分出业务模块（服务网å…
³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
 
 数据解耦
 
@@ -211,28 +229,27 @@ redirect_from:
 
    * 
在负载较低时，将数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务。
 
-改造过程中，ServiceComb的微服务示例项目[Company 
Workshop](https://github.com/ServiceComb/ServiceComb-Company-WorkShop)提供了架构和实é™
…代码参考。复用Company Workshop中的网关，只需更改路由é…
ç½®ï¼Œ 一天内完成了网关服务。参考Company 
Workshop的架构，我们用网关接å…
¥æ‰‹æœºç«¯APP请求，路由给后端服务。**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
+改造
过程中，基于ServiceComb，**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
 
-微服务的改造
也很容易，参考[微服务快速开发博文](http://servicecomb.io/docs/linuxcon-workshop-demo/)，**基于ServiceComb，简单4步，
 1天改造1个微服务：**
+**单个服务的构建并没有那么复杂，基于ServiceComb，通过如下的简单4步，即可快速完成改é€
 ï¼š**
 
 1. 引入[ServiceComb Java 
Chassis](https://github.com/ServiceComb/ServiceComb-Java-Chassis)框架依赖
 2. 定义服务接口端点
 3. 添加服务配置文件
 4. 注释服务启动入口
 
-![](/assets/images/case_mengtuo_reform_before_and_after.png)
 
 另外，通过Company Workshop中提供的Docker插件配置，10分钟内
完成了服务容器化，自动生成镜像。
 
-作为[华为ServiceStage](https://www.huaweicloud.com/product/servicestage.html)的开源微服务解决方案，利用ServiceComb开发的微服务应用可æ—
 ç¼æŽ¥å…
¥ServiceStage，同时享受到微服务治理、容器虚机混编、应用拓扑等能力。
+同时，利用ServiceComb开发的微服务应用，可同时无缝接å…
¥[ServiceStage](https://www.huaweicloud.com/product/servicestage.html)，享受到微服务治理、容器虚机混编、应用拓扑等能力。
 
-盟拓容器虚机混编应用云化方案是盟拓软件基于华为ServiceStage的以云应用为中心的混编管理方案。通过华为的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ ã€æ··ç¼–方案、 
编排调度算法等，帮助系统做云化改造
，云化后的产品和解决方案能够随着参与人数增加
而秒级伸缩，支撑业务峰值和资源利用率。
+为应对短暂的业务高峰，经常需要预购大量的资源来提前部署和验证环境，花费大量的人力物力，且资源利用率极低。å›
 æ­¤ï¼Œè¿›è¡Œäº‘化改造后的产品和解决方案需要å…
·å¤‡éšç€å‚与人数增加
而秒级伸缩，支撑业务峰值和资源利用率的能力。盟拓软件基于华为ServiceStage的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ 
、混编方案、编排调度算法等进行容器虚机混编应用云化改é€
 
，实现了应用的秒级部署和弹性伸缩能力，极大地提高了资源的利用率。
 
 **改造后效果：**
 
-* 运维人力减少80%
-* 资源利用率提升50%，降低运营成本
-* 每秒万级调用链分析能力
+* 运维人力**减少80%**
+* 资源利用率**提升50%**，大幅降低运营成本
+* **每秒万级**调用链分析能力
 * 传统系统和应用平滑改造上云
 * 互联网营销模式，天粒度业务快速创新
 
@@ -246,7 +263,7 @@ redirect_from:
 ![](/assets/images/best_practices_for_legacy_system_reform.jpeg)
 
 ### 基础设施自动化
-原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用AWS作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究AWS以及相关的DevOps配套工具。
+原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用华为ServiceStage作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究华为ServiceStage以及相关的DevOps配套工具。
 
 目前，国内
外有很多优秀的云平台，可以方便的为用户提供基础设施的自动化机制。
 

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/8b91b1a7/assets/images/case_mengtuo_new_mode.png
----------------------------------------------------------------------
diff --git a/assets/images/case_mengtuo_new_mode.png 
b/assets/images/case_mengtuo_new_mode.png
index 4b9ddf0..2d43596 100644
Binary files a/assets/images/case_mengtuo_new_mode.png and 
b/assets/images/case_mengtuo_new_mode.png differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/8b91b1a7/assets/images/case_mengtuo_reform_before_and_after.png
----------------------------------------------------------------------
diff --git a/assets/images/case_mengtuo_reform_before_and_after.png 
b/assets/images/case_mengtuo_reform_before_and_after.png
index 12dec8a..c0743ee 100644
Binary files a/assets/images/case_mengtuo_reform_before_and_after.png and 
b/assets/images/case_mengtuo_reform_before_and_after.png differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/8b91b1a7/assets/images/case_mengtuo_traditional_mode.png
----------------------------------------------------------------------
diff --git a/assets/images/case_mengtuo_traditional_mode.png 
b/assets/images/case_mengtuo_traditional_mode.png
index 6daaad2..4f15ad8 100644
Binary files a/assets/images/case_mengtuo_traditional_mode.png and 
b/assets/images/case_mengtuo_traditional_mode.png differ