这次在微信上阅读了一个实践：给飞机换引擎和安全意识十原则
文章地址：https://mp.weixin.qq.com/s/gd-XqGGh08o-vWFZSR0RJg
给飞行中的飞机换引擎
作者用飞机换引擎作为一个例子。把给飞行中的飞机（或飞驰的汽车）换引擎说成我需要对一个正在飞速发展的系统进行大幅度的架构改造。分为这3种：
- 彻底重新做，直接从前到后抛弃老系统
- 大规模重构，保留对用户的这层皮，后面从服务到数据全部替换
- 小规模重构，保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务
在做换引擎方案选择和设计的时候需要考虑到这么几个现实的情况：
- 业务需要发展。如果重构的时间拖的很长的话，我们需要在这段很长的时间内为两套系统同时做新需求，新的系统还要不断开发新需求，会增加更多的时间，如果新系统的开发不够快的话，甚至一直上不了线。我们最好在重构之前对新增业务有一条界限，新系统只是覆盖到这个版本做需求封板，然后和产品商量出一个妥协是否对于之后我们留1周作为系统切换期，这段时间不上线新需求。这1周分成几个环节，需要2天的时间来做系统切换，然后需要5天的时间来观察新系统的稳定性，修复新系统的Bug，随后我们才能认为系统正式切换成功，把时间精力放到新业务的开发上。
- 数据需要迁移。如果我们更改数据结构的话，需要对数据进行迁移。我们需要做下面的工作：
- 准备迁移脚本
- 准备缓存预热脚本
- 使用既有的数据来测试这2个脚本，然后观察新系统的运行情况
- 做反向数据迁移的脚本，我们要考虑到切换到新系统后运行不流畅需要整体回滚的情况，这个时候我们需要把数据从新的数据库迁移回老的数据库
- 最好没有停机让用户没有感知。其实就是给用户安全感。
- 万一迁移失败怎么办。之前说了我们迁移数据需要考虑回滚方案，这里还会有一些比较恶心的点是如果新老系统有一些内部外部依赖是公用的话，尽量要隔离清楚，让新老系统彻底独立，这样才好回滚。
作者对安全也有深刻的见解，列举了十大原则：
1、安全问题是木桶效应。整个系统的安全程度取决于木桶最短的那块板。针对这点，我们需要做的是对于安全的排查，需要全面覆盖，除非子站在部署上用户体系上彻底隔离。
2、开发层面：不要信任客户端的任何东西。
3、开发层面：数据就是数据代码就是代码。第一客户端过来的数据需要让它当成数据来处理，不管是Encoding一下也好，SQL参数化（Mybatis的$和#问题）也好都是这个方面的措施（从前到后一路数据都以数据的身份在程序中流转），第二从数据库里出来的东西也只能是数据不能让它变为HTML或JS代码，也需要Encoding一次再在客户端上呈现。
4、开发层面：用户看不到不等于黑客看不到。这就要求我们在做设计的时候尽可能仔细审视AJAX的接口的权限、数据开放性和脱敏等问题。一些框架提供的脚手架生成工具以及Restful API自动生成工具，即使要用也要做好权限设置。
5、开发层面：最小化接口权限设计复用性矛盾。
6、开发层面：一开始就要考虑安全，放出去了就没后悔药。
7、产品层面：做好防刷和暴力破解控制。
8、产品层面：注意产品逻辑一体性。
9、运维层面：做好异常数据监控报警。
10、运维层面：对内的数据和权限问题。