最头疼的遗留系统该如何进行微服务改造？

随着RESTful、云计算、DevOps、持续交付等概念的深入人心，微服务（Microservices）逐渐成为系统架构的一个代名词。那么微服务是否是业界期待已久的企业架构解决方案？在对遗留系统进行微服务的改造过程中存在怎样的困难和挑战，应该注意些什么？在该分享中，王磊将通过实际的案例，跟大家探讨使用微服务改造遗留系统的实践之路。

·        什么是微服务

·        微服务的诞生背景

·        遗留系统的微服务改造策略

·        微服务改造之路

背景

首先，请大家思考什么是系统架构设计？

一直以来，系统架构设计是IT领域经久不衰的话题之一，是每个系统构建过程中极其关键的一部分，它决定了系统是否能够被正确、有效的构建。大家也一直在探索，寻找更优秀的架构设计方式来构建系统。

那什么是系统的架构设计？对于这个问题，我相信每个朋友都会有不同的定义，实际上，也并没有一个标准的答案来解释什么是架构设计。

基于我过去的经验和工作方式，我认为系统架构设计的本质，是在应用系统内部找到这样一个动态平衡：平衡业务、技术、团队的同时，考虑系统灵活性、可扩展性以及可维护性等因素，并将应用系统划分成不同的部分，使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。

随着RESTful、云计算、DevOps、持续交付等概念的深入人心，微服务架构逐渐成为系统架构的一个代名词。

 

什么是微服务架构

 

2015年，微服务架构这个词，以相当高的频率出现在各种演讲、文章、会议、社区上。这里，我就和大家快速回顾一下，老马（Martin Folwer）对微服务的定义中认为，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。 每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。 另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

总结成一句话就是微服务是围绕业务构建的细粒度的分布式系统。

 

微服务的诞生背景

2015年，微服务突然火了，为什么？

其实微服务架构并不是什么技术创新，而是IT发展到现阶段对技术架构的要求。

这个要求包括快速和业务对齐（alignbusiness）、快速理解和抽象业务（DDD）、快速开发（Lean、Agile）、快速反馈和交付（CI、CD、DevOps）。

所以我认为微服务并不是技术，而是将化整为零（或称分治）思想换了一种说法，无论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个团队，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。

当然，任何新事物的诞生，总会有一个推动因素。微服务的诞生也并非偶然。它是互联网高速发展，技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下所诞生的产物。

基于个人的理解，我将微服务的诞生因素总结为如下几点：

 

1、互联网行业的快速发展

过去的十年中，互联网对我们的生活产生了翻天覆地的变化，越来越多的传统行业公司也开始依赖互联网技术打造其核心竞争优势。

在这种情况下，如何从系统架构的角度出发，构建灵活、易扩展的系统，快速应对需求的变化；同时，随着用户量的增加，如何保证系统的可伸缩性、高可用性，成为系统架构面临的挑战。

2、单块架构系统面临的挑战

随着用户需求个性化、产品生命周期变短、市场需求不稳定等因素的出现，单块架构系统面临着越来越多的挑战。如何找到一种更有效的、更灵活、适应需求的系统架构方式，成为大家关注的焦点。

3、敏捷、精益方法