为了应对日益严重的支付欺诈行为，携程在线风控系统于2011年正式上线。目前，在线风控系统支持携程每日实时处理1亿+风险事件和100亿+准实时数据。预处理；系统中运行的规则总数和模型总数分别达到+和20+。 ;风控范围从单纯的支付风控拓展到各类业务风控（例如：恶意抢占资源、黄牛抢购、商户刷单）。

下图是目前线上风控系统的整体技术架构图：

目前的系统架构是比较主流的风控系统架构，包括决策引擎、名单库、用户画像、离线处理、离线分析和监控等主要模块。携程网上风控系统发展到现阶段，经历了三次重大改版。

1. 初始设立

它于 2011 年推出，使用 .net 开发的服务。数据库使用SQL。简要架构图如下：

此时风控服务将所有线上决策功能整合到一个系统中，包括规则判断、单子库、流量计算等；而这些逻辑都是基于数据库的。

流量计算：通过明细表执行SQL获得（例如：( ) ...[2]）

规则判断：数据库记录大于、小于、等于等判断规则，接收到风险事件后，获取流量值并与规则进行比较，得到最终的风险判断。

列表数据库判断：数据库维护黑白名单信息（属性类型、属性值、判断依据等），程序判断风险事件中的值是否命中列表。

基于当时携程的风控需求，系统重点满足功能。上线一段时间后，随着携程业务的增长，风控系统的流量不断增加。基于SQL的流量统计耗时严重，严重限制了系统的响应时间，因此进行了第一次性能优化改版。

2.流量查询性能优化及修正

由于此时主要的性能瓶颈是数据库实现的流量查询，因此本次优化的主要方向是优化流量查询的实现：在原有单一数据库的基础上，采用分库分库的方法。 -工作台均匀分布压力，实现更快的响应。时间和更高的吞吐量。架构图如下：

优化后，流量库和业务库分离。流量库采用多个数据库实例，使用hash拆分流量明细，使用SQL进行统计。由于压力由多个数据库实例分担，提高了系统的流量查询性能。

新版本上线后，携程业务对风控系统提出了更多要求：

1、更方便、更快捷的接入：除了支付风险，业务风险也需要风控支持；

2.更多外部数据访问：用户信息、位置信息、UBT信息；

3、更丰富的规则逻辑：支持任意变量的规则判断，支持更多的判断逻辑；

4、性能更高：流量提升10倍，响应时间不超过1秒；

5、编程语言更新：携程在公司内部推动.net向Java的转换。

然后又进行了一次重大的修改，为现在的线上风控系统奠定了基础。

3.风险控制3.0()

从该版本开始，风控系统全面转向Java开发。同时，对核心模块进行了服务分离，明确了各个子系统的边界及其在整个系统中的定位和作用。与以往的功能应用相比，它是一个平台化的风控系统。下面是一个简化的系统架构图：

开始使用脚本来编写规则，这大大提高了规则团队对紧急情况的响应时间。紧急规则通常可以在10分钟内上线。

从结构上来说，风控引擎分为同步引擎和异步引擎。同步引擎运行用于实时判断风险结果的规则和模型；异步引擎负责验证规则/模型、数据分发、关键数据落地等逻辑。同步/异步引擎设计为无状态，方便随时扩展。

在流量统计方面是自研的，是一个定制的类似TSDB的服务。任意时间窗口、任意精度的查询控制在5ms以内。它还支持高并发查询。与SQL实现相比，性能提升数千倍。支持当前风控系统中每项服务每天数百亿次的查询。下图是简要的结构说明：

数据预处理层面独立开发风险分析和两项服务。

风险剖析服务为引擎提供实时的用户和订单画像（用户等级、用户行为标签、订单资源标签等）作为规则和模型的输入变量；其数据来源为实时引擎数据、准实时MQ数据清洗服务、离线数据导入三部分。

该服务封装了所有外部接口和数据库访问，并根据不同的数据特​​征配置不同的缓存策略，确保99.9%的请求在10ms内获取所需数据。

此外，还有以下主要服务：

列表数据库服务支持多个独立列表数据库，并优化列表判断逻辑，单次查询（10维度）响应小于10ms。

配置服务集中了系统中各个应用程序需要配置的功能，并提供集中的配置服务让各个应用程序获取相应的配置。

事件处理平台用于处理引擎无法确定或需要人工干预的事件。

性能监控服务监控系统中各个服务的健康状况，并提供预警和报警功能。

业务监控服务监控规则模型的运行情况、返回的风险结果、事件耗时等业务级数据，并提供预警和报警功能。

系统上线后，新增风控业务接入时间缩短至一周。随着10倍的流量增长和更复杂的规则执行，平均耗时控制在300+ms，是之前版本的两倍多。

后来，两个重要的子系统被添加到该家族中： 和 。这两个服务都是准实时处理应用，但都是通过预热的方式向引擎提供实时数据。

，减少用户的页面访问来反映用户的操作，流程如下：

其数据处理采用自主研发的大数据处理系统。架构图如下：

服务用于指纹数据采集和指纹识别生成，以确定设备的唯一性。它还用于数据处理。系统框图如下：

这两项服务为规则、模型以及人工处理提供了非常关键的判断数据，进一步提高了风险判断的准确性。

至此，系统的功能已经比较完善了。但在一年多的运行过程中，发现随着流量、规则量、模型量的不断增长，实时风控的响应时间呈现缓慢下降的趋势，超时（1秒）。数量在千分之一左右，然后会有持续的性能优化。

4、实时风控性能优化

性能优化从一年前开始，主要分为以下几个优化：

1.规则的分布式并行执行

将单个事件需要执行的规则和模型拆分到同一逻辑组中的多台服务器上执行，最后合并数据。此优化将平均耗时降低至200+ms

2.将脚本执行引擎切换为Java

编写规则时使用模板屏蔽特殊语法，然后将脚本编译成Java执行。规则执行性能提升一倍，整个引擎平均实时耗时降低。

3.开发Java模型执行引擎

Java版的随机森林和逻辑回归算法已经完成，比使用它的性能提高了一个数量级。

完成上述优化后，整个系统只需增加服务器就可以满足短期内的扩容需求。

以上就是系统架构和演进过程。当然，演化过程仍在继续。现阶段的目标是继续开发平台化系统，实现服务产品化。

本公众号编辑部维护读者群结构，邀请资深读者李彦鹏、曲健、魏山、石海峰等嘉宾参与交流。入群请回复公众号：建筑群。