目前攜程利用自主研發的風控系統有效識別、防范這些風險。攜程風控系統從零起步，經過五年的不斷探索與創新，已經可以有效覆蓋事前、事中、事后各個環節。也從原來基于“簡單規則 +DB”，發展到目前能夠支撐 10X 交易增長的智能化風控系統，基于規則引擎、實時模型計算、流式處理、M/R、大數據、數據挖掘、機器學習等的風控系統，擁有實時、準實時的風險決策、數據分析能力。
一、Aegis 系統體系
主要分三大模塊：風控引擎、數據服務、數據運算、輔助系統。
風控引擎：主要處理風控請求，有預處理、規則引擎和模型執行服務，風控引擎所需要的數據是由數據服務模塊提供的。數據服務：主要有實時流量統計、風險畫像、行為設備數據、外部數據訪問代理，RiskGraph。數據訪問層所提供的數據都是由數據計算層提供數據運算：主要包括風險畫像運算、RiskSession、設備指紋、以及實時流量、非實時運算。
數據運算所需的數據來源主要是：風控 Event 數據（訂單數據、支付數據），各個系統采集來的 UBT、設備指紋、日志數據等等。
除了這些，風控平臺還有非常完善的監控預警系統，人工審核平臺以及 報表系統。
二、Aegis 系統架構
三、規則引擎
規則引擎包含 3 大功能，首先是適配層。
由于攜程的業務種類非常多，而且每種業務都有其特性，在進入風控系統（Aegis）后，為了便于整個風控系統對數據進行處理，風控前端有一個適配器模塊，把各個業務的數據都按照風控內部標準化配置進行轉換，以適合風控系統使用。
在完成數據適配后。風控系統要進行數據的合并。
舉個例子，當有一筆支付風控校驗，支付 BU 只拋過來支付信息（支付金額、支付方式、訂單號等）。但是不包含訂單信息，這個時候就必須根據支付信息快速的查找到訂單信息，并把這兩個數據進行合并，以便規則、模型使用。大家知道，用戶從生成訂單到發起支付，其時間間隔從秒到天都有可能，當間隔時間短的時候，就會發生要合并的數據還沒有處理完，所以訂單數據從處理到落地要非常快。第二部就是要快速查找到訂單數據，我們為訂單信息根據生成 RiskGraph，可以快速精確定位到所需要的訂單明細數據。
預處理在完成數據合并后，就開始準備規則、模型所需要的變量、tag 數據，在準備數據時，預處理模塊會依賴后面我們要講解的數據服務層。當然，為了提高性能，我們為變量、tag 的數據合理安排，優先獲取關鍵規則、模型所需要的變量、tag 的數據。
大家知道，欺詐分子的特點就是一波一波的，風控系統需要能夠及時響應，當發現欺詐行為后，能及時上規則防止后續類似的欺詐行為。所以，制定規則需要快速、準確，既然這樣，那么就需要我們的規則能夠快速上線，而且規則人員自己就可以制定規則并上線。還有就是規則與執行規則的引擎比較做到有效隔離，不能因為規則的不合理，影響到整個引擎。那么規則引擎就必須符合這些條件。
我們最后選擇了開源 Drools，第一它是開源，第二它可以使用 JAVA 語言，入門方便，第三功能夠用。
這樣攜程風控引擎 ，實現了 規則上線的高效攜程風控實時引擎 通過使用 規則引擎 Drools，使其具有非常高的靈活性、可配置性，并且由于是 java 語法的，規則人員自己就可以制定規則并迅速上線。
由于每個風控 Event 請求，都需要執行數百個規則，以及模型，這時，風控引擎引入了規則執行路徑優化方法。建立起并行 + 串行，依賴關系 + 非依賴關系的規則執行優化方法，然后再引入短路機制，使上千個規則的運行時間控制在 100ms。
規則的靈活性非常強，制定、上線非常快，但是單個規則的覆蓋率比較低，如果要增加覆蓋率就需要非常多的規則來進行覆蓋，這個時候規則的維護成本就會很高，那么這個時候就需要使用模型了，模型的特點就是覆蓋率覆蓋率可以做到比較高，其模型邏輯可以非常復雜，但是其需要對其進行線下訓練，所以攜程風控系統利用了規則、模型的各自特點進行互補。
在目前的風控系統中主要使用了：Logistic Regression、Random Forest。兩個算法使用下來，目前情況為：LR 訓練變量區分度足夠好的情況下，加以特征工程效果比較好。RF 當變量線性區分能力較弱的時候，效率比較高。所以使用 RF 的比例比較多。
四、數據服務層
數據服務層，主要功能就是提供數據服務，我們知道在風控引擎預處理需要獲取到非常多的變量和 tag，這些變量和 tag 的數據都是由數據訪問層來提供的。該服務層的最重要的目的就是響應快。所以在數據服務層主要使用 redis 作為數據緩存區，重要、高頻數據直接使用 Redis 作為持久層來使用。
數據服務層的核心思想就是充分利用內存（本地、Redis）1、本地內存（大量固定數據，如 ip 所在地、城市信息等）2、充分利用 Redis 高性能緩存
由于實時數據流量服務、風險畫像數據服務的數據是直接存儲在 Redis 中，其性能能夠滿足規則引擎的要求，我們這里重點介紹一下數據訪問代理服務。
數據訪問代理服務，其最重要的思想就是該數據被規則調用前先調用第三方的服務，把數據保存到 Redis 中，這樣當規則請求來請求的時候，就能夠直接從 Redis 中讀取，既然做到了預加載，那么其數據的新鮮度及命中率就非常重要。我們以用戶相關維度的數據為例，風控系統通過對用戶日志的分析，可以偵測到哪些用戶有登陸、瀏覽、預定的動作，這樣就可以預先把這些用戶相關的外部服務數據加載到 Redis 中，當規則、模型讀取用戶維度的外部數據時，先直接在 redis 中讀取，如果不存在然后再訪問外部服務。
在某些場景下，我們還結合引入 DB 來做持久化，當用戶某些信息發生變化的時候，公共服務會發送一個 Message 到 Hermes，我們就訂閱該信息，當知道該用戶的某些信息發生修改，我們就主動的去訪問外部服務獲取數據放入 Redis 中，由于風控系統能夠知道這些數據發生變化的 Message，所以這些數據被持久化到 DB 中也是 ok 的，當然，這些數據也有一個 TTL 參數來保證其新鮮度。在這種場景下，系統在 Redis 沒有命中的情況下，先到 DB 中查找，兩個地方都不存在滿足條件的數據時，才會訪問外部服務，這個時候，其性能、存儲空間就可以得到優化。
五、Chloro 系統
Chloro 系統是數據分析服務也是整個風控系統的核心，數據服務層所使用到的數據，都是由 Chloro 系統計算后提供的。
主要分析維度主要包括：用戶風險畫像，用戶社交關系網絡，交易風險行為特性模型，供應商風險模型。
可以看到數據的來源主要有 hermes、hadoop、以及前端拋過來的各種風控 Event 數據。Listener 是用來接收各類數據，然后數據就會進入 CountServer 和 Real-Time Process 系統，其中和 RiskSession 的數據就先進入 Sessionizer ，該模塊可以快速進行歸約 Session 處理，根據不同的 key 歸約成一個 session，然后再提交給 實時處理系統進行處理。當 Real Time Process 和 CountServer 對數據處理好后，這個時候分成了兩部分數據，一部分是處理的結果，還有一份是原數據，都會提交給 Data Dispatcher，由它進行 Chloro 系統內部的數據路由，結果會直接進入到 RiskProfile 提供給引擎和模型使用。而原始數據會寫入到 Hadoop 集群。
Batch Process 就利用 Hadoop 集群的大數據處理能力，對離線數據進行處理，當 Batch Process 處理好后，也會把處理結果發送給 Data Dispatcher，由它進行數據路由。
Batch Process 還可以做跨 Rsession 之間的數據分析。
RiskSession 的定義：量化、刻畫 用戶的行為，任何人通過任何設備訪問攜程的第一個 event 開始，我們認為 Rsession start 了，到他離開的最后一個 event 后 30 分鐘之內沒有任何痕跡留下，我們認為 Rsession end。
風控系統通過比較用戶信息：Uid, 手機號, 郵箱，設備信息：
Fp（Fingerprint）, clientId, vid, v, deviceId 來判斷其是否是同一個用戶，通過其行為信息：瀏覽軌跡, 歷史軌跡來判斷其行為相似度。
比如：用戶在 PC 端下單、然后在手機 App 里完成支付，這個對于 Chloro 是一個會話，這個會話我們稱之為風控 Session，通過 Risksession 的定義，風控系統使用戶的行為可以量化，也可以刻畫。這樣 Risksession 實際上可以作為用戶行為的一個 Container。使用 RiskSession 就可以做到跨平臺，更加有利于分析用戶特征。
Risk Graph 是根據攜程風控系統的特點開發出來的，Risk Graph 是一個基于 HBase 進行為存儲介質的系統，比如，以用戶為節點其值就是 HBase 用戶表的 key，其每個列就是特性，然后根據用戶的某個特性再創建一個 hbase 表，這樣就創建了一個基于 HBase 的類 Graph 的架構。
所以該系統的一個核心思想是先創建各個維度的數據索引，然后根據索引值再進行內容的查找。目前風控系統已經創建了十幾個維度的快速索引。
六、Aegis 其它子系統
Aegis 還有配置系統，用戶可以在上面進行各種配置，如規則、規則運行路徑，標準化、tag、變量定義、已經數據清洗業務羅輯等等，當然監控系統也是非常重要的，風控研發秉承著監控無處不在的設計理念，使其能夠在第一時間發現系統的任何細小變化。
