微服务接口的防刷、防重、限量设计

微服务接口的防刷、防重、限量设计

安全兜底分级：

1. 无限额涉及钱
   如退款
2. 限额涉及钱
   为用户提供的红包奖励等，通常限额
3. 无门槛虚拟货币
   无门槛优惠券、积分等，由于这部分基本与货币可以等值，但是由于存在可以追回的机会，所以尚存一些容错）
4. 有门槛虚拟货币
   为了促销，并不会带来实质经济损失，没那么敏感

再划分处理级别。人力、时间有限，很难将所有安全兜底完美，优先保证一些损失影响可能较大的业务。

• 权重更高的业务，予以更严谨测试及附加的人工审核机制，更频繁监控等
• 权重较低的，重视程度不那么高，仅保留较低限度兜底

1 防刷

最常见的短信验证码服务，由于是注册用，所以无需登录就能调用。若发短信接口无任何保护措施，直接调用三方短信通道，很容易被短信轰炸平台滥用。

1.1 如何防刷？

1.1.1 验证额外参数信息

验证客户端请求头的一些额外参数，如是否存在浏览器或手机型号、设备分辨率请求头。爬虫一般只能接收到URL。

先过注册页

无论何种客户端注册，一定要先进入注册页，才能看到验证码按钮。
可在页面打开时请求固定的前置接口，为这设备开启允许发送验证码的窗口，之后的请求发送验证码才算合法请求。

这可拦截绕过固定流程，直接通过接口调用验证码的请求。

控制同一手机号的发送次数、间隔

除非没收到短信，否则用户不太会请求了验证码后不点击注册，还重新请求。
可限制同一手机号每天的最大请求次数。控制好发送时间间隔。

增加前置操作

短信轰炸平台会收集很多免费短信接口，而且一个接口它们也只会给一个用户发一次短信，不会触发上一条规则。
可将图形验证码作为前置条件。🐂🍺的还可使用滑块、验证码文字点击、人机检测。

2 限量

对优惠券这种虚拟资产，平台方必须确保其使用界限。

对商家，可能只是收到一个用户支付的订单，并不知道用户使用平台优惠券。
大部分平台和商家都是事后对账结算，所以下单了就会马上安排发货，事后造成大量资损。大量跟风网络主播被薅羊毛的店铺就是这么没的。

优惠券应该需要提前申请：用于何种活动、谁申请的。

幂等

考虑如下：

1. 幂等依据
   每次交互生成的token、客户端的序列号、有意义的业务订单号等
2. 根据幂等依据进行幂等处理：

• 限制：如锁、状态机控制
• 去重

先有订单，再操作资金。任何资金操作都要在平台侧生成业务属性订单，可以是优惠券发放订单，可以是返现订单，也可以是借款订单。

订单的产生必须要有业务属性：
如返现发放订单必须关联到原先的商品订单、借款订单必须关联到那个借款合同。

幂等处理须全链路，从开始到最后都贯穿使用相同业务订单号，才能实现最终的支付幂等。

支付操作一般是调用三方支付接口。这些接口都会有商户订单号，相同商户订单号不会重复处理，所以三方公司的接口可实现唯一订单号的幂等。

防刷、幂等都是事前手段，若

3 系统正被攻击或利用，如何发现问题？

监控难点：报警阈值设置。

可对比昨天同时，上周同时的量，发现差异达到百分比阈值报警。

对于活动，申请单独的活动监控标签，单独呈现曲线，做好量的预估，超量报警，有时大盘很大的话，活动给整个大盘带来的变化不明显。
可通过监控实现类似熔断机制，如数据监控某个功能在被刷，触发报警，同时熔断，暂时把该功能禁掉，减少损失。

任何第三方资源的使用一般都会定期对账，若对账发现：

我方系统记录的调用量 < 对方系统记录的使用量

一般因为：

• 可能在一个事务内调用外部接口，调用超时后事务回滚，导致本地没有保存数据
• 我方系统对第三方调用返回值处理不当，导致重复调用，即没做幂等

推荐所有第三方服务的交互，将request和response完整记录到数据库。