You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by jb...@apache.org on 2017/12/12 07:05:43 UTC
[25/51] incubator-servicecomb-website git commit: updated statements
for blog legacy system reform
updated statements for blog legacy system reform
Signed-off-by: Eric Lee <da...@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 <da...@huawei.com>
Authored: Tue Nov 14 17:28:19 2017 +0800
Committer: Willem Jiang <ji...@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对微服务的抽象。
@@ -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平台按业务类别拆分为多个微服务。
+ 
+
功能剥离：
- * 按照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. 注释服务启动入口
-
另外，通过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:
### 基础设施自动化
-原有的部署发生在数据中心，因此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改造后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用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对微服务的抽象。
@@ -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平台按业务类别拆分为多个微服务。
+ 
+
功能剥离：
- * 按照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. 注释服务启动入口
-
另外，通过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:
### 基础设施自动化
-原有的部署发生在数据中心，因此流程上相对复杂，而且存在一定弊端（譬如审批和协作上，起不到实质作用）。对于改造后的服务而言，我们使用更多的自动化方式代替复杂的审批流程。通过使用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