在传统企业甚至互联网企业中往往存在大量的遗留系统，这些遗留系统大多都能够正常工作，有的可能还运行着关键业务或者持有核心数据。但是，大部分遗留系统通常经常存在技术陈旧、代码复杂、难以修改等特点。笔者曾经维护过一个Perl实现的网站，在2015年被解耦前，它已经工作了十几年，为公司占领市场立下了汗马功劳。奈何技术陈旧，维护困难，最后在微服务化过程中慢慢淡出。
可见，随着时间的推移，遗留系统的维护和管理的成本越来越大。在向微服务架构全面转型的过程中，这些遗留系统就像一只只“拦路虎”，阻挡微服务转型之路。如何在不影响业务的同时，以更安全、更高效、更低成本的方式将这些遗留系统进行微服务改造，使之顺利融入微服务架构，并充分利用到微服务架构的优势呢？本章将详细介绍如何解决遗留系统的微服务改造问题。
一、遗留系统综述
1. 什么是遗留系统
“遗留系统是一种旧的方法、技术、计算机系统或者应用程序，它意味着系统过时了或者需要被取代。”
这是维基百科上对于遗留系统的定义，对于“遗留”的含义有明确阐释，即过时或者需要被取代的系统。正因为如此，遗留系统通常具有一些类似的特征。
- 庞大的单体应用：遗留系统大多是多年积累下来的“巨无霸”系统，以单体应用形式呈现。
- 难于修改：多年的代码累积过程中疏于重构，导致代码的可读性和可扩展性较差。
- 维护成本很高：在庞大的代码中寻找bug的根本原因可能会比较困难。此外，运维也是难题，比如在本章开头提到的Perl系统，没有APM工具支持它的监控。
- 学习成本高昂：由于设计陈旧或技术过时，可能了解遗留系统技术和业务的人已经很难找到。
- 缺乏质量保障：由于过去缺少投入，许多功能基本上没有自动化测试来保障质量。
这些问题随着日积月累，可能会给团队带来越来越多的负担，直到无法承受其管理和维护成本。所以遗留系统在微服务架构下如何进行改造，是大多数企业在面向微服务转型时都不得不面对的问题，而且急需尽早考虑、尽快解决，才能避免问题累积到一定程度后集中爆发。
2. 直接重写遗留系统可行么
遇到遗留系统的改造问题时，不少人可能会首先想到一个直截了当的方案：推翻重写，用全新的系统一次性替换掉遗留系统。采用这种方式，在落地过程中总会发现种种问题，导致新系统无法顺利切换，旧系统又无法完全替代。常见的问题有以下几种：
- 上线困难，业务阻塞风险高：在遗留系统重写的过程中，往往会有新增需求对遗留系统的功能进行修改，在新系统未上线前，这些需求要么被阻塞，要么需要付出双倍的工作量在遗留系统和新系统上同时实现，无论哪种选择对团队都是很难接受的。
- 影响面不可控，系统改造周期长：遗留系统往往运行着关键业务或者持有核心数据，会被多个上层服务所调用。一旦决定开始重写，其影响面无法评估，需要极为小心，考虑周全，客观上会造成系统改造周期被无限期拉长。
- 学习成本高，知识传递周期长：遗留系统的改造周期越长，对系统的学习成本就会随之升高。在这个过程中随着人员的正常流失，团队对业务和技术的熟悉程度会逐渐降低，而新人需要花费更多的时间才能熟悉遗留系统改造过程中必要的知识和技术。
综上所述，寄希望于直接重写遗留系统、进行一次性替换而解决微服务改造问题是不现实的，必须探索一条能够持续可演进的道路，实现快速、低成本、影响面可控的改造效果。
二、遗留系统改造策略
对遗留系统的改造，既要不影响业务，实现平滑、安全的过渡，又要保证能够高效、稳步地推进，这对于软件开发者来说是个不小的挑战。
结合笔者的经验，在遗留系统改造过程中可以采取以下思路：
- 遵循“演进式改造流程”，优先改造最具价值的部分，并保证改造过程中的风险可控。
- 采用“绞杀者模式”，通过逐步替换而非一次性替换的方式，来保证新旧系统的平滑过渡。
- 采用“挎斗模式”，将不容易改造的遗留系统接入微服务环境中。
1. 演进式改造流
演进式改造流程是一种以逐步演进的方式对遗留系统进行改造的流程，其过程如图6-1所示。
图6-1 对遗留系统的演进式改造流程
1.1 构建服务路标图
动手进行改造之前，首先需要构造出一个服务路标图，来粗粒度地展示在理想情况下所期望的各个服务及相互之间的依赖关系。以该图作为路标，指导我们着手进行服务化改造。当然，服务路标图可以不必苛求完整，可以随着开发过程的演进而不断完善。构建路标图的过程可由架构师、业务分析师及技术负责人共同参与，构建路标图的方法可以参考3.1.1小节的“服务拆分策略”。服务路标图构建好之后应在团队中共享并接受来自各个方面人员的反馈。
1.2 服务选择
有了服务路标图之后，也许会发现改造过程千头万绪，不知如何选择合适的部分优先进行改造。此时不妨遵循价值最大化的原则，从多种角度去制定优先拆分策略，比如：
- 优先拆分相对独立的部分，独立业务与旧系统之间的耦合相对较小，比较容易实施。
- 优先拆分频繁变更的部分，可以通过拆分为新的服务实现独立部署与快速上线，对于提高团队总体交付效率价值较大。
- 优先拆分有特殊资源占用需求的部分，比如将计算密集型任务拆分为新服务，并恰当地利用云基础设施的弹性伸缩能力对新服务实例进行扩缩容，有助于提高系统总体性能并降低成本。
1.3 服务改造
选好优先需要改造的部分后，着手将这部分业务功能迁移到微服务架构下实现。改造过程中，通常需要解决这样的问题：
- 新旧系统可能需要不同的数据源，或具有不同的数据库结构，怎样解决数据之间的同步和依赖问题？
- 单体的旧系统需要拆分为多个服务时，怎样实现安全的渐进式拆分？
根据改造需求的不同以及数据依赖关系，具体可以分为三种不同的改造场景，每种场景下的技术实现各有不同。
1.4 业务验证
业务功能迁移到微服务架构下实现后，需要验证新的服务是否满足业务需求。在新服务上线投入使用并稳定后，可以从遗留系统中移除原有的代码模块，如有需要时，一并移除数据同步任务。
1.5 迭代优化
至此已经对一部分遗留系统的业务完成了微服务改造，对于剩余的部分，可以按照类似的方法迭代进行，重新审视服务路标图，选出下一个需要改造的业务，继续进行优化，直到完成既定的微服务改造目标。
