[20/51] incubator-servicecomb-website git commit: updated blog statements

[jbonofre]

updated blog statements

Signed-off-by: eric-lee-ltk <lidaga...@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/b04abded
Tree: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/tree/b04abded
Diff: 
http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/diff/b04abded

Branch: refs/heads/asf-site
Commit: b04abdedcfbf9bcff315eae259f30b2086f27ce5
Parents: 4df516f
Author: eric-lee-ltk <lidaga...@huawei.com>
Authored: Thu Nov 2 09:02:19 2017 +0800
Committer: Willem Jiang <jiangni...@huawei.com>
Committed: Fri Nov 3 08:11:28 2017 -0700

----------------------------------------------------------------------
 .../2017-10-23-how-to-reform-a-legacy-system.md | 125 ++++++++-----------
 .../2017-10-23-how-to-reform-a-legacy-system.md | 125 ++++++++-----------
 assets/images/case_mengtuo_new_mode.png         | Bin 0 -> 71137 bytes
 .../case_mengtuo_reform_before_and_after.png    | Bin 0 -> 169124 bytes
 assets/images/case_mengtuo_traditional_mode.png | Bin 0 -> 63155 bytes
 assets/images/legacy_system_background.jpeg     | Bin 19848 -> 0 bytes
 .../legacy_system_reform_architecture.jpeg      | Bin 22413 -> 0 bytes
 assets/images/rapid_development_framework.png   | Bin 0 -> 152219 bytes
 ...pid_development_framework_based_on_ruby.jpeg | Bin 28266 -> 0 bytes
 9 files changed, 104 insertions(+), 146 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/_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 c2f4d7d..54d1c0f 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
@@ -172,83 +172,71 @@ redirect_from:
 ## 遗留系统改造实践 
 接下来，我和大家分享一个我所经历的遗留系统改造
的案例。首先，让我们看看这个系统的背景和一些数据。
 
-![](/assets/images/legacy_system_background.jpeg)
-
 ### 客户背景
 
-澳洲最大的房产门户，业务涉及个人房产、商业房产、土地交易、买卖租赁、业务运行在7个国家。
-
-8年前基于第三方平台二次开发的业务支撑系统，随着企业的高速发展，维护成本增åŠ
 
，新需求交付周期长，系统逐渐成为阻碍企业高速发展的瓶颈。
+[盟拓软件](http://movit-tech.com/)是中国房地产行业IT服务及行业解决方案和产品的领å
…ˆåŽ‚家，其依据市场变化推出å…
¨æ°‘卖房的新营销模式，正从线下的传
统现场售楼模式向线上的房地产电商模式进行转变。
 
 ### 业务痛点
 
-对于每10万å…
ƒé¢åº¦çš„合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。当时年销售额为4亿，随着业务量的快速增长，签订合同的人力成本在66人年，这还是不考虑管理、沟通等成本，å›
 æ­¤æˆæœ¬æ€¥å‰§å¢žåŠ ã€‚
+当今房地产行业呈现短期开盘峰值、后期零星散客的业务特性。å
…¶é¢ä¸´ç€é«˜æ˜‚线下运营成本，营销成本占
销售额>5%。而由此引入的线上竞价秒杀营销模式，传
统IT解决方案的系统资源率、峰值扩容能力将无法满足。
+
+![](/assets/images/case_mengtuo_traditional_mode.png)
 
 ### 系统概览
 
-系统为å…
¸åž‹çš„三层单块架构，主从数据库运行在数据中心的虚拟机上。开发和运维团队属于两个独立部门，部署时需要提交文档，记录部署流程、细节以及潜在风险，然后提交审批，获取批准后由运维团队排期并完成部署。
+系统为典型的三层单块架构，所有业务共用一个数据库。
 
 ### 相关数据
 
-* 400K行代码
-
-   系统涉及订单、用户、产品、价æ 
¼ã€åˆåŒã€å¤šå›½ä¸šåŠ¡æ”¯æ’‘ç­‰
-
-* 11名团队成员
-
-   
以开发和测试为主，每2周交付一个版本给运维部门，以修复缺陷为主，也会有新特性需求。
-
-* 30% 单元测试覆盖率
-
-   系统功能繁杂，二次开发封装了很多库，单å…
ƒæµ‹è¯•è¦†ç›–率低。
-
-   无效功能的代码长期不清理，核心人员离职或者换岗，因
此，大部分功能用集成和功能测试来验证。
-
-* 50分钟持续集成
-
-   
持续集成的大部分时间都用来运行集成/功能测试，同时创建很多任务，用于检测不同系统间的数据一致性。
-
-* 3天部署
-
-   交付版本给运维部门后，需要相å…
³äººå‘˜å®¡æ‰¹ï¼ŒæŽˆæƒåŽæŽ’期进行部署，从提交到部署生效，通常需要2~3天。
+* 代码约3万行，测试覆盖率为80%，集成测试时间为一个月
+* 营销预案需提前1个月准备资源
+* 业务耦合紧，新业务上线>半年
+* 上百种业务，2-3种开发语言，运维团队>20人
 
 **基于之前定义的改造策略，我们的改造
过程大致如下所示：**
 
 范围定义：
 
-   * 将合同相关部分作为改造的业务范围
-
-   * 将团队中3人+外部引入的2人作为微服务改造团队
+   * 将原房地产CRM平台按业务类别拆分为多个微服务。
 
 功能剥离：
 
-   * 首先剥离合同签署部分，提供在线签署合同系统（H5+JS）
-
-   * 提供合同签署后的存储服务，记录用户在线签署的合同
+   * 按ç…
§DDD设计理念，从单体CRM系统中逐步拆分出业务模块（服务网å
…³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
 
 数据解耦
 
-   * 将用户在线签署的合同数据独立存储
+   * 每个微服务的数据进行独立存储。
 
 数据同步
 
-   * 
在夜间负载较低的时候，将签署的合同数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务
+   * 
在负载较低时，将数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务。
+
+改造过程中，ServiceComb的微服务示例项目[Company 
Workshop](https://github.com/ServiceComb/ServiceComb-Company-WorkShop)提供了架构和实é™
…代码参考。复用Company Workshop中的网关，只需更改路由é…
ç½®ï¼Œ 一天内完成了网关服务。参考Company 
Workshop的架构，我们用网关接å…
¥æ‰‹æœºç«¯APP请求，路由给后端服务。**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
 
-   * 
实现合同服务，并构建前后端分离的H5+JS应用，为合同部门提供合同管理后台
+微服务的改造
也很容易，参考[微服务快速开发博文](http://servicecomb.io/docs/linuxcon-workshop-demo/)，**基于ServiceComb，简单4步，
 1天改造1个微服务：**
 
-   * 定义合同pdf生成器，完成pdf的存储和下载
+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分钟内
完成了服务容器化，自动生成镜像。
 
-![](/assets/images/legacy_system_reform_architecture.jpeg)
+作为[华为ServiceStage](https://www.huaweicloud.com/product/servicestage.html)的开源微服务解决方案，利用ServiceComb开发的微服务应用可æ—
 ç¼æŽ¥å…
¥ServiceStage，同时享受到微服务治理、容器虚机混编、应用拓扑等能力。
 
-可以看到，合同签署的业务已经被拆分出来，同时合同签署的数据也被独立出来，但由于原有遗留系统的复杂度以及数据相å
…
³ä¾èµ–，我们需要将合同的签署数据同步到遗留系统的数据库中。
+盟拓容器虚机混编应用云化方案是盟拓软件基于华为ServiceStage的以云应用为中心的混编管理方案。通过华为的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ ã€æ··ç¼–方案、 
编排调度算法等，帮助系统做云化改造
，云化后的产品和解决方案能够随着参与人数增加
而秒级伸缩，支撑业务峰值和资源利用率。
 
-当然，这只是我的个案中用到，大家可以在改造
的过程中，结合具体的业务场景中，考虑是否需要这æ 
·çš„数据同步机制。
+**改造后效果：**
 
-对于当前这个例子，如果不做数据的同步，则需要更长的时间分析并解耦合同数据同原有遗留系统的依赖，å›
 æ­¤ä¹Ÿå¯ä»¥çœ‹å‡ºï¼ŒåŒæ­¥æ˜¯ä¸ºäº†å¸®åŠ©æˆ‘们尽快的使改造
后的服务体现价值。
+* 运维人力减少80%
+* 资源利用率提升50%，降低运营成本
+* 每秒万级调用链分析能力
+* 传统系统和应用平滑改造上云
+* 互联网营销模式，天粒度业务快速创新
+
+![](/assets/images/case_mengtuo_new_mode.png)
 
 
**理论上，经过不断地迭代，逐渐完成业务功能解耦，新服务构建。那么遗留系统就会被替换掉。**
 
@@ -258,52 +246,45 @@ redirect_from:
 ![](/assets/images/best_practices_for_legacy_system_reform.jpeg)
 
 ### 基础设施自动化
-
 原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用AWS作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究AWS以及相关的DevOps配套工具。
 
 目前，国内
外有很多优秀的云平台，可以方便的为用户提供基础设施的自动化机制。
 
 ### 微服务生态系统
-
 微服务的生态系统是指微服务实施过程相å…
³çš„协作部分，涉及部分较多，譬如测试机制、持续集成、自动化部署、细粒度监控、日志聚合、告警、持续交付，以及大家非常å
…³æ³¨çš„服务注册、服务发现机制等。
 
-这部分的灵活性比较大，因
为目前如上说的每一个领域都有很多优秀的工å…
·ã€‚譬如日志聚合目前业界的方案通常为ELK、AWS的部署使用CloudFormation更灵活，监控的方案如Zabbix、NewRelic、CloudWatch等，成熟的监控工å
…·éƒ½å…
·æœ‰å‘Šè­¦åŠŸèƒ½ï¼ŒPagerDuty也提供更专业的告警服务。服务注册和发现有Eureka，Consul,Zookeeper。大家可以在各自的团队中自由发挥。
+这部分的灵活性比较大，因
为目前如上说的每一个领域都有很多优秀的工å…
·ã€‚譬如日志聚合目前业界的方案通常为ELK，监控的方案如Zabbix、NewRelic、CloudWatch等，成熟的监控工å
…·éƒ½å…
·æœ‰å‘Šè­¦åŠŸèƒ½ï¼ŒPagerDuty也提供更专业的告警服务。服务注册和发现有ServiceComb框架的Service
 
Center，Eureka，Consul，Zookeeper。大家可以在各自的团队中自由发挥。
 
 ### 开发框架的演进
-
 
开发框架是团队在构建微服务的过程中，不断总结，梳理出的快速开发微服务的相å
…³å·¥å…·å’Œæ¡†æž¶ã€‚
 
-我们基于Ruby构建了快速开发框架，主要包
括四部分，如下图所示：
+我们基于ServiceComb构建了快速开发框架，主要包
括四部分，如下图所示：
 
-![](/assets/images/rapid_development_framework_based_on_ruby.jpeg)
+![](/assets/images/rapid_development_framework.png)
 
-1. 开发模板
+1. 微服务工程示例
 
-   
使用Grape作为Web框架，HAL作为API通信规约，RSpec作为测试框架。同时，还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的服务生成RPM/AMI镜像等。
-   
-   除此之外，该模板也提供了一组通用的URL，帮助使用者
查看微服务的版本、é…
ç½®ä¿¡æ¯ä»¥åŠæ£€æµ‹æ˜¯å¦å¥åº·è¿è¡Œç­‰ã€‚譬如/diagnostic/config, 
/health, /version, /heartbeat
+   提供微服务改造
架构最佳实践参考工程Company，使能微服务改造
或开发能复用其架构设计和é…
ç½®ï¼ŒåŒæ—¶æŒ‡å¯¼å®žçŽ°æœåŠ¡å®¹å™¨åŒ–和后续服务性能测试等提高服务可é
 æ€§ã€‚
 
-2. 代码生成工具
+2. 契约生成工具
 
-   通过指定不同参数，代码生成工具能创建å…
·æœ‰æ•°æ®åº“访问能力，或者是包
含异步队列处理的微服务应用。同时，也可以æ 
‡è®°è¯¥æœåŠ¡æ˜¯æ•°æ®æ¶ˆè´¹è€…还是数据生产者
，帮助理解多个微服务之间的联系
+   
ServiceComb采用了基于OpenAPI的服务契约，使业务逻辑与编程语言解耦，并可使用Swaggerå·¥å
…·å®šä¹‰æœåŠ¡å¥‘约，自动生成契约对应的代码和文档。
 
-3. 持续集成模板
+3. 持续集成
 
-   
基于持续集成服务器Bamboo，创建了模板工程，并定义主要的阶段：
-   
-   > 验证：运行单元测试，契约测试
+   持续集成使用了Jenkins，通过其配置文件定义主要的阶段：
+
+   > 验证：运行单元测试，集成测试
    >
-   > 构建：构建基于AMI的部署包
+   > 构建：构建可执行的jar部署包
    >
-   > 部署：基于指定版本的AMI，快速部署到验收环境或者
产品环境上。
+   > 
部署：基于指定版本制作镜像，并推送到测试或生产环境下
 
    利用这æ 
·çš„持续集成模板工程，花费很少的时间，就可以针对新建的微服务应用，快速é
…ç½®å…¶å¯¹åº”的持续集成环境。
+   
+4. Kubernetes集群一键部署
 
-4. 基于Asgard的部署工具
-
-   Asgard是由Netflix开发的基于Web的AWS云部署和管理工å…
·ã€‚基于Asgard，我们实现了命令行部署工å…
·ï¼Œéƒ¨ç½²æ—¶é€šè¿‡ä¸€æ¡å‘½ä»¤ï¼Œæä¾›æœåŠ¡åç§°ã€ç‰ˆæœ¬å·ï¼Œå°±å¯è‡ªåŠ¨å®Œæˆèµ„源的创建、部署、流量切换、åˆ
 é™¤æ—§çš„应用等操作。譬如：
-
-   > deploy [ServiceName] [ServiceVersion]
+   Kubernetes是谷歌开源的一个容器集群管理工å…
·ã€‚基于Kubernetes，可实现微服务的快速部署及弹性伸缩。我们提供了一键部署脚本，部署时只需稍作修改即可通过一条命令，自动完成资源的创建、部署、弹性伸缩、金丝雀发布等。
 
 ### 团队运维自管理
 
@@ -319,12 +300,10 @@ redirect_from:
    
 
最后，和大家分享一下，我个人在微服务实施过程中总结的4句方针:
 
-由大到小，由粗到细
-
-关注运维，关注监控
+**由大到小，由粗到细**
 
-快速反馈，快速修复
+**关注运维，关注监控**
 
-循序渐进，增量实现
+**快速反馈，快速修复**
 
-也希望大家能够支持我的书《微服务架构与实践》。
+**循序渐进，增量实现**

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/_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 30680e0..2df95d8 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
@@ -172,83 +172,71 @@ redirect_from:
 ## 遗留系统改造实践 
 接下来，我和大家分享一个我所经历的遗留系统改造
的案例。首先，让我们看看这个系统的背景和一些数据。
 
-![](/assets/images/legacy_system_background.jpeg)
-
 ### 客户背景
 
-澳洲最大的房产门户，业务涉及个人房产、商业房产、土地交易、买卖租赁、业务运行在7个国家。
-
-8年前基于第三方平台二次开发的业务支撑系统，随着企业的高速发展，维护成本增åŠ
 
，新需求交付周期长，系统逐渐成为阻碍企业高速发展的瓶颈。
+[盟拓软件](http://movit-tech.com/)是中国房地产行业IT服务及行业解决方案和产品的领å
…ˆåŽ‚家，其依据市场变化推出å…
¨æ°‘卖房的新营销模式，正从线下的传
统现场售楼模式向线上的房地产电商模式进行转变。
 
 ### 业务痛点
 
-对于每10万å…
ƒé¢åº¦çš„合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。当时年销售额为4亿，随着业务量的快速增长，签订合同的人力成本在66人年，这还是不考虑管理、沟通等成本，å›
 æ­¤æˆæœ¬æ€¥å‰§å¢žåŠ ã€‚
+当今房地产行业呈现短期开盘峰值、后期零星散客的业务特性。å
…¶é¢ä¸´ç€é«˜æ˜‚线下运营成本，营销成本占
销售额>5%。而由此引入的线上竞价秒杀营销模式，传
统IT解决方案的系统资源率、峰值扩容能力将无法满足。
+
+![](/assets/images/case_mengtuo_traditional_mode.png)
 
 ### 系统概览
 
-系统为å…
¸åž‹çš„三层单块架构，主从数据库运行在数据中心的虚拟机上。开发和运维团队属于两个独立部门，部署时需要提交文档，记录部署流程、细节以及潜在风险，然后提交审批，获取批准后由运维团队排期并完成部署。
+系统为典型的三层单块架构，所有业务共用一个数据库。
 
 ### 相关数据
 
-* 400K行代码
-
-   系统涉及订单、用户、产品、价æ 
¼ã€åˆåŒã€å¤šå›½ä¸šåŠ¡æ”¯æ’‘ç­‰
-
-* 11名团队成员
-
-   
以开发和测试为主，每2周交付一个版本给运维部门，以修复缺陷为主，也会有新特性需求。
-
-* 30% 单元测试覆盖率
-
-   系统功能繁杂，二次开发封装了很多库，单å…
ƒæµ‹è¯•è¦†ç›–率低。
-
-   无效功能的代码长期不清理，核心人员离职或者换岗，因
此，大部分功能用集成和功能测试来验证。
-
-* 50分钟持续集成
-
-   
持续集成的大部分时间都用来运行集成/功能测试，同时创建很多任务，用于检测不同系统间的数据一致性。
-
-* 3天部署
-
-   交付版本给运维部门后，需要相å…
³äººå‘˜å®¡æ‰¹ï¼ŒæŽˆæƒåŽæŽ’期进行部署，从提交到部署生效，通常需要2~3天。
+* 代码约3万行，测试覆盖率为80%，集成测试时间为一个月
+* 营销预案需提前1个月准备资源
+* 业务耦合紧，新业务上线>半年
+* 上百种业务，2-3种开发语言，运维团队>20人
 
 **基于之前定义的改造策略，我们的改造
过程大致如下所示：**
 
 范围定义：
 
-   * 将合同相关部分作为改造的业务范围
-
-   * 将团队中3人+外部引入的2人作为微服务改造团队
+   * 将原房地产CRM平台按业务类别拆分为多个微服务。
 
 功能剥离：
 
-   * 首先剥离合同签署部分，提供在线签署合同系统（H5+JS）
-
-   * 提供合同签署后的存储服务，记录用户在线签署的合同
+   * 按ç…
§DDD设计理念，从单体CRM系统中逐步拆分出业务模块（服务网å
…³ã€å®¢æˆ·æœåŠ¡ã€æˆ¿æºæœåŠ¡ã€æœºä¼šæœåŠ¡ã€ç§¯åˆ†æœåŠ¡ï¼‰ã€‚
 
 数据解耦
 
-   * 将用户在线签署的合同数据独立存储
+   * 每个微服务的数据进行独立存储。
 
 数据同步
 
-   * 
在夜间负载较低的时候，将签署的合同数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务
+   * 
在负载较低时，将数据同步回原有的遗留系统中不断迭代，陆续完成后续的服务。
+
+改造过程中，ServiceComb的微服务示例项目[Company 
Workshop](https://github.com/ServiceComb/ServiceComb-Company-WorkShop)提供了架构和实é™
…代码参考。复用Company Workshop中的网关，只需更改路由é…
ç½®ï¼Œ 一天内完成了网关服务。参考Company 
Workshop的架构，我们用网关接å…
¥æ‰‹æœºç«¯APP请求，路由给后端服务。**通过控制请求路由，逐步架空对原单体应用的请求，
 平滑过渡系统到微服务架构。**
 
-   * 
实现合同服务，并构建前后端分离的H5+JS应用，为合同部门提供合同管理后台
+微服务的改造
也很容易，参考[微服务快速开发博文](http://servicecomb.io/docs/linuxcon-workshop-demo/)，**基于ServiceComb，简单4步，
 1天改造1个微服务：**
 
-   * 定义合同pdf生成器，完成pdf的存储和下载
+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分钟内
完成了服务容器化，自动生成镜像。
 
-![](/assets/images/legacy_system_reform_architecture.jpeg)
+作为[华为ServiceStage](https://www.huaweicloud.com/product/servicestage.html)的开源微服务解决方案，利用ServiceComb开发的微服务应用可æ—
 ç¼æŽ¥å…
¥ServiceStage，同时享受到微服务治理、容器虚机混编、应用拓扑等能力。
 
-可以看到，合同签署的业务已经被拆分出来，同时合同签署的数据也被独立出来，但由于原有遗留系统的复杂度以及数据相å
…
³ä¾èµ–，我们需要将合同的签署数据同步到遗留系统的数据库中。
+盟拓容器虚机混编应用云化方案是盟拓软件基于华为ServiceStage的以云应用为中心的混编管理方案。通过华为的æ
 ¸å¿ƒæŠ€æœ¯å®¹å™¨æ”¹é€ ã€æ··ç¼–方案、 
编排调度算法等，帮助系统做云化改造
，云化后的产品和解决方案能够随着参与人数增加
而秒级伸缩，支撑业务峰值和资源利用率。
 
-当然，这只是我的个案中用到，大家可以在改造
的过程中，结合具体的业务场景中，考虑是否需要这æ 
·çš„数据同步机制。
+**改造后效果：**
 
-对于当前这个例子，如果不做数据的同步，则需要更长的时间分析并解耦合同数据同原有遗留系统的依赖，å›
 æ­¤ä¹Ÿå¯ä»¥çœ‹å‡ºï¼ŒåŒæ­¥æ˜¯ä¸ºäº†å¸®åŠ©æˆ‘们尽快的使改造
后的服务体现价值。
+* 运维人力减少80%
+* 资源利用率提升50%，降低运营成本
+* 每秒万级调用链分析能力
+* 传统系统和应用平滑改造上云
+* 互联网营销模式，天粒度业务快速创新
+
+![](/assets/images/case_mengtuo_new_mode.png)
 
 
**理论上，经过不断地迭代，逐渐完成业务功能解耦，新服务构建。那么遗留系统就会被替换掉。**
 
@@ -258,52 +246,45 @@ redirect_from:
 ![](/assets/images/best_practices_for_legacy_system_reform.jpeg)
 
 ### 基础设施自动化
-
 原有的部署发生在数据中心，因
此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改é€
 
后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用AWS作为基础设施，团队能够更自主的对基础设施进行管理。如资源创建、销毁、更新等。随着服务的增多，基础设施自动化帮助我们节省了大量的时间。当然，从组织层面，也成立了专门的小组ç
 ”究AWS以及相关的DevOps配套工具。
 
 目前，国内
外有很多优秀的云平台，可以方便的为用户提供基础设施的自动化机制。
 
 ### 微服务生态系统
-
 微服务的生态系统是指微服务实施过程相å…
³çš„协作部分，涉及部分较多，譬如测试机制、持续集成、自动化部署、细粒度监控、日志聚合、告警、持续交付，以及大家非常å
…³æ³¨çš„服务注册、服务发现机制等。
 
-这部分的灵活性比较大，因
为目前如上说的每一个领域都有很多优秀的工å…
·ã€‚譬如日志聚合目前业界的方案通常为ELK、AWS的部署使用CloudFormation更灵活，监控的方案如Zabbix、NewRelic、CloudWatch等，成熟的监控工å
…·éƒ½å…
·æœ‰å‘Šè­¦åŠŸèƒ½ï¼ŒPagerDuty也提供更专业的告警服务。服务注册和发现有Eureka，Consul,Zookeeper。大家可以在各自的团队中自由发挥。
+这部分的灵活性比较大，因
为目前如上说的每一个领域都有很多优秀的工å…
·ã€‚譬如日志聚合目前业界的方案通常为ELK，监控的方案如Zabbix、NewRelic、CloudWatch等，成熟的监控工å
…·éƒ½å…
·æœ‰å‘Šè­¦åŠŸèƒ½ï¼ŒPagerDuty也提供更专业的告警服务。服务注册和发现有ServiceComb框架的Service
 
Center，Eureka，Consul，Zookeeper。大家可以在各自的团队中自由发挥。
 
 ### 开发框架的演进
-
 
开发框架是团队在构建微服务的过程中，不断总结，梳理出的快速开发微服务的相å
…³å·¥å…·å’Œæ¡†æž¶ã€‚
 
-我们基于Ruby构建了快速开发框架，主要包
括四部分，如下图所示：
+我们基于ServiceComb构建了快速开发框架，主要包
括四部分，如下图所示：
 
-![](/assets/images/rapid_development_framework_based_on_ruby.jpeg)
+![](/assets/images/rapid_development_framework.png)
 
-1. 开发模板
+1. 微服务工程示例
 
-   
使用Grape作为Web框架，HAL作为API通信规约，RSpec作为测试框架。同时，还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的服务生成RPM/AMI镜像等。
-   
-   除此之外，该模板也提供了一组通用的URL，帮助使用者
查看微服务的版本、é…
ç½®ä¿¡æ¯ä»¥åŠæ£€æµ‹æ˜¯å¦å¥åº·è¿è¡Œç­‰ã€‚譬如/diagnostic/config, 
/health, /version, /heartbeat
+   提供微服务改造
架构最佳实践参考工程Company，使能微服务改造
或开发能复用其架构设计和é…
ç½®ï¼ŒåŒæ—¶æŒ‡å¯¼å®žçŽ°æœåŠ¡å®¹å™¨åŒ–和后续服务性能测试等提高服务可é
 æ€§ã€‚
 
-2. 代码生成工具
+2. 契约生成工具
 
-   通过指定不同参数，代码生成工具能创建å…
·æœ‰æ•°æ®åº“访问能力，或者是包
含异步队列处理的微服务应用。同时，也可以æ 
‡è®°è¯¥æœåŠ¡æ˜¯æ•°æ®æ¶ˆè´¹è€…还是数据生产者
，帮助理解多个微服务之间的联系
+   
ServiceComb采用了基于OpenAPI的服务契约，使业务逻辑与编程语言解耦，并可使用Swaggerå·¥å
…·å®šä¹‰æœåŠ¡å¥‘约，自动生成契约对应的代码和文档。
 
-3. 持续集成模板
+3. 持续集成
 
-   
基于持续集成服务器Bamboo，创建了模板工程，并定义主要的阶段：
-   
-   > 验证：运行单元测试，契约测试
+   持续集成使用了Jenkins，通过其配置文件定义主要的阶段：
+
+   > 验证：运行单元测试，集成测试
    >
-   > 构建：构建基于AMI的部署包
+   > 构建：构建可执行的jar部署包
    >
-   > 部署：基于指定版本的AMI，快速部署到验收环境或者
产品环境上。
+   > 
部署：基于指定版本制作镜像，并推送到测试或生产环境下
 
    利用这æ 
·çš„持续集成模板工程，花费很少的时间，就可以针对新建的微服务应用，快速é
…ç½®å…¶å¯¹åº”的持续集成环境。
+   
+4. Kubernetes集群一键部署
 
-4. 基于Asgard的部署工具
-
-   Asgard是由Netflix开发的基于Web的AWS云部署和管理工å…
·ã€‚基于Asgard，我们实现了命令行部署工å…
·ï¼Œéƒ¨ç½²æ—¶é€šè¿‡ä¸€æ¡å‘½ä»¤ï¼Œæä¾›æœåŠ¡åç§°ã€ç‰ˆæœ¬å·ï¼Œå°±å¯è‡ªåŠ¨å®Œæˆèµ„源的创建、部署、流量切换、åˆ
 é™¤æ—§çš„应用等操作。譬如：
-
-   > deploy [ServiceName] [ServiceVersion]
+   Kubernetes是谷歌开源的一个容器集群管理工å…
·ã€‚基于Kubernetes，可实现微服务的快速部署及弹性伸缩。我们提供了一键部署脚本，部署时只需稍作修改即可通过一条命令，自动完成资源的创建、部署、弹性伸缩、金丝雀发布等。
 
 ### 团队运维自管理
 
@@ -319,12 +300,10 @@ redirect_from:
    
 
最后，和大家分享一下，我个人在微服务实施过程中总结的4句方针:
 
-由大到小，由粗到细
-
-关注运维，关注监控
+**由大到小，由粗到细**
 
-快速反馈，快速修复
+**关注运维，关注监控**
 
-循序渐进，增量实现
+**快速反馈，快速修复**
 
-也希望大家能够支持我的书《微服务架构与实践》。
+**循序渐进，增量实现**

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/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
new file mode 100644
index 0000000..4b9ddf0
Binary files /dev/null and b/assets/images/case_mengtuo_new_mode.png differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/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
new file mode 100644
index 0000000..12dec8a
Binary files /dev/null and 
b/assets/images/case_mengtuo_reform_before_and_after.png differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/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
new file mode 100644
index 0000000..6daaad2
Binary files /dev/null and b/assets/images/case_mengtuo_traditional_mode.png 
differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/assets/images/legacy_system_background.jpeg
----------------------------------------------------------------------
diff --git a/assets/images/legacy_system_background.jpeg 
b/assets/images/legacy_system_background.jpeg
deleted file mode 100644
index 528710d..0000000
Binary files a/assets/images/legacy_system_background.jpeg and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/assets/images/legacy_system_reform_architecture.jpeg
----------------------------------------------------------------------
diff --git a/assets/images/legacy_system_reform_architecture.jpeg 
b/assets/images/legacy_system_reform_architecture.jpeg
deleted file mode 100644
index 66c6597..0000000
Binary files a/assets/images/legacy_system_reform_architecture.jpeg and 
/dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/assets/images/rapid_development_framework.png
----------------------------------------------------------------------
diff --git a/assets/images/rapid_development_framework.png 
b/assets/images/rapid_development_framework.png
new file mode 100644
index 0000000..1f8ae21
Binary files /dev/null and b/assets/images/rapid_development_framework.png 
differ

http://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website/blob/b04abded/assets/images/rapid_development_framework_based_on_ruby.jpeg
----------------------------------------------------------------------
diff --git a/assets/images/rapid_development_framework_based_on_ruby.jpeg 
b/assets/images/rapid_development_framework_based_on_ruby.jpeg
deleted file mode 100644
index 942b913..0000000
Binary files a/assets/images/rapid_development_framework_based_on_ruby.jpeg and 
/dev/null differ