自以为是取不得-Feign的消息解析机制撞上接口设计特殊情况导致的线上问题定位和解决(二)

ps:阅读这个系列的博客,请大家一定要把三篇文章阅读完整,否则会被带跑偏了(狗头保命)

前情回顾和观点修正

第一篇中我说了关于风控报错,交易还是通过了的问题,并且特别指出了,风控系统抛出异常报错啥的,后面的过程肯定不能让继续了呀这样的观点,当天下班之余,我问了我的组长和我之前一个比较要好的同事,他们说如果风控系统出问题了(极端情况下,前提必须保证高可用),交易还是要继续的,因为你不可能因为一个风控环境出问题,为了防止那几个很大可能都不会存在的欺诈用户被拦截而选择让所有的用户收到影响.

首先这个问题就不应该出现,或者说出现后立马就应该恢复,因为这种业务前提必须保证高可用,真正的高可用等同于不出问题(指服务挂了等),如果出现了,应该在代码中也有体现,比如这里的风控,要想筛除这几个可能不存在的欺诈请求,其实可以在很多地方做,比如我们这里就有两侧风控,我说的这个是经过了第一层风控后来到的,所以这个欺诈几率又可以大大降低,在这种情况下,就更不应该因为一个相对独立的系统出现故障导致整个环境直接终止,这无论在业务上还是在技术方案上都是不正确的.

当然这也需要针对特定的业务,极端的业务情况下,风控系统挂了,交易也应该结束,比如银行之间的超大额转账流程,这种业务首先用户量就很少,就算直接影响全流程,实际影响的范围也不大,但是一旦除了问题就损失巨大了,所以在综合考虑两点损失的大小后,再做出决定,具体的两边考虑点我觉得是这样的:

第一点是如果刚好有欺诈请求,那么这段时间造成的损失(这一点需要考虑概率,我们这里的业务的概率已经很低很低了) 第二点是这段时间对所有的用户造成了业务影响,这种全面的损失

综上,我收回我昨天说的风控系统挂了,整个环节结束的错误观点,这里我能认识到,我在整个系统设计和业务理解上的不足,后续一定要仔细思考每一个决定对整个系统的影响.

ps:这个错误观点,其实这里我有受到部门一个测试同事的影响,我当时问他站在测试的角度看,在支付这个业务中,如果执行过程中,风控系统挂了,那么本次的交易或者开卡业务是不是直接是一定不能通过才算正常逻辑,他说是的,这里我不能说他的想法有问题,因为他是一名测试人员,可能呢对于测试来说,这个环节缺少了安全校验,而只有安全校验通过了才能继续,所以他觉得不能交易,但是我作为系统开发设计人员,还是应该更多的综合业务和技术架构的角度来看待类似的问题.

如果大家有不同的观点,欢迎下面讨论,毕竟这也不是绝对的观点.还是要综合业务场景考虑.

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2022/05/12 20:23