# 《Seckill秒杀系统》第114章:秒杀系统风控模型设计
作者:冰河
星球:http://m6z.cn/6aeFbs (opens new window)
博客:https://binghe.gitcode.host (opens new window)
文章汇总:https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址:https://t.zsxq.com/0dhvFs5oR (opens new window)
沉淀,成长,突破,帮助他人,成就自我。
- 本章难度:★★☆☆☆
- 本章重点:理解秒杀系统风控模型可扩展、可配置、可编排的设计之道,掌握如何设计高度可扩展、可配置、可编排的风控模型,从代码角度理解如何设计高度可扩展的代码,并能够将其灵活应用的自身实际项目中。
大家好,我是冰河~~
黑灰产的能力比我们想象的要强很多,建设风控系统对抗黑灰产是一个长期且艰巨的任务,我们不能将对抗黑灰产的艰巨任务寄托于任何现有的代码上。要知道,黑灰产所使用的技术也是在不断更新和迭代的,所以,我们在设计秒杀系统的风控模型时,不仅仅是要完成风控所具备的一些功能,更重要的是要将风控模型高度可扩展、可配置、可编排化,任何时候,基于高度可扩展、可配置、可编排的模型设计,能够非常方便并且快速的加入任何风控规则和实现逻辑。
# 一、前言
在前面的文章中,我们介绍了黑灰产和风控的基础知识,并且对风控模型的架构与落地方案进行了详细的介绍。那对于我们的秒杀系统来说,要如何实现风控的逻辑呢?其实,不管是写业务代码还是实现风控逻辑,我们都不能只关注眼下的功能需求,或者一上来就想开发一个非常完善的风控系统,一上来就开始一个非常完善的风控系统几乎是不可能的。
风控是需要建立在海量数据之上,并且在各种场景下需要不断升级和优化,所以,我们在开发风控逻辑时,首先要设计一个高度可扩展、可配置、可编排的风控模型和执行流程,能够在原有执行逻辑和执行流程的基础上,快速新增其他风控规则,以便快速迭代和开发其他风控逻辑。
# 二、本章诉求
对秒杀系统的风控模型和执行流程进行设计,从总体上了解秒杀系统风控逻辑的执行流程,并重点掌握高度可扩展、可配置、可编排的架构设计和代码设计,结合自身实际项目思考如何将高度可扩展、可配置、可编排的代码设计灵活应用到自身实际项目中。
# 三、可扩展流程设计
在秒杀系统中,我们在业务网关中基于责任链模式实现了多重风控校验模块,预留了大量的风控扩展点。还是那句话,一上来就设计和实现一个非常完善的风控系统是不可能的。在设计和实现风控规则时,我们要做到高度可扩展、可编排和可配置,随时可以扩展其他的风控规则,也能够随时对这些风控规则进行编排,同时,能够随时配置风控的具体规则。
当请求进入业务网关时,会触发风控规则,此时会执行风控链中的校验规则,只有经过所有过滤器链的校验之后,请求才会被业务网关路由到正确的服务上执行后续业务逻辑,总体如图114-1所示。
可以看到,用户在访问秒杀系统时,请求会首先到达流量网关,经过流量网关的流控、限流、防刷和黑白名单等校验,到达业务网关。在业务网关会经过多重风控校验和鉴权校验。而在多重风控校验设计中,会提供风控扩展点接口,后续要新增风控规则时,只需要新建一个扩展点实现类,实现风控扩展点接口即可,并且可以对这些具体的风控逻辑进行编排,使其按照自己想要的顺序执行,完全做到了高度可扩展、可配置和可编排。
实现了风控可扩展点接口的具体实现类,就是风控要执行的具体逻辑了,在执行风控逻辑时,会以责任链模式以此执行风控可扩展接口实现类中的逻辑,例如:账户风控、IP风控、设备风控、防攻击风控、自定义风控、其他风控等等。只有通过所有风控逻辑的校验之后,接下来就是对请求进行鉴权校验,通过鉴权校验的请求才会被业务网关路由到目标微服务执行具体业务逻辑。
# 四、风控模型设计
# 查看完整文章
加入冰河技术 (opens new window)知识星球,解锁完整技术文章与完整代码