使用微服务架构改造遗留系统
背景与挑战
随着公司国际化战略的推行以及本土业务的高速发展、《网络借贷信息中介机构业务活动管理暂行办法》的发布，各网贷平台都面临业务转型和运营合规问题，接入银行资金存管系统，就是网贷平台必须满足的合规条件。然而，后台支撑系统、前台PC网站、手机APP、M站已经不堪重负，在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。一方面系统架构过于陈旧，性能、可靠性无法满足现有的需求。另一方面，功能繁杂，结构紊乱，定制的代码与系统耦合性极高。
由于是遗留系统，熟悉代码的人早已离职多时，新团队对其望而却步，只能做些周边的修补工作和需求的迭代增加。同时还要承担着边修补测试，边整理逻辑的工作。
改造策略
在无法中断业务处理的情况下，为解决当前面临的问题，团队制定了如下策略；
- 最小修改
- 功能剥离
- 数据解耦
- 数据同步
- 迭代替换
最小修改
同当前系统的负责人、用户、产品经理等进行协商，制定对现有系统的修改保护策略；对现有的系统进行更改，譬如对增加新特性、修复缺陷等进行评审和分析，对于大部分非紧急、非重要的任务，都禁止在原有的系统上进行修改。这样做的目的是用最小的成本保障当前系统能够正常运行，同时将工作的中心从现有的系统逐渐迁移到新的服务改造中。
功能剥离
在现有的系统的外围，逐渐构建功能服务接口，将系统核心功能剥离出来。同时使用代理机制，将用户对原系统的访问转发到新系统中。从而解耦原系统与用户之间的依赖。
数据解耦
随着部分功能的解耦，已经存在一些微服务能够独立为用户提供功能，这时逐渐考虑将数据解耦，从原有的单块架构数据库中剥离出相关的业务数据，尽量满足对于每一个服务有独立的、隔离的业务数据系统
数据同步
通常，对于某些遗留的单块架构系统而言，存在着较为复杂的业务逻辑，因此改造所需要花费的时间和成本非常大。可能在很长的一段时间内，由于新的服务独立出来（业务逻辑、数据），导致无法同现有的系统协作。在这种情况下，为了保持持续交付价值，通常会采用ETL机制，将服务中的数据同步到单块架构的数据库中，保障原有的功能能够继续被使用。
迭代替换
通过上述所描述的方式不断迭代，逐渐将功能解耦成独立的服务（包括业务逻辑以及数据）。
通过不断的迭代替换，最终将原有的系统替换成使用微服务架构解耦的新系统。
快速开发实践
随着团队对业务理解的加深和对微服务实践的尝试，数个微服务程序已经成功构建出来。不过问题也出现了：对于这些不同的微服务而言，虽然具体的代码实现细节不同，但其结构、开发方式、程序集成环境、测试策略、部署机制以及监控和警告等都有着类似的实现方式，那么如何才能满足DRY（Don't
Repeat Yourself Principle）原则并消除浪费呢？
- 快速开发模板
- 代码生成工具
- 持续集成模板
- 一键部署工具
小结
通过使用微服务架构，在不影响现有业务运转的情况下，团队有效的将遗留的单块架构系统逐渐分解成不同功能的微服务应用。
同时，通过微服务开发架构，团队能够快速构建不同功能的微服务接口，并能方便的将其部署在验收环境和生产环境下。
最后，得益于微服务的灵活性和高扩展性，使得团队能够快速建立低耦合、易扩展、易伸缩性的应用系统。