遗留系统改造面试题：我被问到的那些问题

最近换工作面试，发现很多公司都在做遗留系统改造，面试官特别喜欢问遗留系统改造相关的问题。我这几年正好参与过几个大型遗留系统的改造项目，从老旧的单体应用拆分成微服务，从PHP5升级到PHP7，从MySQL迁移到分布式数据库，积累了不少实战经验。

面试的时候被问到了不少相关的问题，有的答得不错，有的答得不太好。今天就来整理一下我被问到的遗留系统改造相关的面试题，以及我的回答和思考，希望能帮到正在准备面试或者正在做遗留系统改造的朋友。

一、为什么要做遗留系统改造，改造的目标是什么

这是最基础的问题，几乎每次面试都会问。我的回答是，遗留系统改造的原因通常有以下几个：

技术栈老旧，维护成本高：很多遗留系统用的是很老的技术栈，比如PHP5、Java 6、Struts、jQuery等等，这些技术已经停止维护了，有安全漏洞也没人修，而且会用这些老技术的人越来越少，招人难，维护成本越来越高。
架构落后，无法支撑业务发展：很多遗留系统是单体架构，所有功能都在一个应用里，随着业务越来越复杂，代码量越来越大，修改一个小功能都要整个系统重新测试发布，风险大，效率低，而且单体架构的扩展性差，无法应对高并发，无法支撑业务的快速发展。
性能差，用户体验不好：遗留系统往往性能很差，响应慢，经常卡顿，甚至宕机，用户体验很差，影响业务发展。
数据孤岛，无法打通：很多公司有多个遗留系统，各个系统之间数据不互通，形成数据孤岛，无法做统一的数据分析和业务协同，影响决策效率和业务发展。
安全隐患：老旧的系统往往有很多安全漏洞，而且因为技术栈老旧，无法及时修复，存在很大的安全隐患，一旦被攻击，后果不堪设想。

改造的目标，我总结为以下几点：

提升系统的可维护性：用现代化的技术栈和架构，降低维护成本，提高开发效率。
提升系统的性能和稳定性：优化架构和代码，提升系统性能，提高稳定性，减少宕机。
提升系统的可扩展性：用分布式、微服务架构，让系统能够水平扩展，应对业务增长和高并发。
打通数据孤岛：统一数据标准，打通各个系统之间的数据，实现数据共享和业务协同。
提升安全性：修复安全漏洞，用现代化的安全技术，提升系统的安全性。
业务赋能：通过系统改造，支撑新的业务场景，提升业务效率，为业务发展赋能。

这个问题考察的是你对遗留系统改造的整体理解，有没有从业务和技术两个维度去思考，而不是只想着技术升级。回答的时候要结合实际项目，说说你做过的项目为什么要改造，改造的目标是什么，这样更有说服力。

二、遗留系统改造有哪些策略，各自的优缺点是什么

这个问题也是高频面试题，考察你对改造策略的理解。遗留系统改造通常有以下几种策略：

1. 彻底重写（Big Bang Rewrite）

就是把旧系统完全抛弃，从零开始用新的技术栈重新写一套系统。优点是可以彻底摆脱旧系统的技术债务，用最新的技术和架构，系统设计可以更合理，没有历史包袱。缺点是风险大，周期长，成本高，而且重写过程中旧系统还要继续维护，双线作战，团队压力大。而且重写很容易陷入"第二系统效应"，新系统越做越复杂，越做越慢，最后可能烂尾。

这种策略适合旧系统已经完全无法维护，业务逻辑相对简单，或者团队有足够的资源和时间的情况。一般不推荐大规模系统用这种策略，风险太高。

2. 绞杀者模式（Strangler Fig Pattern）

这是Martin Fowler提出的一种改造模式，就是在旧系统外面包一层新系统，新功能用新系统开发，旧功能逐步从旧系统迁移到新系统，直到旧系统的所有功能都被迁移完，最后旧系统就被"绞杀"掉了。优点是风险低，可以渐进式改造，边做边上线，用户无感知，而且可以随时停下来，不会影响业务。缺点是改造周期长，新旧系统共存期间需要维护两套系统，还要处理新旧系统之间的通信和数据同步，有一定的复杂度。

这种策略是目前最常用的，适合大部分遗留系统改造，特别是大型系统，风险可控，渐进式推进，业务影响小。

3. 逐步重构（Incremental Refactoring）

就是在旧系统的基础上，逐步重构代码，优化架构，不改变系统的外部行为，只是改善内部结构。比如把大模块拆成小模块，把重复代码提取出来，优化数据库查询，引入设计模式等等。优点是风险低，每次改动小，容易验证，不影响业务。缺点是只能改善代码质量，无法从根本上改变技术栈和架构，如果旧系统的技术栈和架构已经严重落后，逐步重构是解决不了根本问题的。

这种策略适合旧系统还能用，只是代码质量差，维护成本高的情况，可以作为其他改造策略的补充。

4. 防腐层（Anti-Corruption Layer）

就是在新旧系统之间加一层防腐层，把新系统和旧系统隔离开，新系统通过防腐层和旧系统通信，防腐层负责数据转换、协议转换、接口适配等等。优点是新系统不会被旧系统的烂设计污染，可以保持新系统的纯洁性，而且以后旧系统下线了，只需要改防腐层就行，新系统不用改。缺点是增加了一层，有一定的开发和维护成本，而且性能会有一点损耗。

这种策略通常和绞杀者模式配合使用，在新旧系统共存期间，用防腐层来隔离新旧系统，保护新系统不被旧系统污染。

回答这个问题的时候，要把每种策略的优缺点说清楚，然后结合实际项目说说你用的是哪种策略，为什么选这种策略，效果怎么样。这样能体现你不仅懂理论，还有实践经验。

三、如何保证改造过程中业务不中断，数据不丢失

这个问题是遗留系统改造的核心问题，也是面试官最关心的问题，因为改造的前提是不能影响业务，不能出故障。我的回答是，从以下几个方面来保证：

1. 渐进式改造，小步快跑

不要搞大爆炸式的改造，不要一下子把整个系统都换掉，而是用绞杀者模式，一个模块一个模块地迁移，每次只迁移一个小功能，上线验证没问题了，再迁移下一个。这样每次改动的范围小，风险可控，出了问题也容易回滚，不会影响整个业务。

2. 灰度发布和流量切换

新功能上线的时候，不要一下子把所有流量都切到新系统，而是用灰度发布，先切一小部分流量（比如1%、5%）到新系统，观察新系统的运行情况，包括性能、错误率、业务指标等等，如果没问题，再逐步放大流量比例，直到100%。如果出了问题，立刻把流量切回旧系统，不会影响大部分用户。

流量切换可以用Nginx、网关层来做，根据用户ID、百分比、地域等维度来路由，非常灵活。

3. 双写和数据校验

涉及到数据迁移的时候，用双写的方式，新系统和旧系统同时写数据，保证两边的数据一致。然后定期做数据校验，对比新旧系统的数据，看看有没有不一致的地方，如果有，及时修复。等新系统稳定运行一段时间，确认数据没问题了，再把旧系统的写停掉，只写新系统。

读的话，可以先读新系统，如果新系统没有，再读旧系统，或者并行读新旧系统，对比结果，确保新系统的数据是对的。等确认新系统数据没问题了，再只读新系统。

4. 完善的监控和告警

改造过程中，一定要有完善的监控和告警，对新系统的各项指标进行实时监控，包括CPU、内存、磁盘、网络、响应时间、错误率、业务指标等等。一旦出现异常，立刻告警，及时处理，不要等问题扩大了才发现。

还要有旧系统的监控，因为新旧系统共存期间，旧系统还要继续运行，也要保证旧系统的稳定。

5. 回滚方案

每次上线新功能之前，都要准备好回滚方案，一旦新系统出了问题，能够快速回滚到旧系统，把影响降到最低。回滚方案要提前演练，确保真的出问题的时候能够快速执行，不要等出了问题才发现回滚不了。

回滚包括代码回滚、流量回滚、数据回滚等等，都要考虑到。

6. 充分的测试

改造过程中，测试是非常重要的，一定要有充分的测试，包括单元测试、集成测试、功能测试、性能测试、压力测试、回归测试等等。特别是回归测试，要确保新系统的功能和旧系统一致，没有引入新的bug。

可以用自动化测试来提高测试效率，把核心业务流程做成自动化测试用例，每次上线前跑一遍，确保核心功能没问题。还可以用流量回放，把旧系统的真实流量录下来，在新系统上回放，对比新旧系统的输出，确保新系统的行为和旧系统一致。

回答这个问题的时候，要结合实际项目，说说你在项目中是怎么做的，用了哪些方法，遇到了什么问题，怎么解决的，效果怎么样。这样能体现你的实战经验。

四、如何处理新旧系统之间的通信和数据同步

这个问题也是遗留系统改造中的常见问题，新旧系统共存期间，肯定需要通信和数据同步。我的回答是，通常有以下几种方式：

1. API调用

新系统通过调用旧系统的API来获取数据或者触发操作，这是最直接的方式。如果旧系统没有API，可以给旧系统封装一层API，把旧系统的功能暴露出来。优点是简单直接，实时性好。缺点是耦合度高，新系统依赖旧系统的API，如果旧系统出问题，新系统也会受影响。而且旧系统的API可能设计得不好，调用起来很麻烦。

这种方式适合旧系统还比较稳定，有现成的API，或者可以快速封装API的情况。

2. 消息队列异步通信

新旧系统之间通过消息队列来通信，一个系统发消息，另一个系统消费消息，异步处理。优点是解耦，新旧系统不直接依赖，一个系统出问题不会影响另一个系统，而且可以削峰填谷，应对高并发。缺点是实时性差一些，有延迟，而且需要处理消息丢失、重复消费、顺序性等问题，有一定的复杂度。

这种方式适合对实时性要求不高，需要解耦的场景，比如数据同步、事件通知等等。

3. 数据同步

通过数据同步的方式，把旧系统的数据同步到新系统，或者双向同步。可以用定时任务同步，也可以用binlog监听实时同步（比如用Canal监听MySQL的binlog，把数据变更同步到新系统）。优点是对旧系统侵入小，不用改旧系统的代码，只需要读数据库就行。缺点是数据同步有延迟，而且要处理数据一致性问题，双向同步的话复杂度更高。

这种方式适合旧系统无法改造，或者不想改旧系统代码的情况，用数据同步的方式来打通数据。

4. 共享数据库

新旧系统共用同一个数据库，直接读写同一份数据。优点是简单，没有数据同步的问题，数据一致性好。缺点是耦合度非常高，数据库的结构不能随便改，一改两个系统都受影响，而且两个系统同时写同一个表，容易出现冲突和数据不一致。这种方式一般不推荐，只适合临时过渡，或者非常简单的场景。

实际项目中，通常是几种方式结合使用，比如核心业务用API调用，数据同步用binlog监听，事件通知用消息队列，根据不同的场景选择合适的方式。

回答这个问题的时候，要说说各种方式的优缺点和适用场景，然后结合实际项目说说你是怎么做的，怎么选型的，遇到了什么问题，怎么解决的。

五、如何说服业务方和领导支持改造

这个问题很实际，很多时候技术改造最大的阻力不是技术，而是业务方和领导不支持，觉得改造不产生业务价值，还浪费时间和资源，甚至可能影响业务。我的回答是，从以下几个方面去说服：

1. 用业务语言沟通，不要只讲技术

和业务方、领导沟通的时候，不要只讲技术术语，什么微服务、分布式、技术债务，他们听不懂，也不关心。要用业务语言，讲清楚改造能给业务带来什么好处，比如提升系统稳定性，减少宕机，减少因为系统问题导致的业务损失；提升开发效率，新功能上线更快，支撑业务快速迭代；提升性能，用户体验更好，提高用户留存和转化率；提升安全性，避免安全事故，减少合规风险等等。把技术问题转化为业务问题，让他们明白改造是为了业务更好地发展，不是为了技术而技术。

2. 用数据说话，量化收益和风险

不要空口说白话，要用数据说话。比如现在系统每个月宕机几次，每次宕机损失多少营收；现在开发一个新功能需要多久，改造后能缩短到多久；现在系统的响应时间是多少，改造后能提升多少；现在维护旧系统需要多少人，改造后能减少多少人力成本。把这些数据摆出来，让业务方和领导直观地看到改造的收益和不改造的风险，他们自然会支持。

还要量化改造的成本和周期，让他们知道需要投入多少资源，多长时间能看到效果，做到心中有数，不要给他们不切实际的期望。

3. 小步快跑，快速见效，建立信任

不要一上来就说要花一年时间，投入多少人，做一个大改造，那样业务方和领导肯定会犹豫，风险太大。可以先从一个痛点最明显、最容易出成果的模块入手，做一个小的改造，快速上线，让大家看到效果，比如某个模块改造后，性能提升了多少，bug减少了多少，开发效率提高了多少。用实际效果建立信任，然后再逐步扩大改造范围，这样业务方和领导就会越来越支持。

4. 让业务方参与进来，达成共识

改造不是技术团队一个人的事，要让业务方也参与进来，一起讨论改造的目标、范围、优先级，让他们明白改造的必要性和价值，达成共识。可以组织一些分享会、研讨会，让业务方了解旧系统的问题和改造的方案，听取他们的意见和建议，让他们觉得这是大家共同的项目，而不是技术团队单方面的决定。这样他们才会主动支持，而不是被动配合。

5. 降低风险，消除顾虑

业务方和领导最大的顾虑就是改造会不会影响业务，会不会出故障。要把你的风险控制方案讲清楚，比如渐进式改造、灰度发布、双写校验、监控告警、回滚方案等等，让他们知道你有充分的准备，风险是可控的，就算出了问题也能快速回滚，不会影响业务。消除了他们的顾虑，他们才会放心地支持你。

这个问题考察的是你的沟通能力和项目推动能力，技术人员往往只关注技术，忽略了人的因素，但是实际工作中，推动一个改造项目，沟通和协调能力和技术能力一样重要。回答的时候要体现你有这方面的意识和经验。

六、写在最后

遗留系统改造面试题：我被问到的那些问题。

以上就是我面试中被问到的一些遗留系统改造相关的问题，以及我的回答和思考。当然，遗留系统改造涉及的内容远不止这些，还有很多深入的问题，比如技术选型、团队管理、成本控制、质量保障等等，面试的时候如果遇到深入的问题，还需要更深入的理解和实践经验。

遗留系统改造是一个很有挑战性的工作，它不仅仅是技术升级，更是一个系统工程，涉及到技术、业务、团队、管理等方方面面。做好遗留系统改造，不仅需要扎实的技术能力，还需要良好的沟通能力、项目管理能力、风险控制能力。但是一旦做好了，对个人能力的提升是非常大的，而且能给公司带来很大的价值。

如果你正在做遗留系统改造，或者面试中经常被问到相关问题，希望这篇文章能给你一些参考和启发。也欢迎大家在评论区交流你们的经验和问题，一起学习进步。

最后用一句话结尾："遗留系统改造不是一蹴而就的，而是一个渐进的过程，小步快跑，持续迭代，控制风险，稳步推进，终能成功。"

祝大家都能顺利完成遗留系统改造，面试顺利，工作顺利！