攜程在線風控系統架構

為了應對日益嚴重的支付欺詐，攜程在線風控系統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系統的架構和演進過程，當然演進的過程還在持續，現階段的目標是將平臺化的系統繼續發展，做到服務產品化。

【作者簡介】蔣一新，攜程風險控制部技術專家，負責風控運營平臺、數據分發、關系圖譜、名單服務等多個風控子系統；風控引擎性能優化主要實施人員。

來自：http://techshow.ctrip.com/archives/2548.html