单体应用的微服务转型

在博主工作的经历中曾经接受过一个历史超过15年的单体应用程序，其代码行数超过四百万，使用的技术五花八门。并且由于项目太大，也带来了很多问题:

1. 运行测试的时间非常之久，要实现CI/CD几乎是一件不可能的事情。
2. 项目前后端耦合在一起
3. 项目使用的框架尤其是前端五花八门，难以管理
4. 项目启动耗时长，开发效率低

项目的开发者管理人员当然也意识到了这个问题，但是由于项目已经有很多客户在使用，因此要进行微服务转型必须考虑客户不受到影响，因此进行微服务转型并不是一件容易的事情，但是在项目内部的所有人都意识到转型到微服务的架构是必须完成的事情，因为项目过于庞大带来的问题已经对项目的新功能的开发，测试和交付带来了巨大的障碍。

这样的问题存在于软件行业许多的系统当中。毕竟软件先于微服务的概念诞生。

一种不推荐使用的策略是进行“大爆炸”重写。这种方式是，将所有开发工作都集中在从头开始构建新的基于微服务的应用程序上。尽管听起来很吸引人，但它极具风险，并且很可能会以失败告终。Martin Fowler说，“大爆炸重写唯一保证的就是大爆炸！”

代替Big Bang重写的方案是，我们应该逐步重构整体应用程序。逐步构建一个由微服务组成的新应用程序，并与整体应用程序一起运行。随着时间的流逝，单片应用程序实现的功能量会不断缩小，直到它完全消失或变成另一个微服务为止。此策略类似于以70 mph的速度在高速公路上行驶时维修汽车-它机具挑战性，但风险远小于尝试重写Big Bang。

Martin Fowler将此应用程序现代化策略称为Strangler应用程序。这个名字来自雨林中的扼杀藤蔓（又称扼杀无花果）。为了达到林冠上方的阳光，缠结藤蔓生长在树木周围。有时，树死了，留