DataVisor风控架构设计与OpenResty实战

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

01

风控业务痛点

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

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

02

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抖动，没有大延时。可以解决风控系统低延迟的业务痛点。

03

风控查询裂变

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的痛点。

04

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

1. 脚本热加载

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

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

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

2. OpenResty 动态脚本配置后台

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

05

自动熔断&快速恢复

1. DataVisor自动熔断恢复系统

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

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

2. DataVisor自动熔断恢复系统

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

06

单体应用还是微服务

1. 单体应用 VS 微服务

① 单体应用

单体应用优点：

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

单体应用缺点：

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

② 微服务

微服务优点：

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

微服务缺点：

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

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

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

优点：

• 每一个业务逻辑块均可以看做是一个独立的“微服务”
• 业务块之间做调用采用OpenResty的子调用，这个性能相当于是一次C函数调用非常高效
• Server直接调用是本机API调用，省去了网络传输 消耗和CPU消耗

缺点：一个实例挂了，所有业务逻辑都挂了。

07

水平切分与垂直切分

水平切分按逻辑层。不同业务垂直切分，但部分数据会共享。

• 网关接入与业务处理作为整个系统的一级系统，需要做最高的可用性保证，数据收集、数据分析为内部系统，可用性保证较低。
• 不同业务直接做垂直切分，防止业务间互相影响故障级联。

08

DataVisor 设备指纹产品系统架构演进

1. DataVisor 设备指纹产品架构 V1

有网关、服务器、数据库、消息收发。

2. DataVisor 设备指纹产品架构 V2

蓝色部分继承自V1中的内容，其他是V2新增内容。Pika代替cassandra，是因为性能更好。可以进行水平和垂直切分。Kafka及右侧，是分析模块，日志收集上面是稳定性保障模块。

09

下一代软件架构 Service Mesh

1. DataVisor 设备指纹产品架构 V3 Service Mesh?

• 一代中sidecar 副驾，做服务发现等支持，但功能比较少。
• 二代中，蓝色方块可以看做sidecar，做节点之间的相互连接、信息交互、转发等。绿色方块是专注于业务逻辑，不关心网络等的交互。

2. DataVisor 设备指纹产品架构 V3 OpenResty Sidecar

特权代理(privileged agent)，有root权限，给它fork一个sidecar功能的进程，和其他进程交互连接、请求数据等，和其他worker进程交互也会很方便，比如共享内存、信号量来实现不同worker间的数据通信。

10

我的架构师感悟

从ToB的角度：

懂业务 + 懂技术 + 懂客户 = 合格的架构师

学会做减法比学会做加法更有用

高性能、高可用、易扩展、低成本要牢记在心，让产品没有后顾之忧

今天的分享就到这里，谢谢大家。