微服务接口的防刷、防重、限量应该如何设计？

安全兜底分级：

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

分级之后，再进一步划分处理的级别。因为人力和时间都是有限的，很难将所有的安全兜底都控制的那么完美，那就优先保证一些损失影响可能较大的业务上。

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

安全第一步

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

如何防刷？

验证额外参数信息

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

先过注册页

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

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

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

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

增加前置操作

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

2 限量

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

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

幂等

考虑如下：

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

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

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

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

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

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

防刷、幂等其实都是事前手段，若系统正被攻击或利用，如何发现问题？

监控是较好的手段，难点是报警阈值的设置，可以对比昨天同时，上周同时的量，发现差异达到百分比阈值就报警。此外，对于活动可以申请单独的活动监控标签，单独呈现曲线，做好量的预估，超量报警，有的时候大盘很大的话活动给整个大盘带来的变化不明显。 可通过监控实现类似熔断机制，比如数据监控某个功能在被刷，触发报警，同时熔断，暂时把该功能禁掉，减少损失。

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

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

一般因为啥呢？

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

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