用“给飞机换引擎”来说明了架构改造的复杂性和重要性。一般来说重构分为这样几种：（1）彻底重新做，直接从前到后抛弃老系统（2）大规模重构，保留对用户的这层皮，后面从服务到数据全部替换。（3）小规模重构，保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务。
在重构设计时需要考虑这几个现实的情况:（1）业务需要发展。业务需要不断发展意味着不断有新的需求开发。如果重构的时间很长的话，我们需要在这段时间内做两套系统的需求。如果新需求的开发需要很长时间的话。先重构到正在使用的版本系统。当重构的系统上线进行观察，修复新的系统bug后。再一心开发的新的业务。（2）数据需要迁移。当系统重构时，我们需要把旧系统的数据迁移到新的系统上。我们需要做一些数据迁移工作：准备迁移脚本，准备缓存预热脚本；使用既有的数据来测试这2个脚本，然后观察新系统的运行情况；做反向数据迁移的脚本，我们要考虑到切换到新系统后运行不流畅需要整体回滚的情况，这个时候我们需要把数据从新的数据库迁移到老的数据库。这种数据迁移是需要时间的，但我们希望最好没有停机让用户没有感知。所以可以用两端走的方式，今天先把以前的99%的数据迁移过去，明天再把今天1%的数据迁移过去。（3）万一迁移失败时怎么办。当迁移数据需要回滚时，可能一些新老系统依赖是公用的，尽量要隔离清楚，让新老系统系统彻底独立。如果迁移后新系统再跑了污染了老系统的数据，这时候再要回滚会出现回不去的情况。
作者提出了安全意识十原则。（1）安全问题是木桶效应。整个系统的安全成都取决于木桶最短的板。很多黑客也往往喜欢找边缘化的子站点或非核心逻辑进行攻破。因为这些模块或站点往往是由初级程序员打造，有的还不是主站统一的技术架构，总体上会防备薄弱。、
（2）开发层面：不要信任客户端的任何东西。对于http协议，不管里面的东西还是正文的东西，二五年和数据都是可以伪造的。不仅get的参数不安全，post过来的数据也不安全，不能信任Cookie中的数据做一些权限控制。（3）开发层面：数据就是数据，代码就是代码。对于客户端传过来的任何信息都知识数据，应该很少让客户端告诉服务端执行的代码。
（4）开发层面：用户看不到不等于黑客看不到。（5）开发层面：最小化接口权限设计复用性矛盾。（6）开发层面：一开始：一开始就要考虑安全，放出去了就没后悔药。（7）产品层面：做好防爆和暴力破解控制。（8）产品层面：注意产品逻辑一体性。（9）运维层面：做好异常数据监控报警。（10）运维层面：对内的数据和权限问题。