做服务端开发也有7年的时间了，从开发-高级开发-技术经理-高级开发-?。重新做回程序员，尽管心里上难免有些不甘心，但是按照欲进先退的理念，我确定我的下一个方向是架构师。
今天谈谈对接口安全的浅略认识：
接口安全从两个方面分析下：
- 性能安全
- 数据安全
古人教导我们未雨绸缪，居安思危。做服务端开发更是如此，在以前传统的开发领域我们可能只会关心数据安全，不会考虑性能问题。但是在目前分布式、soa、微服务、高并发等互联网思维下，我们开始对我们的服务进行拆！拆！拆！拆的原因有很多：
- 共享服务：和共享代码一个道理，提高使用效率
- 服务解耦：各个团队负责自己的业务，使用者自己决定使用哪些服务，针对不同的服务可以有不同的技术方案
- ....
总体来说，就是高内聚，低耦合。
但是服务拆分后会产生一系列的问题等待解决，比如分布式事务问题。
性能安全：
出于各种原因，你的服务可能遇到性能问题，异常的网络攻击，人为的接口盗链、广告灌水，批量刷注册用户等！
所以从性能安全上可以有以下考虑：
- https:安全的网络协议，让内容不再明文线上。ios平台未来会强制使用https
- 接口签名：做基于privatekey的对称加密，可以把时间戳加进去参与签名，控制接口有效时间
- 基于网络层的屏蔽：1和2的思路还是不要让人去破解你的接口规则，防止通过参数篡改内容，但是如果是对于算法已经被破解，或者接口在有效期内的请求，我们应该做频率限制，目前可以用nginx+lua+redis自己写规则，也可以用nginx通过HttpLimitReqModul和HttpLimitZoneModule配置来限制ip在同一时间段的访问次数
- 接口的幂等性：这个属于数据安全范畴，无论是客户端httpclient重试、dubbo rpc重试、还是分布式事务中业务自己需要重试，都会造成统一服务的多次调用。因为超时所以重试，然而超时不代表业务失败，A调用B的超时时间是10ms，但是B执行了11ms，对于A来说业务失败，而实际上B是成功执行的。所以B服务的实现需要是幂等的。那么问题来了：
什么是幂等性：我理解就是进行多次调用/执行，不影响结果的正确性。
那是不是所有的接口都要考虑幂等性，听起来好像和麻烦很可怕，那我们具体分析下：
查询类服务：不用考虑幂等性，因为查询本身就是幂等的
删除类服务：不用考虑幂等性，因为多次删除的结果一样
更新累服务：update a="xxx"不需要，update a = a+1需要
增加累服务：多次add要考虑幂等性
组合操作服务：一个服务需要删除+增加，需要考虑
如何避免不幂等带来的问题？
- add update 等操作不要设置重试（客户端不要重试，dubbo服务也可以设置是failfast的,...）
- 分情况考虑:完全避免重试不可能，比如客户端提交注册信息，结果请求超时，但是最终还是插入到数据库了。但是对于客户端来说，应该提示用户进行重新提交。SO看情况了:必须保证幂等（数据唯一索引避免重复，其它业务逻辑）；不考虑幂等（多次评论就多次评论吧，谁让你接口慢呢。服务端客户端开始互相撕逼了）
时间： 2024-10-15 21:36:16