注：創(chuàng)業(yè)公司不僅要滿足用戶的需求，更要讓自己的產(chǎn)品安全可靠，亡羊補牢不如未雨綢繆，這正是風控系統(tǒng)需要做的。本文為豈安科技帶來的分享，作者為bigsec安全業(yè)務(wù)研發(fā)負責人王笑天，主導(dǎo)公司安全業(yè)務(wù)和Redq系統(tǒng)的研發(fā)工作。擅長python編程，分布式系統(tǒng)的研發(fā)和運維。以下為文章原文：
在本文開始之前先貼一份2015年11月的統(tǒng)計數(shù)據(jù)：
11月,實物電商交易量達到人民幣1.0萬億(人民幣,下同)，同比增長38.3%。
服務(wù)業(yè)電商交易量達到630億，同比增長41.3%。
11月總電商交易量達到1.07萬億，同比增長38.5%。
數(shù)據(jù)共同指向一點，越來越多的交易行為正從線下轉(zhuǎn)到線上，由傳統(tǒng)到互聯(lián)網(wǎng)化。而當互聯(lián)網(wǎng)給我們的生活帶來便利和高效的同時，又帶來了什么呢？那就是業(yè)務(wù)風控的壓力，并不是所有的交易都是安全的，并不是所有的用戶都是可靠的。如何在極短的時間內(nèi)在成千上萬筆交易以及成千上萬個用戶中迅速定位風險、降低損失，我們都知道，亡羊補牢不如未雨綢繆，這正是風控系統(tǒng)需要做的。
說到風控系統(tǒng)，筆者先拋出幾個問題：
1.如何將更新數(shù)據(jù)在10s內(nèi)推送給全國用戶？
2.如何保證客戶的數(shù)據(jù)是絕對安全的？
3.如何在10m內(nèi)完成新數(shù)據(jù)中心的搭建？
4.如何做到全國任何用戶訪問都在10ms？
問題中提到了三個10，即10s，10m，10ms，本文以Red.Q云風控系統(tǒng)為例，來談?wù)?個10的問題是如何解決的。本文將按順序討論為什么風控系統(tǒng)需要實時性、安全性、便捷性和可靠性，這其中可靠性是最重要的，所有的技術(shù)細節(jié)比如跨數(shù)據(jù)中心通信，服務(wù)SLA，發(fā)布，運維監(jiān)控，數(shù)據(jù)質(zhì)檢，分布式等會在文章后面的可靠性章節(jié)詳細闡述。
實時性：10S
對風控來說，以前在說風險控制，現(xiàn)在都說風險預(yù)警，其實就是時間維度的控制，只有提前發(fā)現(xiàn)了風險才能有效控制風險。筆者這里舉個簡單的例子，http 代理是一個可愛又可恨的東西，它可以幫助我們隱藏真實的身份，也可以幫助我們?nèi)プ鰤氖虏槐话l(fā)現(xiàn)，對于大部分的互聯(lián)網(wǎng)企業(yè)來說，只要談到用戶訪問來源是代理的時候都會有些緊張，因為http代理是目前成本低并且效果好的撕開企業(yè)各種風險控制系統(tǒng)和IP防火墻系統(tǒng)的一把利劍，學習成本低到只要會點互聯(lián)網(wǎng)知識會使用搜索引擎就可以用，所以大部分互聯(lián)網(wǎng)企業(yè)在如何防范代理ip訪問上面都做了很多工作。但是當你好不容易把國內(nèi)的代理IP都收集的差不多的時候，你會發(fā)現(xiàn)好多代理已經(jīng)失效了，新的代理層出不窮，做這個維度的風控完全是跟時間賽跑。
那么如果Red.Q云風控系統(tǒng)有這樣的一個功能：實時提供國內(nèi)IP代理狀態(tài)查詢功能，你會不會覺得風控工作瞬間變得簡單了很多呢（實時性的相關(guān)技術(shù)細節(jié)請參看可靠性章節(jié)）。在大流量面前，早發(fā)現(xiàn)可疑行為一分鐘，對于企業(yè)都可能避免更多的損失，這只是實時性在風控領(lǐng)域的一個縮影，事實上有更多的數(shù)據(jù)需要很強的實時性和時效性。例如我們的風控數(shù)據(jù)的更新量每天都很大，每天探索數(shù)以萬計的數(shù)據(jù)，包括IP，手機號碼，情報數(shù)據(jù)，我們一直在努力壓縮數(shù)據(jù)從探索到質(zhì)檢到入庫到推送各個數(shù)據(jù)節(jié)點的過程時長，一直希望給用戶帶來更好的實時性體驗。就之前提到的代理ip數(shù)據(jù)而言，我們最快的從發(fā)現(xiàn)到推送的時間是10秒鐘。
安全性
為什么我會提到安全性？我相信大部分互聯(lián)網(wǎng)公司的核心都是其業(yè)務(wù)數(shù)據(jù)，公司的安全性就是這些數(shù)據(jù)的安全性。公司如果自己做風控系統(tǒng)那么無所謂，數(shù)據(jù)都是在公司內(nèi)部流轉(zhuǎn)，但是如果公司沒有風控團隊，技術(shù)也還不夠成熟又想做風控就只能借助于第三方安全公司。之前接觸到一些云風控系統(tǒng)都是需要將客戶的訂單、登錄等敏感的業(yè)務(wù)數(shù)據(jù)上傳到云端進行分析產(chǎn)生決策，這些核心數(shù)據(jù)如何傳輸，如何存儲都脫離了客戶的控制。就算安全公司把自己如何如何安全說的天花亂墜可能也只是在安慰客戶和自己，沒有一家安全公司敢站出來說在這個黑客橫行，0DAY亂跑的年代，我的客戶數(shù)據(jù)是最安全的。對于一個好的云風控系統(tǒng)來說就不存在或者很少存在這個問題。用戶提供的數(shù)據(jù)非常的有限，我們不要求用戶上傳敏感數(shù)據(jù)，有限就代表可控，可控就代表安全，這就是豈安一直在倡導(dǎo)并始終堅持的安全性，除了自身數(shù)據(jù)的加密和防護，在同態(tài)加密（百度百科：同態(tài)加密）的技術(shù)領(lǐng)域上我們也一直保持高度關(guān)注，筆者認為在不遠的將來，同態(tài)加密的應(yīng)用一定會是安全領(lǐng)域的一個顛覆。
便捷性：10m
首先，對于客戶而言，風控系統(tǒng)需要的是接入簡單，無需提供復(fù)雜數(shù)據(jù)格式，對照文檔即可完成接入。
其次，對于公司自身而言，在現(xiàn)有的技術(shù)棧（docker，數(shù)據(jù)分發(fā)系統(tǒng)，發(fā)布系統(tǒng)，自動化安裝，服務(wù)可伸縮）的基礎(chǔ)上，我們新建或者重建（容災(zāi)）數(shù)據(jù)中心的成本異常的小，從發(fā)布到上線大概花費時間是10分鐘，我們可以真正做到客戶在哪里，數(shù)據(jù)節(jié)點就建到哪里，具體技術(shù)細節(jié)參見下文可靠性的發(fā)布章節(jié)。
可靠性：10ms
為什么可靠性很重要？有人會說你們又不是銀行系統(tǒng)，也不是訂單系統(tǒng)，只是一個工具而已，為什么要那么高的可靠性？筆者想說的是當一個公司在重視安全風控的情況下，將這個所謂的工具嵌入到注冊登錄流程以及交易流程中，成為關(guān)鍵一環(huán)時，可靠性的重要性就體現(xiàn)出來了。如果因為你的產(chǎn)品延遲過大或者拒絕服務(wù)影響客戶的交易流程，導(dǎo)致客戶受到財產(chǎn)損失時，也許老板已經(jīng)把你fire了。
說到可靠性就不得不提SLA（service-level agreement）業(yè)界都在用得一個考量標準，如果做到SLA 四個九五個九，如何做到延遲20MS，假設(shè)我們的數(shù)據(jù)中心在上海，那么做到上海地區(qū)的20ms應(yīng)該沒有什么難度，那么北京的用戶可以做到20ms么？深圳的用戶可以做到么？有人可能會問，使用CDN就可以了，當前CDN無論技術(shù)的成熟度和穩(wěn)定性都做的非常的棒，筆者也承認CDN技術(shù)確實可以解決資源遠端用戶訪問延遲的問題，不過只能解決靜態(tài)資源調(diào)用，對于動態(tài)資源，只能通過優(yōu)化骨干網(wǎng)線路來實現(xiàn)，但是局限性在于延遲的優(yōu)化提升極限，它可以把你的網(wǎng)站訪問延遲從2秒縮短到500ms，也有可能把你的查詢接口從500ms縮短到50ms，但是當我們到了要把延遲從30ms降低到20ms的度時，CDN技術(shù)也許就無法勝任了。
舉個例子，還是假設(shè)我們的數(shù)據(jù)中心在上海，深圳的用戶要查詢我們的數(shù)據(jù)，深圳到上海的直線距離是1200公里，通訊線路算1500公里，用戶發(fā)出請求到數(shù)據(jù)返回給用戶大概是3000公里，這里先不考慮數(shù)據(jù)包轉(zhuǎn)發(fā)等損耗，僅僅是光速傳輸需要3000公里/300000公里=10ms，可以想象當我們的風控系統(tǒng)在追求極致的低延遲的時候，CDN技術(shù)已經(jīng)被PASS了，我們需要的是多數(shù)據(jù)中心（多機房）！
Red.Q云風控系統(tǒng)目前有十個數(shù)據(jù)中心節(jié)點在部署中，主要分布在北上杭廣深，同城訪問可以覆蓋70%的互聯(lián)網(wǎng)公司，SaaS服務(wù)接口查詢延遲在全國范圍內(nèi)基本控制在20MS以內(nèi)，如果用戶調(diào)用服務(wù)器跟我們處在同一機房，速度可以達到近10ms，最大程度提高接入速度和可靠性，這就是跨數(shù)據(jù)中心方案的好處。
下圖則是用戶在訪問Red.Q業(yè)務(wù)時的抽象數(shù)據(jù)流向圖
1 我們通過使用運營商提供的DNS定位功能將用戶定位到離其最近的一個數(shù)據(jù)中心節(jié)點
2 查詢請求首先進入該節(jié)點LB并轉(zhuǎn)發(fā)到后端服務(wù)器
3 Service處理本地數(shù)據(jù)并返回
4 Service加載遠端機房數(shù)據(jù)并返回
這里提到的本地數(shù)據(jù)就是我們的核心業(yè)務(wù)數(shù)據(jù)，我們會在很低的可控延遲內(nèi)做到所有數(shù)據(jù)中心的數(shù)據(jù)一致性同步。做到這一點就相當于把數(shù)據(jù)搬到了用戶的家門口，用戶99%的請求都是在請求“家門口的數(shù)據(jù)”，延遲問題得到解決，還有1%是第四點所說的遠端機房數(shù)據(jù)請求，那么我們是如何做到數(shù)據(jù)傳輸和控制的呢？
下圖是跨機房的架構(gòu)介紹：
我們采用微服務(wù)架構(gòu)(MSA)對每個服務(wù)進行解耦，橘紅色就是Red.Q的Services，并且自己寫了一套通訊框架【Babel】用于service之間的通訊。
下圖描述了Babel的Workflow：
Babel有如下幾個功能特性:
1 多語言構(gòu)建支持（目前支持Python和Java）：最大程度發(fā)揮了不同技術(shù)棧程序員的優(yōu)勢。
2 支持多種消息分發(fā)語義：shuffle（隨機分發(fā)），sharding（數(shù)據(jù)切片），topic（消息copy）等
3 數(shù)據(jù)傳輸方式支持Rpc請求，數(shù)據(jù)推送以及輪詢等方式，滿足了Bigsec目前的幾乎所有數(shù)據(jù)傳輸要求。
4 支持多種底層通訊協(xié)議（Rabbitmq，redis，0mq）：滿足分布式，單機，高速等需求。
5 通過使用Rabbitmq的federation特性，在不同的機房搭建Rabbitmq節(jié)點來支持跨數(shù)據(jù)中心功能。
Red.Q云風控系統(tǒng)后端需要有很多的不同的服務(wù)組件支撐，每一個服務(wù)組件都搭建成多實例集群（這里的集群概念是指多個相同service進程）做負載和容災(zāi)（一個進程Down了不影響該服務(wù)），如圖1的serviceA、B、C等，并用Babel框架連起來，再加上簡單的配置就實現(xiàn)了跨數(shù)據(jù)中心特性。
下面一張圖描述了我們的跨機房特性上線前后用戶延遲粗略對比，效果比較明顯。
優(yōu)化之前
優(yōu)化之后
關(guān)于Babel的技術(shù)細節(jié)將會在后續(xù)的文章中詳細介紹，本文僅作為通訊框架使用，Babel的跨數(shù)據(jù)中心通訊實現(xiàn)使上層業(yè)務(wù)基本不再關(guān)注跨數(shù)據(jù)中心的實現(xiàn)細節(jié)，但需要注意幾點：
1 跨數(shù)據(jù)中心的數(shù)據(jù)大小要控制
2 使用跨數(shù)據(jù)中心特性要考慮延遲，準實時級別
3 業(yè)務(wù)上層實現(xiàn)緩存機制，如上圖ServiceA的Cache（黃色）
4 做好熔斷措施
當架構(gòu)復(fù)雜了，隨之而來的就是運維的難度，如何快速將代碼部署到所有機房并上線？如何在第一時間知道哪個機房的哪個服務(wù)器的哪個service出了問題？這兩個問題就引出了發(fā)布流程和監(jiān)控系統(tǒng)。
發(fā)布流程
我相信很多大型的互聯(lián)網(wǎng)公司已經(jīng)可以在幾千臺甚至幾萬臺服務(wù)器規(guī)模下把發(fā)布做得很棒，而且也完善的發(fā)布流程和自己的發(fā)布系統(tǒng)。不過這里筆者還是要說兩句，這對于剛剛接觸互聯(lián)網(wǎng)或者初創(chuàng)公司來說，多多少少會有一些啟發(fā)，還是畫一張圖來說明下我們公司的發(fā)布流程是什么樣子的。
從左往右說：
opservers是運維服務(wù)器集群，所有發(fā)布，運維，監(jiān)控等服務(wù)都會放在這里，為了降低維護成本，僅存在于主數(shù)據(jù)中心
Ansible (http://www.ansible.com) 是一款運維自動化工具，用于批量執(zhí)行任務(wù)，功能強大又不失簡單，對于任何運維工作，只需要定義兩點：你要做什么（playbook）、對誰去做（HostsInventory），將兩者進行組合。
橙色部分是Docker容器技術(shù)的使用，微服務(wù)概念哲學給我們帶來使用docker的可能，完美的解決了應(yīng)用的環(huán)境依賴問題，對于環(huán)境基線的更新也能像應(yīng)用基線一樣通過簡單的commit、push、pull來實現(xiàn)，為了降低docker容器的運維成本，我們對docker的commit進行了層抽象：
系統(tǒng)層監(jiān)控通過在服務(wù)器初始化的時候安裝監(jiān)控agent ，監(jiān)控數(shù)據(jù)由agent發(fā)送
框架層監(jiān)控集成到了Babel通訊框架中，Babel會將Service之間的msg通訊統(tǒng)計、產(chǎn)生錯誤、心跳數(shù)據(jù)定期上傳到服務(wù)器，通過報表可以看到所有服務(wù)器上的每個service通訊和健康情況。
業(yè)務(wù)層監(jiān)控：硬性規(guī)定要在業(yè)務(wù)代碼的關(guān)鍵位置打點。
簡單描述下Red.Q云風控系統(tǒng)的發(fā)布步驟：
1 代碼開發(fā)完成提交GIT。
2 修改DockerFile Build新版本。
3 測試：拉取測試配置，推送新版本的Docker Commit ，測試通過。
4 生產(chǎn)：拉取生產(chǎn)配置，推送新版本的Docker Commit。
5 生產(chǎn)：集群拉入拉出，服務(wù)重新啟動。
6 監(jiān)控發(fā)布期間的Metric報警。
7 上線成功。
目前，我們通過編寫Ansible Playbook 完成了以上發(fā)布流程的80%，大大節(jié)約了人力成本，提高發(fā)布質(zhì)量。
這里提到一個問題，由于機房服務(wù)器都存在于內(nèi)網(wǎng)，所以為了解決跨數(shù)據(jù)中心運維服務(wù)的訪問（不包括Babel業(yè)務(wù)通訊），也就是說讓子數(shù)據(jù)中心能夠訪問運維服務(wù)器集群，本來子中心到主中心打通就可以，但是由于我們的jumpserver在主中心，所以如果要使用該跳板機管理子中心的服務(wù)器，就必須將主中心到子中心打通，所以我們采用的方法就是主機房建立vpn服務(wù)器，子機房撥號連接進來，同時在兩端做路由和nat，并將各自機房的路由器添加互通路由就實現(xiàn)了機房互通。當然這里面還會涉及到很多問題，比如版本控制，服務(wù)器初始化等，本文暫不涉及。
監(jiān)控系統(tǒng)
Influxdb是一個開源分布式時序、事件和指標數(shù)據(jù)庫，寫入速度快，非常適合用于監(jiān)控
Grafana跟influxdb搭配使用，將Metric web可視化，查看指標的重要工具。
Metricalert 基于influxdb開發(fā)，設(shè)置報警規(guī)則進行報警。
metricproxy 存在意義在于跨數(shù)據(jù)中心特性，為了保證proxyclient的穩(wěn)定，每個數(shù)據(jù)中心的metric報警都會發(fā)到本地proxy并統(tǒng)一由proxy壓縮發(fā)送到主中心服務(wù)器。
監(jiān)控保障，依然采用分層體系：
系統(tǒng)層監(jiān)控通過在服務(wù)器初始化的時候安裝監(jiān)控agent ，監(jiān)控數(shù)據(jù)由agent發(fā)送
框架層監(jiān)控集成到了Babel通訊框架中，Babel會將Service之間的msg通訊統(tǒng)計、產(chǎn)生錯誤、心跳數(shù)據(jù)定期上傳到服務(wù)器，通過報表可以看到所有服務(wù)器上的每個service通訊和健康情況。
業(yè)務(wù)層監(jiān)控：硬性規(guī)定要在業(yè)務(wù)代碼的關(guān)鍵位置打點。
監(jiān)控系統(tǒng)的技術(shù)細節(jié)請參考我們的另一篇文章《創(chuàng)業(yè)型公司如何做好監(jiān)控報警》。
經(jīng)統(tǒng)計，目前我們的監(jiān)控布點大約有200+，可視監(jiān)控報表大約80個，報警規(guī)則大約40條，從業(yè)務(wù)到系統(tǒng)，從通訊到進程，基本覆蓋了98%的關(guān)鍵點，不過有句話說得好，出來混總歸要還的，故障還是會發(fā)生，不過我們的Red.Q云風控系統(tǒng)在抵御故障能力上具備天然基因和優(yōu)勢，以下CaseList可以說明這一點：
1 Service進程被殺：其他Service繼續(xù)提供服務(wù)（繼承Babel特性）
2 服務(wù)器宕機：其他服務(wù)器繼續(xù)提供服務(wù)（繼承LB特性）
3 機房光纖被鏟：其他機房繼續(xù)提供服務(wù)（繼承DNS節(jié)點切換特性）
數(shù)據(jù)可靠性
那么最后一個影響可靠性的因素就是數(shù)據(jù)了，對于風控的數(shù)據(jù)，人工識別也好，機器判斷也罷，由于數(shù)據(jù)的特殊性，無法做到100%的精確，不過在有限的領(lǐng)域我們可以做的還有很多，下圖是一張關(guān)于數(shù)據(jù)質(zhì)檢以及發(fā)布的流程。
數(shù)據(jù)質(zhì)檢的定義在于數(shù)據(jù)質(zhì)量的要求，Red.Q云風控系統(tǒng)后面有一個非常龐大的情報團隊無時無刻的不在收集互聯(lián)網(wǎng)上所有我們關(guān)心的數(shù)據(jù)，來源多，維度廣，數(shù)量大，這類數(shù)據(jù)如何做到有效的關(guān)聯(lián)和驗證對于我們來說是一個持久的技術(shù)挑戰(zhàn)。對于提高數(shù)據(jù)質(zhì)量來說，首先我們對所有的來源定義了可信指數(shù)，根據(jù)數(shù)據(jù)的類型、維度和來源定義了很多驗證規(guī)則，所有的來源數(shù)據(jù)根據(jù)驗證規(guī)則進行交叉驗證，數(shù)據(jù)會被多次進行驗證，數(shù)據(jù)每一次被驗證可信指數(shù)都會增長，比如我們在鑒定某一個手機號碼是否是非正常用戶時，會通過硬件、語音識別等方式鑒別，對于IP，我們有分布式IP掃描系統(tǒng)和爬蟲框架進行驗證。
當質(zhì)檢倉庫的某批數(shù)據(jù)達到了可信指數(shù)輸出的設(shè)定值，該批次數(shù)據(jù)就會被打上版本Tag推送到生產(chǎn)倉庫并對每一條數(shù)據(jù)生成Binlog，這里Tag的意義在于將每批次更新的數(shù)據(jù)區(qū)分開來，在生產(chǎn)數(shù)據(jù)出問題的時候能夠做到迅速定位數(shù)據(jù)批次并回滾，最后通過Babel推送到全國各個節(jié)點。圖中綠色部分是新數(shù)據(jù)中心搭建時候我們針對數(shù)據(jù)一致性所做的一些措施，我們首先會在數(shù)據(jù)主倉庫中Dump一份數(shù)據(jù)并Copy到新數(shù)據(jù)中心，為了彌補在Dump-copy過程中更新數(shù)據(jù)的損失，我們會記錄dump的時間點定位相關(guān)時間段日志數(shù)據(jù)Append到新庫中，最后接入babel并上線。
這么多技術(shù)活歸根結(jié)底一句話——在服務(wù)可靠性上面，我們是認真的。
數(shù)據(jù)
額外提一點就是數(shù)據(jù)這塊，這一點對bigsec來說是業(yè)務(wù)發(fā)展的基石，目前bigsec擁有3.5億風控數(shù)據(jù)體量，Babel消息總線每天傳輸處理3000W+的Msg，數(shù)十個數(shù)據(jù)來源不間斷補充新數(shù)據(jù)，多種數(shù)據(jù)驗證方式對數(shù)據(jù)質(zhì)量進行把控，平均每周可以保持數(shù)據(jù)復(fù)合增長10%，雖然數(shù)據(jù)量越來越大，但謹小慎微依然是Bigsec技術(shù)人對數(shù)據(jù)的態(tài)度。就拿一個很簡單的一個歸屬地數(shù)據(jù)來說吧，為了能做到IP以及手機號碼更高的準確度，我們并沒有直接使用網(wǎng)上的開源庫，而是花了好長時間爬取并整合了包括阿里，ip138，純真等數(shù)據(jù)，在對數(shù)據(jù)的校驗過程中，發(fā)現(xiàn)大量的歸屬地錯誤條目，只能通過人工去校正，最后開發(fā)出了bigsec版的歸屬地數(shù)據(jù)庫，有人說這是重復(fù)造輪子，但是筆者認為只有對自己認真，別人才會對你認真。
總結(jié)
篇幅有限，很多東西只能一帶而過，本文大概圍繞了可靠性、實時性、安全性、便捷性、數(shù)據(jù)這幾個關(guān)鍵詞展開，用以說明這幾點對于風控系統(tǒng)來說的重要性，尤其重申了容易被大家忽視的可靠性，但是在風控領(lǐng)域里面其實還有太多的東西要談，有太多的東西要做。
筆者一直認為bigsec的技術(shù)發(fā)展之迅速是建立在巨人的肩膀上的，不是一個巨人，是無數(shù)巨人的肩膀，在這里向這些巨人致以最崇高的敬意，并拋磚引玉之。
京公網(wǎng)安備 11010502049343號