DataVisor风控架构设计与OpenResty实战

分享嘉宾：赵晓彪 DataVisor 架构师

编辑整理：陈丽虎牙游戏

出品平台：DataFunTalk

导读：本文主要从实用的角度，给大家讲解一下DataVisor的风控架构，以及在风控架构中如何使用OpenResty。

风控业务痛点

今天主要围绕以下5个风控通点，详细讲解DataVisor的处理方案。

风控业务逻辑复杂：主要体现在查询逻辑和计算逻辑有很多关联。
数据量巨大：查询大量历史数据，有些历史数据会在数仓等冷数据库中，查询比较慢。
有较高qps/tps：日增千万的数据量，涉及业务比较多，所以qps比较高。
低延迟：风控要求50-200ms的低延时，以保证业务正常运行。
风控策略变化快：因为黑产、羊毛党等时刻在测试风控规则，改善黑产工具，所以需要及时调整风控策略，避免黑产攻击。

OpenResty介绍

1. OpenResty是什么

OpenResty是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

2. 为什么使用OpenResty

业内大多使用OpenResty做为流量接入网关， K8S ingress等。如开源的 Kong，APISIX 等优秀的网关均是基于OpenResty实现的。而我们不仅将OpenResty做为网关承接业务流量，也使用OpenResty做业务逻辑开发。

3. OpenResty优势：

开发速度高：没有Lua经验的程序员，1-2天学习Lua后即可上手。
运行性能高：对Lua和C进行性能对比测试，Lua使用的性能约使用了C语言的70%。所以OpenResty是Nginx+Lua，性能约等于c语言。
动态加载脚本：Lua是脚本语言，支持热加载，热部署。
资源占用低：每个worker占用资源十几MB~几十MB，消耗较少。
没有STW：GC比较平滑，不会出现长延时和大量毛刺的问题。

4. OpenResty优异的GC性能

线上性能截图展示：p50（绿色线）一般在2-3ms，比较稳定。P90（黄色线）在稍高的5-6ms，p99在p90高出2-3ms，多出的不多。从图中看出没有大的GC抖动，没有大延时。可以解决风控系统低延迟的业务痛点。

风控查询裂变

1. 典型的金融风控查询逻辑

一次风控查询需背后，要级联做多次子查询。
子查询需要并发执行。
风控请求时延仅允许在100-200ms以内。

OpenResty使用capture调用内部接口，性能消耗较低，类似于调用C函数的性能。使用cosocket调用外部接口，支持多种连接。可以解决风控系统业务逻辑复杂的痛点。

2. OpenResty的capture_multi & cosocket

capture_multi：

对于没有依赖关系的step1、step2、step3查询，可以并发查询。

cosocket：

协程+socket实现。Nginx实现事件驱动，Lua层使用协程并发，以同步的方式编写异步代码，避免繁琐的callback、事件等待、异常处理等逻辑。
cosocket可以提供基于TCP/UDP协议的上下游连接，比如上游连接数据库Mysql、Redis，连接Websocket服务器、DNS服务器等。
可以解决风控系统有较高qps/tps的痛点。

快速应对新型的攻击手段：脚本热加载

1. 脚本热加载

部署OpenResty实现业务过滤，Metadb存储策略（比如：同设备登录用户超过3个，就拦截或二次认证）。策略配置平台调用Lua脚本生成器，并把生成的Lua脚本写入Metadb，然后可以向OpenRestry发起指令。整个过程无需重启，指令实时生效。可以解决风控系统策略变化快的痛点。

可以配置灰度发布或预发布。可以发指令给OpenRestry，使其只在其中一个worker进程中运行新策略，使用线上真实流量测试策略是否生效。

可以支持离线数据回放。把离线历史数据导入数据库，进行历史数据回放，查看策略执行效果。

2. OpenResty 动态脚本配置后台

‍‍‍‍‍‍‍‍‍‍‍‍‍选择API，选择APPKey或者某个用户，填写Lua脚本，点击创建就生成配置。点击发布后，就在OpenResty中生效了可以选择全量发布或灰度发布。

自动熔断&快速恢复

1. DataVisor自动熔断恢复系统

风控系统如果出现超出预期的拦截量误伤，需要尽快自我熔断。

进入OpenRestry熔断系统后，进入不同后端服务，如果出现异常情况就把流量导入YesBox，YesBox只对流量做接收然后放过。使用Prometheous、Altermanager、Grafana监控业务。配置熔断策略导入Altermanager，当达到熔断阈值时，Altermanager会向OpenResty发指令，秒级响应切换流量到YesBox。在灰度发布中，可以对已发布的服务进程，进行熔断处理。

2. DataVisor自动熔断恢复系统

2个节点的集群，在时间18:17，手动触发某一节点异常，该节点请求迅速跌至0，会在一段时间内无请求，中间只有一些探测流量，在18:30时，服务开始恢复，流量开始上升，恢复至正常流量。给风控系统多一层保障。

单体应用还是微服务

1. 单体应用 VS 微服务

① 单体应用

单体应用优点：

方便调试，代码都在一起；
没有分布式开销，所有服务都在本地容器内；
中小型项目可以快速迭代，不需要太多资源。

单体应用缺点：

系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。

② 微服务

微服务优点：

职责单一，业务内部逻辑简单
自治，可独立部署与测试
方便扩展

微服务缺点：

部署复杂度高，服务间的调用经常是跨机器乃至跨机房
运维复杂度高，需要有个非常强大的运维团队

2. DataVisor是一种基于OpenResty的“微服务”

和Ngix类似，每个接口都是一个location，将相关的逻辑服务（比如业务1的逻辑接口）放在一起，包装成假想的业务逻辑server块1。将不同的业务打包成业务逻辑server块2、3、4，不同业务逻辑server块可以运行在同一个端口上，使用capture内部调用，实现内部微服务调用。如果需要根据业务分不同server，比如server1和server2，可以通过本机接口调用，节省网络耗时和cpu网络调度，如果需要数据共享，可以通过进程间内存共享，比如通过redis、管道、订阅发布。这样可以单机实现类似分布式模式。

优点：