攜程在線風控系統的架構解析和問題總結

GIF/13K

【不要錯過文末彩蛋】

編輯 杜隆坦

前言

為了應對日益嚴重的支付欺詐，攜程在線風控系統2011年正式上線。

現在，在線風控系統支撐了攜程每日1億+的風險事件實時處理和100億+的准實時數據預處理；

系統中運行的總規則數和總模型數分別達到了1萬+和20+；

風控的範圍從單純的支付風控擴展到了各種類型的業務風控（例如：惡意搶佔資源、黃牛搶購、商家刷單）。

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

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

最初創立

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

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

流量計算：通過明細表執行SQL得到（例如：SELECT COUNT(DISTINCT orderId) FROM t1 WHERE … ）

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

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

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

流量查詢性能優化改版

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

優化之後，流量庫和業務庫分離，流量庫使用多個資料庫實例，使用hash的方式拆分流量明細，統計的時候使用SQL。

由於壓力被多個資料庫實例分攤，使得系統的流量查詢性能得到了較好的提升。

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

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

更多的外部數據接入：用戶信息、位置信息、UBT信息；

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

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

編程語言的更新：攜程推動公司內.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年前開始，可以分以下幾個主要優化：

規則分散式並行執行 ：

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

腳本執行引擎切換 Drools 到 Java

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

開發Java的模型執行引擎

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

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

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

彩蛋

重磅 Chat

《高效學習，快速變現：不走彎路的五大學習策略》

分享人：

Seaborn Lee，一名會在 B 站直播寫代碼，會玩雜耍球、彈 Ukulele、極限健身、跑步、寫段子、畫畫、翻譯、寫作、演講、培訓的程序員。喜歡用編程實現自己的想法，在 Android 市場上賺過錢，有多次創業經歷。

擅長學習，習慣養成，時間管理。身體力行地影響他人做出積極的改變！目前就職於 ThoughtWorks，致力於傳播快樂高效的編程理念。業餘創立軟體匠藝社區 CodingStyle.cn，組織超過30場技術活動。

Chat簡介：

說到學習呀，真是頭大喲：

碎片化，沒有較長的連續時間來學習

難專註，捧起書，手機卻在召喚：來呀，快活呀~ 反正有，大把時光~

做不到，看了很多書，生活中卻做不到

然並卵，學了方法和工具，找不到使用場景

效率低，學習速度跟不上知識產生的速度

記不牢，學習速度趕不上遺忘速度

在這個知識泛濫、跨界競爭的年代，學習能力才是核心競爭力。你想想，過去一周，有沒有哪一件工作是不需要學習就能完成的？

儘管如此重要，大部分人卻沒研究過學習這件事，以為上下班路上打開「得到」聽本書，就是碎片時間終身學習者了。

想要免費參與本場 Chat ？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 GitChat技術雜談 的精彩文章: