互联网架构实践
所谓给飞行中的飞机（或飞驰的汽车）换引擎说的是我们需要对一个正在飞速发展的系统进行大幅度的架构改造，比如把All-in-one的架构改造成微服务架构，尽可能减少或消除停服的时间。一般而言，我们可以这么来考虑方案，从重构的彻底性来说，分为这么几种：
- 彻底重新做，直接从前到后抛弃老系统
- 大规模重构，保留对用户的这层皮，后面从服务到数据全部替换
- 小规模重构，保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务
1、安全问题是木桶效应。
我们需要做的是对于安全的排查，需要全面覆盖，除非子站在部署上用户体系上彻底隔离。
2、开发层面：不要信任客户端的任何东西。
对于HTTP协议，不管是头里面的东西（来源、客户端类型、Cookie）还是正文里面的东西，任何数据都是可以伪造的。我们往往会觉得Get的东西暴露在浏览器地址上，里面的参数不安全，Post过来的数据因为不暴露就安全，然后会信任Cookie中的数据做一些权限控制，会用头里面的一些数据做一些安全性控制。
3、开发层面：数据就是数据代码就是代码。
不管是SQL注入也好XSS也好都是这个问题，把数据和代码混在了一起。对于客户端过来的任何信息应该都只是数据，应该很少会让客户端来告诉服务端执行的代码。
4、开发层面：用户看不到不等于黑客看不到。
我们在做设计的时候尽可能仔细审视AJAX的接口的权限、数据开放性和脱敏等问题。一些框架提供的脚手架生成工具以及Restful API自动生成工具，即使要用也要做好权限设置。
5、开发层面：最小化接口权限设计复用性矛盾。
在设计服务端接口的时候，我们最好针对某个功能设计最小的接口，而不是开放的通用的接口，对外的接口设计安全性需要大于重用性。
6、开发层面：一开始就要考虑安全，放出去了就没后悔药。
不仅仅是接口的安全性，安卓客户端的代码也要考虑到反编译的可能性需要混淆。
7、产品层面：做好防刷和暴力破解控制。
显性的功能固然重要，但是产品经理也需要在隐性功能和风控策略上下一些功夫，产品经理没有这方面意识的话开发往往更不太会做深入考虑。
8、产品层面：注意产品逻辑一体性。
对于多步走的逻辑，我们一定要作为一个整体来思考。黑客在寻找突破的时候特别喜欢寻找ABC几步走的逻辑，然后尝试最后一步C是否可以单独来做寻找逻辑方面的漏洞。
9、运维层面：做好异常数据监控报警。
我们需要对方方面面的数据有报表或监控，对于异常的数据徒增及时进行调查，业务量的增加如果不伴随活动或推广的话不一定是好事情。
10、运维层面：对内的数据和权限问题
- 线上的配置尽量加密，配置信息和代码分离
- 敏感数据（用户信息）在数据库中加密保存
- 线上数据访问需要使用类似于phpmyadmin的Web网站，不允许使用客户端工具，这样可以做比较健全的授权，防止数据导出
- 内部系统涉及到用户信息部分脱敏显示，显示完整的数据需要上级授权
- 所有内部系统的登录和使用需要有完整的日志，对日志进行分析和定期的审计
注：原文链接：https://mp.weixin.qq.com/s/gd-XqGGh08o-vWFZSR0RJg