乾貨 | 攜程線上風控系統架構

作者簡介

蔣一新，攜程風險控制部技術專家，負責風控運營平臺、資料分發、關係圖譜、名單服務等多個風控子系統；風控引擎效能最佳化主要實施人員。

*本文首發於GitChat，轉載請註明* 

為了應對日益嚴重的支付欺詐，攜程線上風控系統2011年正式上線。現在，線上風控系統支撐了攜程每日1億+的風險事件實時處理和100億+的準實時資料預處理；系統中執行的總規則數和總模型數分別達到了1萬+和20+；風控的範圍從單純的支付風控擴充套件到了各種型別的業務風控（例如：惡意搶佔資源、黃牛搶購、商家刷單）。

下圖是當前線上風控系統的整體技術架構圖：

當前的系統結構是比較主流的風控系統結構，包含了決策引擎、Counter、名單庫、使用者畫像、離線處理、離線分析和監控各主要模組。攜程的線上風控系統發展到這個階段一共經過了3次重大的改版。

一、最初創立

2011年上線，使用了.net開發的服務，資料庫使用SQL Server，簡要架構圖如下：

這個時候的風控服務將所有線上決策功能整合在一個系統內實現，包括規則判斷、名單庫、流量計算；而這些邏輯都基於資料庫實現。

流量計算：透過明細表執行SQL得到（例如：SELECT COUNT(DISTINCT orderId) FROMt1 WHERE …[2]）

規則判斷：資料庫記錄大於、小於、等於等判斷規則，接收到風險事件後獲取流量值和規則進行比較，得到最終的風險判斷。

名單庫判斷：資料庫維護黑白名單資訊（屬性型別、屬性值、判斷依據等），程式判斷風險事件中的值是否命中名單。

基於當時攜程對風控的需求，系統以滿足功能為主。在上線執行一段時間後，隨著攜程業務的增長，風控系統的流量不斷增加，基於SQL的流量統計耗時嚴重製約了系統的響應時間，因此有了第一次的效能最佳化改版。

二、流量查詢效能最佳化改版

由於這個時候的主要效能瓶頸在於資料庫實現的流量查詢，這次最佳化主要方向就是最佳化流量查詢的實現：在原來單個資料庫的基礎上，採用分庫分表的方式均攤壓力，以達到更快的響應時間和更高的吞吐量。架構圖如下：

最佳化之後，流量庫和業務庫分離，流量庫使用多個資料庫例項，使用hash的方式拆分流量明細，統計的時候使用SQL。由於壓力被多個資料庫例項分攤，使得系統的流量查詢效能得到了較好的提升。

新版本上線後，攜程的業務又對風控系統提出了更多的要求：

1.    更方便快捷的接入：除了支付風險，業務的風險也需要風控支援；

2.    更多的外部資料接入：使用者資訊、位置資訊、UBT資訊；

3.    更豐富的規則邏輯：支援任意變數的規則判斷，支援更多的判斷邏輯；

4.    更高的效能：流量10x的增長，響應時間不超過1秒；

5.    程式語言的更新：攜程推動公司內.net轉java。

然後，就有了奠定當前線上風控系統基礎的重大改版

三、風控3.0（Aegis）

從這個版本開始，風控系統全面轉向Java開發，同時將核心模組獨立成服務，定義了各子系統的邊界以及在整個系統中的定位和作用。相比之前功能性的應用，Aegis是一個平臺化的風控系統。以下是簡化的系統架構圖：

Aegis開始使用Drools指令碼用於規則的編寫，極大的提高了規則團隊對突發事件的響應時間，緊急規則一般10分鐘就能上線。

在結構上風控引擎分為同步引擎和非同步引擎，同步引擎執行用於實時判斷風險結果的規則和模型；非同步引擎則負責驗證規則/模型、資料分發、關鍵資料落地等邏輯。同步/非同步引擎設計成無狀態的，方便隨時擴容。

Aegis在流量統計上自研發了Counter Server，這是一個定製化的類TSDB服務，任意精度任意時間視窗的查詢控制在5ms，同時支援高併發查詢，相較於SQL的實現提升了上千倍的效能。支撐了現在風控系統內個服務每日百億次的查詢。下圖是其簡要的結構說明：

在資料預處理層面獨立出了風險畫像和DataProxy兩個服務。

風險畫像服務為引擎提供實時的使用者、訂單的畫像（使用者等級、使用者行為標籤、訂單資源標籤等）作為規則和模型的輸入變數；其資料來源是實時的引擎資料、準實時的MQ資料清洗服務、離線的資料匯入三部分。

DataProxy服務包裝了所有對外的介面和資料庫的訪問，並針對資料特性的不同配置了不同的快取策略，保證99.9%的請求在10ms內獲取到所需的資料。

此外還有以下幾個主要的服務：

名單庫服務，支援多個獨立的名單庫，最佳化了名單判斷邏輯，使得單次查詢（10個維度）的響應小於10ms。

配置服務，集中系統內各個應用需要配置的功能，提供中心化的配置服務讓各個應用獲取響應配置。

事件處理平臺，用於處理引擎無法判斷或需要人工干預的事件。

效能監控服務，監控系統內各服務的健康狀態，提供預警和報警功能。

業務監控服務，監控規則模型執行情況、返回的風險結果、事件耗時等業務層面的資料，提供預警和報警功能。

Aegis系統上線後，新風控業務接入時間縮短到一週，在10x流量增加和執行更多更復雜的規則的情況下，平均耗時控制在300+ms，比上一版本提高了1倍多。

之後Aegis家族又增加了兩個重要的子系統：Sessionizer和DeviceID。這兩個服務屬於準實時處理應用，但是都透過預熱的方式為引擎提供了實時資料。

Sessionizer，歸約使用者的頁面訪問session為反應使用者的操作的RiskSession，流程如下圖：

其資料處理使用了自研的大資料處理系統Chloro，架構圖如下：

DeviceID服務，用於指紋資料採集和指紋識別生成，從而判斷裝置的唯一性，同樣也藉助了Chloro進行資料處理，系統示意圖如下：

這兩個服務為規則和模型以及人工處理提供了非常關鍵的判斷資料，進一步提高了風險判斷的準確性。

只此，Aegis系統的功能已比較完善，但在1年多的執行過程中發現隨著流量和規則、模型量的持續增長，實時風控的響應時間出現緩慢下滑的趨勢，超時（1秒）的量在千分之一上下，然後就有了之後持續的效能最佳化。

四、針對實時風控的效能最佳化

效能最佳化從1年前開始，可以分以下幾個主要最佳化：

1、規則分散式並行執行

將單個事件需要執行的規則和模型拆分到同一邏輯組內多個伺服器執行，最終合併資料。這個最佳化將平均耗時降到了200+ms

2、指令碼執行引擎切換Drools到Java

使用模版遮蔽編寫規則時drools的特殊語法，之後將指令碼編譯成Java class執行。規則的執行效能提升1倍，整個引擎的實時平均耗時降入100ms。

3、開發Java的模型執行引擎

已完成隨機森林和邏輯迴歸演算法的Java版，相較使用Python，提高了一個數量級的效能。

完成上述最佳化後，整個系統在短期內，只需要簡單的增加伺服器，就可以滿足容量擴張。

以上就是Aegis系統的架構和演進過程，當然演進的過程還在持續，現階段的目標是將平臺化的系統繼續發展，做到服務產品化。