案例與解決方案匯總頁：
阿里云實時計算產(chǎn)品案例&解決方案匯總
對一個互聯(lián)網(wǎng)產(chǎn)品來說，典型的風(fēng)控場景包括：注冊風(fēng)控、登陸風(fēng)控、交易風(fēng)控、活動風(fēng)控等，而風(fēng)控的最佳效果是防患于未然，所以事前事中和事后三種實現(xiàn)方案中，又以事前預(yù)警和事中控制最好。
這要求風(fēng)控系統(tǒng)一定要有實時性。
1.總體架構(gòu)
風(fēng)控是業(yè)務(wù)場景的產(chǎn)物，風(fēng)控系統(tǒng)直接服務(wù)于業(yè)務(wù)系統(tǒng)，與之相關(guān)的還有懲罰系統(tǒng)和分析系統(tǒng)，各系統(tǒng)關(guān)系與角色如下：
業(yè)務(wù)系統(tǒng)，通常是APP+后臺 或者 web，是互聯(lián)網(wǎng)業(yè)務(wù)的載體，風(fēng)險從業(yè)務(wù)系統(tǒng)觸發(fā)；
風(fēng)控系統(tǒng)，為業(yè)務(wù)系統(tǒng)提供支持，根據(jù)業(yè)務(wù)系統(tǒng)傳來的數(shù)據(jù)或埋點信息來判斷當(dāng)前用戶或事件有無風(fēng)險；
懲罰系統(tǒng)，業(yè)務(wù)系統(tǒng)根據(jù)風(fēng)控系統(tǒng)的結(jié)果來調(diào)用，對有風(fēng)險的用戶或事件進行控制或懲罰，比如增加驗證碼、限制登陸、禁止下單等等；
分析系統(tǒng)，該系統(tǒng)用以支持風(fēng)控系統(tǒng)，根據(jù)數(shù)據(jù)來衡量風(fēng)控系統(tǒng)的表現(xiàn)，比如某策略攔截率突然降低，那可能意味著該策略已經(jīng)失效，又比如活動商品被強光的時間突然變短，這表面總體活動策略可能有問題等等，該系統(tǒng)也應(yīng)支持運營/分析人員發(fā)現(xiàn)新策略；
其中
風(fēng)控系統(tǒng)和
分析系統(tǒng)是本文討論的重點，而為了方便討論，我們假設(shè)業(yè)務(wù)場景如下：
電商業(yè)務(wù)；
風(fēng)控范圍包括：
注冊，虛假注冊；
登陸，盜號登陸；
交易，盜刷客戶余額；
活動，優(yōu)惠活動薅羊毛；
2.風(fēng)控系統(tǒng)
風(fēng)控系統(tǒng)有
規(guī)則和
模型兩種技術(shù)路線，規(guī)則的優(yōu)點是簡單直觀、可解釋性強、靈活，所以長期活躍在風(fēng)控系統(tǒng)之中，但缺點是容易被攻破，一但被黑產(chǎn)猜到里面就會失效，于是在實際的風(fēng)控系統(tǒng)中，往往再結(jié)合上基于模型的風(fēng)控環(huán)節(jié)來增加健壯性。但限于篇幅，本文中我們只重點討論一種基于規(guī)則的風(fēng)控系統(tǒng)架構(gòu)，當(dāng)然如果有模型風(fēng)控的訴求，該架構(gòu)也完全支持。
規(guī)則就是針對事物的條件判斷，我們針對注冊、登陸、交易、活動分別假設(shè)幾條規(guī)則，比如：
規(guī)則可以組合成規(guī)則組，為了簡單起見，我們這里只討論規(guī)則。
事實，即被判斷的主體和屬性，如上面規(guī)則的賬號及登陸次數(shù)、IP和注冊次數(shù)等；
條件，判斷的邏輯，如某事實的某屬性大于某個指標(biāo)；
指標(biāo)閾值，判斷的依據(jù)，比如登陸次數(shù)的臨界閾值，注冊賬號數(shù)的臨界閾值等；
規(guī)則可由運營專家憑經(jīng)驗填寫，也可由數(shù)據(jù)分析師根據(jù)歷史數(shù)據(jù)發(fā)掘，但因為規(guī)則在與黑產(chǎn)的攻防之中會被猜中導(dǎo)致失效，所以無一例外都需要動態(tài)調(diào)整。
基于上邊的討論，我們設(shè)計一個風(fēng)控系統(tǒng)方案如下：
該系統(tǒng)有三條數(shù)據(jù)流向：
實時風(fēng)控數(shù)據(jù)流，由紅線標(biāo)識，同步調(diào)用，為風(fēng)控調(diào)用的核心鏈路；
準(zhǔn)實時指標(biāo)數(shù)據(jù)流，由藍(lán)線標(biāo)識，異步寫入，為實時風(fēng)控部分準(zhǔn)備指標(biāo)數(shù)據(jù)；
準(zhǔn)實時/離線分析數(shù)據(jù)流，由綠線標(biāo)識，異步寫入，為風(fēng)控系統(tǒng)的表現(xiàn)分析提供數(shù)據(jù)；
本節(jié)先介紹前兩部分，分析系統(tǒng)在下一節(jié)介紹。
2.1 實時風(fēng)控
實時風(fēng)控是整個系統(tǒng)的核心，被業(yè)務(wù)系統(tǒng)同步調(diào)用，完成對應(yīng)的風(fēng)控判斷。
前面提到規(guī)則往往由人編寫并且需要動態(tài)調(diào)整，所以我們會把風(fēng)控判斷部分與規(guī)則管理部分拆開。規(guī)則管理后臺為運營服務(wù)，由運營人員去進行相關(guān)操作：
場景管理，決定某個場景是否實施風(fēng)控，比如活動場景，在活動結(jié)束后可以關(guān)閉該場景；
黑白名單，人工/程序找到系統(tǒng)的黑白名單，直接過濾；
規(guī)則管理，管理規(guī)則，包括增刪或修改，比如登陸新增IP地址判斷，比如下單新增頻率校驗等；
閾值管理，管理指標(biāo)的閾值，比如規(guī)則為某IP最近1小時注冊賬號數(shù)不能超過10個，那1和10都屬于閾值；
講完管理后臺，那規(guī)則判斷部分的邏輯也就十分清晰了，分別包括前置過濾、事實數(shù)據(jù)準(zhǔn)備、規(guī)則判斷三個環(huán)節(jié)。
2.1.1 前置過濾
業(yè)務(wù)系統(tǒng)在特定事件（如注冊、登陸、下單、參加活動等）被觸發(fā)后同步調(diào)用風(fēng)控系統(tǒng)，附帶相關(guān)上下文，比如IP地址，事件標(biāo)識等，規(guī)則判斷部分會根據(jù)管理后臺的配置決定是否進行判斷，如果是，接著進行黑白名單過濾，都通過后進入下一個環(huán)節(jié)。
2.1.2 實時數(shù)據(jù)準(zhǔn)備
在進行判斷之前，系統(tǒng)必須要準(zhǔn)備一些事實數(shù)據(jù)，比如：
redis/hbase的數(shù)據(jù)產(chǎn)出我們會在第2.2節(jié)準(zhǔn)實時數(shù)據(jù)流中進行介紹。
2.2.3 規(guī)則判斷
在得到事實數(shù)據(jù)之后，系統(tǒng)會根據(jù)規(guī)則和閾值進行判斷，然后返回結(jié)果，整個過程便結(jié)束了。
整個過程邏輯上是清晰的，我們常說的規(guī)則引擎主要在這部分起作用，一般來說這個過程有兩種實現(xiàn)方式：
這兩種方案都支持規(guī)則的動態(tài)更新。
2.2 準(zhǔn)實時數(shù)據(jù)流
這部分屬于后臺邏輯，為風(fēng)控系統(tǒng)服務(wù)，準(zhǔn)備事實數(shù)據(jù)。
把數(shù)據(jù)準(zhǔn)備與邏輯判斷拆分，是出于系統(tǒng)的性能/可擴展性的角度考慮的。
前邊提到，做規(guī)則判斷需要事實的相關(guān)指標(biāo)，比如最近一小時登陸次數(shù)，最近一小時注冊賬號數(shù)等等，這些指標(biāo)通常有一段時間跨度，是某種狀態(tài)或聚合，很難在實時風(fēng)控過程中根據(jù)原始數(shù)據(jù)進行計算，因為風(fēng)控的規(guī)則引擎往往是無狀態(tài)的，不會記錄前面的結(jié)果。
同時，這部分原始數(shù)據(jù)量很大，因為用戶活動的原始數(shù)據(jù)都要傳過來進行計算，所以這部分往往由一個流式大數(shù)據(jù)系統(tǒng)來完成。在這里我們選擇Flink，F(xiàn)link是當(dāng)今流計算領(lǐng)域無可爭議的No.1，不管是性能還是功能，都能很好的完成這部分工作。
業(yè)務(wù)系統(tǒng)把埋點數(shù)據(jù)發(fā)送到Kafka；
Flink訂閱Kafka，
完成原子粒度的聚合；
注：Flink僅完成原子粒度的聚合是和規(guī)則的動態(tài)變更邏輯相關(guān)的。舉例來說，在注冊場景中，運營同學(xué)會根據(jù)效果一會要判斷某IP最近1小時的注冊賬號數(shù)，一會要判斷最近3小時的注冊賬號數(shù)，一會又要判斷最近5小時的注冊賬號數(shù)……也就是說這個最近N小時的N是動態(tài)調(diào)整的。那Flink在計算時只應(yīng)該計算1小時的賬號數(shù)，在判斷過程中根據(jù)規(guī)則來讀取最近3個1小時還是5個1小時，然后聚合后進行判斷。因為在Flink的運行機制中，作業(yè)提交后會持續(xù)運行，如果調(diào)整邏輯需要停止作業(yè)，修改代碼，然后重啟，相當(dāng)麻煩；同時因為Flink中間狀態(tài)的問題，重啟還面臨著中間狀態(tài)能否復(fù)用的問題。所以假如直接由Flink完成N小時的聚合的話，每次N的變動都需要重復(fù)上面的操作，有時還需要追數(shù)據(jù)，非常繁瑣。
通過把數(shù)據(jù)計算和邏輯判斷拆分開來并引入Flink，我們的風(fēng)控系統(tǒng)可以應(yīng)對極大的用戶規(guī)模。
3.分析系統(tǒng)
前面的東西靜態(tài)來看是一個完整的風(fēng)控系統(tǒng)，但動態(tài)來看就有缺失了，這種缺失不體現(xiàn)在功能性上，而是體現(xiàn)在演進上。即如果從動態(tài)的角度來看一個風(fēng)控系統(tǒng)的話，我們至少還需要兩部分，一是衡量系統(tǒng)的整體效果，一是為系統(tǒng)提供規(guī)則/邏輯升級的依據(jù)。
判斷規(guī)則是否失效，比如攔截率的突然降低；
判斷規(guī)則是否多余，比如某規(guī)則從來沒攔截過任何事件；
判斷規(guī)則是否有漏洞，比如在舉辦某個促銷活動或發(fā)放代金券后，福利被領(lǐng)完了，但沒有達(dá)到預(yù)期效果；
在為系統(tǒng)提供規(guī)則/邏輯升級依據(jù)方面，我們需要：
發(fā)現(xiàn)全局規(guī)則，比如某人在電子產(chǎn)品的花費突然增長了100倍，單獨來看是有問題的，但整體來看，可能很多人都出現(xiàn)了這個現(xiàn)象，原來是蘋果發(fā)新品了……
識別某種行為的組合，單次行為是正常的，但組合是異常的，比如用戶買菜刀是正常的，買車票是正常的，買繩子也是正常的，去加油站加油也是正常的，但短時間內(nèi)同時做這些事情就不是正常的。
群體識別，比如通過圖分析技術(shù)，發(fā)現(xiàn)某個群體，然后給給這個群體的所有賬號都打上群體標(biāo)簽，防止出現(xiàn)那種每個賬號表現(xiàn)都正常，但整個群體卻在集中薅羊毛的情況。
這便是分析系統(tǒng)的角色定位，在他的工作中有部分是確定性的，也有部分是探索性的，為了完成這種工作，該系統(tǒng)需要盡可能多的數(shù)據(jù)支持，如：
業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，業(yè)務(wù)的埋點數(shù)據(jù)，記錄詳細(xì)的用戶、交易或活動數(shù)據(jù)；
風(fēng)控攔截數(shù)據(jù)，風(fēng)控系統(tǒng)的埋點數(shù)據(jù)，比如某個用戶在具有某些特征的狀態(tài)下因為某條規(guī)則而被攔截，這條攔截本身就是一個事件數(shù)據(jù)；
這是一個典型的大數(shù)據(jù)分析場景，架構(gòu)也比較靈活，我僅僅給出一種建議的方式。
相對來說這個系統(tǒng)是最開放的，既有固定的指標(biāo)分析，也可以使用機器學(xué)習(xí)/數(shù)據(jù)分析技術(shù)發(fā)現(xiàn)更多新的規(guī)則或模式，限于篇幅，這里就不詳細(xì)展開了。
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
新聞名稱：基于Flink和規(guī)則引擎的實時風(fēng)控解決方案
新聞來源：
http://weahome.cn/article/gddije.html
重慶分公司
重慶分公司
