微服务架构重构是怎样一种“神仙体验”？

如今，很多企业都在进行微服务架构重构，问题是微服务到底是不是最佳选择？如果选择没有问题，微服务在什么时候用?重构之后的技术路线和之前是怎样一种关系？我们应该以什么样的方式，把之前和之后的技术结合起来……相信，这些都是很多开发者在微服务重构过程中，必然会遇到的问题。

在笔者看来，企业在部署架构的时候，看似是遇到问题，解决问题， 但其实要秉承一个原则，那就是“以始为终”，在开始出发前就要知道终点在哪里。具体到微服务架构重构，根本目的是要解决当前架构的问题，最终能让系统支撑业务高质量发展。

重构不可避免

首先，开发者需要明确的一点是，重构不可避免。不管是复杂的应用系统，还是任意一个App，甚至是类似于office这样的软件，都有自己的生命周期。在漫长的生命周期里，业务和需求都在不断变化，最后的需求和最开始的设计，已经完全不一样，当系统现状和大家的认知有严重冲突的时候，不重构系统，软件就难以继续维护开发下去。另外，技术开发本身也在不断变化，比如：在代码层需要不断引入新代码，加入了很多冗余的内容，变得僵硬、脆弱、难以维护，需要开发周期越来越长，Bug越来越多，所以重构成为必然结果。

以具体微服务实践为例，随着长时间、多地辗转，功能越做越大，已经没人了解最初的设计思路和项目初衷；但有一个有意思的现象是，大家在开发新功能的时候，都喜欢把功能放在这个微服务里，开发迭代速度逐渐变慢，Bug环比稳中有升。换言之，随着功能的增加，该微服务退化成了单体架构。

虽然，我们今天都在谈微服务，但其实不管是单体架构还是微服务，都各有优缺点。比如:单体架构虽然不够灵活，但好处是紧凑，你想要什么变量，直接调用对象就可以了，内存是共享状态，使得功能开发变得简单。既然这样，为什么要重构呢？答案是，业务发展是最大推动力！当业务方准备进行一次较大规模的新业务尝试，新业务形式上有很大变化，不过核心业务功能变化不大，但研究团队发现服务复用很困难。

用领域驱动设计驱动系统重构

那么，我们到底以什么样的方式去设计我们的系统？

当项目简单的时候，有两种开发方式：一种是CRUD Design，增删改查，有什么做什么；另一种DomAIn Driven Design，就是我们常说的DDD领域驱动设计。项目简单的时候，CRUD开发成本更低，而DDD设计模式需要把业务领域分析清楚以后，做合适的服务分析，做合适的对象设计，进而通过合适的领域设计去完成。

值得一提的是，CRUD和DDD会有一个交叉点，而业务最终的演进方向一定会向复杂的方向发展。尤其是互联网项目，开始只是做一些简单的业务逻辑实现，之后随着业务的发展，会变得越来越复杂，传统开发方式就会变得艰难。

所以，在使用微服务之前，一定不要指望微服务能做什么，微服务不是灵丹妙药，也不是尚方宝剑，不能解决一切问题。

微服务重构复盘

通过微服务进行系统重构，大概需要六个步骤：

第一，把当前系统设计与问题汇总讨论。比如：架构与代码混乱，需求迭代困难，部署麻烦，Bug频率逐渐升高等等，都汇总在一起。

第二，针对问题分析具体原因。微服务A太庞大，微服务B和C职责不清，团队内业务理解不一致，内部代码设计不良，硬编码和耦合太多……寻找这些问题的具体原因。

第三，重新梳理业务流程，明确业务术语，进行DDD战略设计。比如：活动图，子域分解，限界上下文设计等等，理解这些专业用语，用于战略设计。

第四，针对当前系统实现和DDD设计不匹配的地方设计微服务重构方案。

第五，DDD战术设计与技术验证，比如：聚合、实体、值对象设计、打样代码开发。

第六，任务分解与持续重构，在不影响业务开发的前提下，按照战略与战术设计，将重构开发和业务迭代有机结合。

需要重点强调的是，不管是微服务，还是单体服务，任何技术都一样，都是解决特定问题的一个具体方法。而其中，微服务的正确解法是，先分析问题，再找合适的方案。大体来看，微服务的真正难点不是技术，而是业务。技术问题解决起来非常容易，但业务问题不好梳理。企业需要先解决业务问题，重新梳理业务，再找合适的工具和方法。