摘要：同盾技術(shù)總監(jiān)張新波在第二期移動時代互聯(lián)網(wǎng)金融的架構(gòu)趨勢中闡述了同盾是如何從零開始打造千萬級實時風(fēng)控云服務(wù)，具體介紹了同盾系統(tǒng)平臺構(gòu)建過程中主要需要解決的三大難題，以及解決這些問題的具體時實踐過程。

同盾科技，是由阿里、Paypal 反欺詐專家創(chuàng)建的，國內(nèi)第一家風(fēng)險控制與反欺詐云服務(wù)提供商，其涉及領(lǐng)域包括電商、B2B、互聯(lián)網(wǎng)金融、游戲等。同盾技術(shù)總監(jiān)張新波在 UPYUN Open Talk第二期《移動時代互聯(lián)網(wǎng)金融的架構(gòu)趨勢》中闡述了同盾是如何從零開始打造千萬級實時風(fēng)控云服務(wù)，具體介紹了同盾系統(tǒng)平臺構(gòu)建過程中主要需要解決的三大難題，以及解決這些問題的具體時實踐過程。

同盾的后臺系統(tǒng)是一套非常強大的，規(guī)則靈活配置的管理系統(tǒng)，搭建這個平臺同盾主要面臨了以下幾個難點：
1、性能
同盾提供的云服務(wù)需要直接嵌入到用戶的業(yè)務(wù)流程中，比如說登錄，客戶的網(wǎng)站接受用戶的登錄請求后，客戶調(diào)用同盾提供的的服務(wù)，等我們的服務(wù)做出響應(yīng)后再決定下一步行為。通常情況下，客戶給我們的時間是500毫秒左右，除掉網(wǎng)絡(luò)開銷，基本上我們必須在200毫秒內(nèi)做完所有的數(shù)據(jù)分析計算，給客戶響應(yīng)。同時每次調(diào)用都需實時計算，且參與計算的數(shù)據(jù)量非常龐大，會涉及大量的指標運算。如何在短時間內(nèi)完成計算，對整個系統(tǒng)來說是一個較大的挑戰(zhàn)。

2、可用性
和其他云服務(wù)商一樣，我們提供7×24小時的服務(wù)，如果系統(tǒng)掛了，對客戶的系統(tǒng)會造成比較大的影響，如果某臺服務(wù)器掛掉，導(dǎo)致服務(wù)不可用或不穩(wěn)定，這種情況客戶也是不可接受的。是否有完善的災(zāi)備和緊急備選方案，保證在各種異常情況下，整個系統(tǒng)都可持續(xù)使用，這是另一個難點。

3、可擴展性
同盾是為企業(yè)提供服務(wù)，很多大的客戶接進來數(shù)據(jù)量可能是上百萬的流量，隨著客戶的增多，對系統(tǒng)要求的處理能力會越來越大，所以我們整個系統(tǒng)架構(gòu)設(shè)計要求具備隨時可進行線性擴展的能力，比如說現(xiàn)在能夠處理500萬，流量增加一倍的話，能夠通過簡單的加機器可以把處理能力提升到1000萬，這也是一個難點。

系統(tǒng)搭建前期工作

這是最開始我們的系統(tǒng)架構(gòu)。我們做的一些對用戶的管理，最主要的是策略配置，比如說我們在針對借貸風(fēng)險場景做一系列的規(guī)則配置，這些配置會直接寫到數(shù)據(jù)庫里面。我們提供的API，可以加載一些客戶自己定的策略，用戶請求的時候可以通過執(zhí)行策略和規(guī)則，得到風(fēng)險評估的結(jié)果。

具體流程見上圖，可以看到，這里所有的流程幾乎都需要直接和 mysql 交互，導(dǎo)致 mysql 壓力非常大，系統(tǒng)性能一直很差。針對這個問題我們做了兩方面的改進。

首先是讀優(yōu)化，通過使用 Guava Cache，對用戶校驗和查找策略做了緩存處理，并在系統(tǒng)啟動時預(yù)先加載全部用戶數(shù)據(jù)和策略數(shù)據(jù)，并通過定時刷新緩存，保證請求基本不需要訪問 mysql，全部在內(nèi)存中進行計算。

然后是寫優(yōu)化，應(yīng)用寫數(shù)據(jù)時并不直接操作 mysql，而是通過本地任務(wù)隊列異步保存數(shù)據(jù)。這里我們使用的本地隊列是 Berkeley DB。Berkeley DB 是一個內(nèi)存數(shù)據(jù)庫。我們用它主要考慮到Berkeley DB 支持持久化，以及本身處理性能高。如果我們寫入的數(shù)據(jù)，消費端沒有及時刷新數(shù)據(jù)庫，或者寫到其他地方處理完畢，數(shù)據(jù)將會堆積，如果全放在內(nèi)存里，會把內(nèi)存撐爆。Berkeley DB 的持久化性能，剛好可以解決這個問題。

在完成這兩項優(yōu)化后，系統(tǒng)性能已經(jīng)有了很大提升，但在性能上還是不能滿足我們的要求，后面加上了 memcached 的緩存，將數(shù)據(jù)通過 base64 加 Gzip 進行壓縮后存到 memcached 當中，請求進來后，執(zhí)行策略需要做指標計算時，可以很快從cache中取到數(shù)據(jù)，減少與 MySQL 的交互。因為熱點數(shù)據(jù)比較少，為了提高緩存利用率我們將數(shù)據(jù)的過期時間從一天提升到一周，這樣大部分都可以命中緩存，無需再用 MySQL 讀取，對性能有較大提升。

系統(tǒng)前期處理好后，還存在很多單點問題，為了保證整個系統(tǒng)的可用性，得將所有的單點問題消滅掉，首先做了MySQL主備，主機宕機之后用 Keeplived 自動切換到備機。另外Memcached 也是單點，有些應(yīng)用出現(xiàn)問題會導(dǎo)致系統(tǒng)無法效應(yīng)，為了消除單點故障，做了Memcached 集群。

在這個過程中還進行了其他優(yōu)化，主要包括：
MySQL服務(wù)器硬盤從 SAS RAID5 升級到 SSD RAID10，保證較快的讀寫速度。
數(shù)據(jù)庫從 MySQL 5.1 系統(tǒng)升級到 MySQL 5.6，以及對參數(shù)進行優(yōu)化 。
客戶數(shù)據(jù)記錄單表更改為 按客戶分表 ，提升讀寫性能和防止表過度膨脹。
Apache 改成了 NGINX，利用它的動態(tài)修改upstream server的組件，在發(fā)布時將機器自動摘除，發(fā)布完成之后再加入到處理集群中，避免系統(tǒng)性能抖動問題。
另外利用好各種 JVM 工具，如 jstat、jstack、MAT 以及BTrace可以方便地進行JVM的問題排查和優(yōu)化。

災(zāi)備和應(yīng)急方案
應(yīng)用放在一個地方的話，總是會遇到各種各樣的一些問題，所以，為了保障服務(wù)的穩(wěn)定性，我們在阿里云上部署了一套簡化版的服務(wù)，如果在主機房不能正常提供服務(wù)，還有最基本的應(yīng)急方案。
關(guān)于應(yīng)急方案，我們在最前端 Nginx 的 lua 腳本中添加全局開關(guān)，如果某個后臺應(yīng)用出現(xiàn)問題，可以立即通過全局開關(guān)禁用，以免因為某個服務(wù)異常而導(dǎo)致整體響應(yīng)時間過長。同時也可以針對特定用戶設(shè)定開關(guān)，如果某個用戶訪問有異常，也可以通過開關(guān)直接關(guān)掉。通過后臺界面和定制腳本，在出現(xiàn)緊急情況時，可以做到一兩分鐘之內(nèi)切快速切換開關(guān)。

監(jiān)控報警

為了保障實時了解整個系統(tǒng)線上運行情況，需要一個完善的監(jiān)控系統(tǒng)。同盾選擇了 Zabbix。
Zabbix 本身就有很完備的監(jiān)控體系，并且還支持很多插件，可以較方便的搭建一套完整的監(jiān)控報警系統(tǒng)。
Zabbix 主要從幾個基本層面來完善監(jiān)控報警。硬件層面，通過 Load、Memory、Disk、IO 等來判斷。應(yīng)用層面，每個應(yīng)用都有一個默認接口，在 Zabbix 上調(diào)用，看應(yīng)用是否正常返回來檢測。JVM 層面，通過 Heap 使用情況、GC 情況來監(jiān)控。其他，可以通過 Memecached、Nginx、MySQL 的專有插件，來監(jiān)控專門的應(yīng)用，比如 Nginx的 QPS，Memcached 的命中率等。
Zabbix 對內(nèi)部的監(jiān)控還是很強力的，但外部的，諸如 IP，Zabbix 監(jiān)控不到。因此在 Zabbix的基礎(chǔ)上搭配了360 的云監(jiān)控，對 DNS、公網(wǎng)IP 等所有暴露在外部的接口都監(jiān)控起來。

在完成上面的優(yōu)化后，承載線上百萬級的容量沒有太大的問題。但隨著業(yè)務(wù)量的增加，我們首先面臨的最大問題是存儲的問題，因為 MySQL 存儲有限，在數(shù)據(jù)增長過快的情況下，分庫分表已經(jīng)不能很好的解決問題，所以我們又對系統(tǒng)架構(gòu)做了一次調(diào)整：

通過引入 Cassandra 來實現(xiàn)自動水平擴展，整個系統(tǒng)承載能力又得到了一次提升。

最后，從同盾這一年來的經(jīng)驗來說，盡量在選用一些熟悉、成熟和社區(qū)活躍的開源技術(shù)，在創(chuàng)業(yè)初期，以解決業(yè)務(wù)問題為主，先滿足業(yè)務(wù)需求再做優(yōu)化。作為第三方云服務(wù)商，需要監(jiān)控報警和應(yīng)急預(yù)案放在非常重要的位置，如果出現(xiàn)問題能做出最快相應(yīng)。系統(tǒng)的演變迭代是一起復(fù)雜的過程，且會遇到很多問題，要搭建真正的能承載大數(shù)據(jù)訪問的系統(tǒng)，還需多實踐，在這個過程中不斷進行優(yōu)化。

UPYUN Open Talk是 UPYUN 發(fā)起主辦的行業(yè)技術(shù)沙龍，旨在以邀請各行各業(yè)優(yōu)秀的企業(yè)技術(shù)負責人分享介紹自己工作過程中的技術(shù)架構(gòu)經(jīng)驗的方式，推動整個移動互聯(lián)網(wǎng)時代的企業(yè)員工的個人技術(shù)成長，從“人”這個關(guān)鍵點的個人成長提升去幫助推動企業(yè)的快速成長。