给飞行中的飞机换引擎
所谓给飞行中的飞机（或飞驰的汽车）换引擎说的是我们需要对一个正在飞速发展的系统进行大幅度的架构改造，比如把All-in-one的架构改造成微服务架构，尽可能减少或消除停服的时间。一般而言，我们可以这么来考虑方案，从重构的彻底性来说，分为这么几种：
-
彻底重新做，直接从前到后抛弃老系统
-
大规模重构，保留对用户的这层皮，后面从服务到数据全部替换
-
小规模重构，保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务
在做换引擎方案选择和设计的时候需要考虑到这么几个现实的情况：
-
业务需要发展。意味着会不断有新需求需要开发，如果重构的时间拖的很长的话，我们需要在这段很长的时间内为两套系统同时做新需求，新的系统还要不断开发新需求，会增加更多的时间，如果新系统的开发不够快的话，甚至一直上不了线。我们最好在重构之前对新增业务有一条界限，新系统只是覆盖到这个版本做需求封板，然后和产品商量出一个妥协是否对于之后我们留1周作为系统切换期，这段时间不上线新需求。这1周分成几个环节，需要2天的时间来做系统切换，然后需要5天的时间来观察新系统的稳定性，修复新系统的Bug，随后我们才能认为系统正式切换成功，把时间精力放到新业务的开发上。
-
数据需要迁移。我们是为一个旧飞机在换引擎，无法抛弃飞机上的乘客。如果我们更改数据结构的话，需要对数据进行迁移。我们需要做下面的工作：
-
准备迁移脚本
-
准备缓存预热脚本
-
使用既有的数据来测试这2个脚本，然后观察新系统的运行情况
-
做反向数据迁移的脚本，我们要考虑到切换到新系统后运行不流畅需要整体回滚的情况，这个时候我们需要把数据从新的数据库迁移回老的数据库
这种方式的迁移是需要有短暂的停机的，两个脚本的执行和验证需要一段时间（数据量大的话导数据费时）。如果希望尽可能减少停机时间的话可以采用两段走的方式，先同步今天前的99.9%的数据到新数据库，在停机后再同步今天发生的那0.1%的数据。极端点希望彻底不停机的话，需要让业务同时走两套系统进行双写，这种方案大大增加复杂度，但是可以换来几乎0停机的时间，除非是需要24小时在线的金融系统，一般不会考虑新老系统双活的方案。
安全意识：
1、安全问题是木桶效应。整个系统的安全程度取决于木桶最短的那块板。很多时候我们会召集安全专家和架构师和主站主流程主域名的系统进行安全分析和渗透测试，而黑客知道这点也往往喜欢找边缘化的子站点或非核心逻辑进行攻破，这些模块或站点往往是由初级程序员打造，有的甚至还不是主站统一的技术架构，总体上会防备薄弱。黑客能够攻破任意站点进去到内网，就有种种可能。针对这点，我们需要做的是对于安全的排查，需要全面覆盖，除非子站在部署上用户体系上彻底隔离。
2、开发层面：不要信任客户端的任何东西。对于HTTP协议，不管是头里面的东西（来源、客户端类型、Cookie）还是正文里面的东西，任何数据都是可以伪造的。我们往往会觉得Get的东西暴露在浏览器地址上，里面的参数不安全，Post过来的数据因为不暴露就安全，然后会信任Cookie中的数据做一些权限控制，会用头里面的一些数据做一些安全性控制。这些不是说不能做，而是要从根子里面有这个意识所有客户端的东西可以用但不能不经过判断直接相信。有一个容易犯的错误是，在设计Controller的时候我们可能会在参数里让客户端传过来UserID、Price等信息。这里的问题在于，登录后的UserID应该是保存在服务端的，客户是谁不是客户自己说了算的，应该是我们根据SessionID在服务端获得的，我们需要全面排查代码，不允许在Controller的方法里存在类似于用户ID这样的字段
3、开发层面：数据就是数据代码就是代码。不管是SQL注入也好XSS也好都是这个问题，把数据和代码混在了一起。对于客户端过来的任何信息应该都只是数据，应该很少会让客户端来告诉服务端执行的代码。所以这个事情我们要从两方面来防范，第一客户端过来的数据需要让它当成数据来处理，不管是Encoding一下也好，SQL参数化（Mybatis的$和#问题）也好都是这个方面的措施（从前到后一路数据都以数据的身份在程序中流转），第二从数据库里出来的东西也只能是数据不能让它变为HTML或JS代码，也需要Encoding一次再在客户端上呈现。SQL注入的防范很多人喜欢用敏感字符替换的方式来做，这种做法其实是会有遗留的，我们不应该去考虑排除数据中有代码的可能性，而是应该从根源上去让数据只可能成为数据。
4、开发层面：用户看不到不等于黑客看不到。
第一个方面想说的是，随着前后端的分离，现在很多请求都是AJAX请求，AJAX请求会有几方面的安全疏漏：
-
逻辑分散而明确。对于服务端渲染，我们会把各种逻辑整合在一起，用户看到的是一个完整的渲染后的页面不清楚里面有多少逻辑，对于AJAX请求，我们会以良好的方法命名来命名各种API。这个时候会给黑客可乘之机，会更容易分析理解程序运行的流程，毕竟在寻找突破之前需要先理解程序的流程。
-
容易觉得AJAX请求是前端程序发起的而忽略权限问题。没错，AJAX的发起人也是我们的代码，但是AJAX请求也是HTTP请求谁都可以发起。如果我们对AJAX请求的参数设计有所松懈，犯了之前说的两个错的话那就很危险了。特别是前后端都是一个人来写的话，程序员在实现代码逻辑的时候往往只会考虑数据的传输简单通畅，后端给前端，前端再给后端放松安全意识。
第二方面说的是，后端往往会返回更多的数据给前端，前端选择需要的数据进行呈现，有的时候甚至直接返回的是代码生成器生成的DbEntity（在三层架构中，DbEntity对应表结构，ServiceEntity是充血的领域实体，ResponseEntity是面向呈现的实体，三者不应该是一套）。这里的问题在于：
-
服务端返回了过多的数据，这是比较危险的事情，因为有一些内部的字段会返回出去。
-
服务端返回的数据列对应了数据库实际的列，相当于暴露了表结构，对于以后各种API的尝试和注入极端危险。
-
一些敏感的数据也直接返回给客户端了，虽然客户端不会展现出来，但是对于黑客来说根本不在于用户看得到看不到这些数据。
这就要求我们在做设计的时候尽可能仔细审视AJAX的接口的权限、数据开放性和脱敏等问题。一些框架提供的脚手架生成工具以及Restful API自动生成工具，即使要用也要做好权限设置。
5、开发层面：最小化接口权限设计复用性矛盾。在做设计的时候我们会考虑到复用性的问题让方法尽可能通用，但是对于对外的接口我们要尽量收缩功能。举一个之前看到的例子，我们需要验证游戏的密保卡，需要用户告知三个坐标的密保数字，比如A1B2C3三个坐标，每一个数字是0到99，三个数字同时猜对的可能性是百万分之一，但是接口的设计居然是直接让用户传三个坐标，这里有两个严重的设计错误：
-
第一，为什么是允许客户端传过来三个密保的位置，合理的做法是服务端告知客户端此次校验的ID，然后客户端传过来ID，服务端在Session或缓存中去获取坐标位置。
-
第二，接口允许传三个坐标也算了，还允许是相同的坐标，我们完全可以改造接口传A1A1A1然后依次暴力破解0到99，马上就可以得出A1坐标的值，几秒的时间就可以把整个密保卡完全暴破出来。
在设计服务端接口的时候，我们最好针对某个功能设计最小的接口，而不是开放的通用的接口，对外的接口设计安全性需要大于重用性。
6、开发层面：一开始就要考虑安全，放出去了就没后悔药。比较无奈的是，很多项目我们处于赶进度，一开始第一版的时候并没有对接口做加密和签名验证。如果做的是一个APP，那么我们要考虑到APP用户不升级的情况，即使v2的版本的数据都是加密的，参数都是验签的，但是我们还不能下架v1版本（强更会损失多少用户难以估计）。这个时候就比较无奈了，明知道v1版本的安全性有着很大的风险却不能升级。不仅仅是接口的安全性，安卓客户端的代码也要考虑到反编译的可能性需要混淆。之前遇到过有一个App客户端里网络层直接使用了服务端的接口定义，导致客户端代码里可以对服务端所有接口一清二楚，还不乏一些不能对外使用的内部接口以及已经淘汰的老接口，加上接口的调用又没有签名数据传输又不加密，拿着这份网络协议什么都可以干。