如何从传统springmvc架构逐步迁移到微服务架构

最近在技术圈子聊到个关于微服务的话题，存在不少争议，很多人觉得微服务框架根本用不上，但是出去外面找工作面试，不会微服务又基本处于java后台技术文盲。

今天就跟大家探讨下如何从传统springmvc架构逐步迁移到微服务架构。

随着技术的不断更新，我经历了从jsp+java、struts1、struts2、springmvc、再到现在的springboot-dubbo、springboot-cloud，再到service mesh我总结了下，其实任何新的技术都是为了解决系统旧的一些问题而生，没有完美的技术，随着技术的变革，当下认为最好的项目也最终都会成为历史。

以springmvc为代表的技术前几年也是风靡整个IT行业，它解决了原先旧架构的很多问题，如分成架构、还有struts的配置繁琐问题，用起来已经很简单，那还需要升级为微服务架构吗？

如果有以下几点场景，建议可以开始规划微服务架构设计：

1.对微服务技术感兴趣的人员；

2.希望找到一份较好的技术岗位的人；

3.对当前项目想做大做强的项目，就提前考虑架构设计的架构师；

4.当前单体架构已经不满足实际业务场景，不得不做技术的升级改造；

下面我就讲解下如何从传统springmvc架构可以逐步无缝迁移到微服务架构，可以分解成以下几个步骤（哪怕你不做微服务，每个步骤也都是对当前项目的一种优化）：

1.前后端分离

前后端分离可以列为微服务技术的首项工作，也会对项目的耦合度做了很大提升，扩展性也有了很大的提升，而且对服务器的压力也做了一部分的优化，例如很多项目升级只想换换界面，卖给不同的客户，那么前后端分离就能很大体现出优势，当然也为微服务做了铺垫。

2.项目的模块划分

先在单体架构里面，把项目里面的不同模块进行包的划分，数据库、redis、mq等等的中间件一概不动、只把包拆分好移动好，基本对项目没有任何影响，只有一些移动归类包的工作，这步在微服务是否能平稳迁移非常关键。

这里一般有两个维度来划分：1.按照功能模块来划分； 2.按照技术模块抽象划分；

3.逐步抽出特定的模块

抽出模块也是有优先级，并非一下子全部需要做实际的微服务，可按照系统使用的情况，如库存模块使用频率较高，出现系统瓶颈的可能性较高模块，进行微服务开发（主流技术如springboot-dubbo、springcloud-alibaba），过程包括数据库、mq、redis等中间件可以逐步拆出，可保项目平稳度过。

以上就是就是我对微服务架构逐步演变的大致介绍，首次发表技术文章，欢迎大家的评论和提问，未来将更新更多技术分享文章，有兴趣的童鞋可关注下，您的关注是我更新的动力，谢谢！