互联网架构实践心得 （六）—给飞机换引擎和安全意识十原则

给飞行中的飞机换引擎

所谓给飞行中的飞机（或飞驰的汽车）换引擎，说的是我们需要对一个正在飞速发展的系统进行大幅度的架构改造，比如把 All-in-one 的架构改造成微服务架构，尽可能减少或者消除停服的时间，一般而言，我们可以这么来考虑方案，从重构的彻底性来说，分为这么几种：

• 彻底重做：直接从前到后彻底抛弃老系统。
• 大规模重构：保留对用户的这层皮，后面从服务到数据全部替换。
• 小规模重构：保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务。

在做换引擎方案选择和设计的时候需要考虑到这么几个现实的问题：

• 业务需要发展，意味着会不断由新需求需要开发，如果重构的时间拖得很长的话，我们需要在这段很长的时间内为两套系统同时做新需求，新的系统还有不断开发新需求，会增加更多的时间，如果新系统的开发不够快的话，甚至一直上不了线，我们最好在重构之前对新增业务有一条界限，新系统只是覆盖到这个版本做需求封板，然后和产品商量出一个妥协是否对于之后我们留一周作为系统切换期，这段时间不上线新需求。这一周分成几个环节，需要两天的时间来做系统切换，然后需要五天的时间来观察新系统的稳定性，修复新系统的BUG，随后我们才认为系统正式切换成功，把时间精力放到新业务的开发上。
• 数据需要迁移，我们是为一个旧飞机在换引擎，无法抛弃飞机上的乘客，如果我们更改数据结构的话，需要对数据进行迁移。我们需要做下面的工作：
  • 准备迁移脚本
  • 准备缓存预热脚本
  • 使用既有的数据来测试这2个脚本，然后观察新系统的运行情况。
  • 做反向数据迁移的脚本，我们要考虑到切换到新系统后运行不流畅需要整体回滚的情况，这个时候我们需要把数据从新的数据库迁移回老的数据库

这种方式的迁移是需要有短暂的停机的，两个脚本的执行和验证需要一段时间（数据量大的话导数据费时），如果希望尽可能减少停机时间的话，可以采用两段走的方式，先同步今天前的99.9%的数据到新数据库，在停机后再同步今天发生的那0.1%的数据，极端点希望彻底不停机的话，需要让业务同时走两套系统进行双写，这种方案大大增加了复杂度，但是可以换来几乎 0 停机的时间，除非是需要 24 小时在线的金融系统，一般不会考虑新老系统双活的方案。

你可能会觉得对于重构，我们应该考虑不要改底层数据库，这会大大增加复杂性，这还是取决于我们希望多彻底进行重构，很多时候底层的数据库设计不够灵活这是最致命的，如果不切换到新的数据库，即使搞成了微服务架构数据还是揉在一起，只是形态上是微服务，底层还是乱七八糟，这堆业务代码最终还是要进行一次重构。

• 最好没有停机让用户没有感知，没有停机意味着老的系统一直在线上稳定运行，新的系统可以以独立的形态重新部署一套。用户对我们新系统的开发没有感知，新老系统的面子可以长得一模一样，但是底层的调用面目全非，由于两套系统都在线上运行，我们可以在内部对新系统进行充分测试，还可以比较同样的业务流程在数据呈现上是否有差异，可惜现实往往没有想的那么简单，很多时候我们会依赖各种第三方数据。对于金融系统来说往往对