UPYUN Open Talk ：同盾，從零打造千萬級實時風控雲服務

同盾科技，是由阿里、Paypal 反欺詐專家建立的，國內第一家風險控制與反欺詐雲服務提供商，其涉及領域包括電商、B2B、互聯網金融、遊戲等。同盾技術總監張新波在 UPYUN Open Talk第二期《移動時代互聯網金融的架構趨勢》中闡述了同盾是如何從零開始打造千萬級實時風控雲服務，具體介紹了同盾系統平臺構建過程當中主要須要解決的三大難題，以及解決這些問題的具體時實踐過程。

同盾的後臺系統是一套很是強大的，規則靈活配置的管理系統，搭建這個平臺同盾主要面臨瞭如下幾個難點：
一、性能
同盾提供的雲服務須要直接嵌入到用戶的業務流程中，好比說登陸，客戶的網站接受用戶的登陸請求後，客戶調用同盾提供的的服務，等咱們的服務作出響應後再決定下一步行爲。一般狀況下，客戶給咱們的時間是500毫秒左右，除掉網絡開銷，基本上咱們必須在200毫秒內作完全部的數據分析計算，給客戶響應。同時每次調用都需實時計算，且參與計算的數據量很是龐大，會涉及大量的指標運算。如何在短期內完成計算，對整個系統來講是一個較大的挑戰。

二、可用性
和其餘雲服務商同樣，咱們提供7×24小時的服務，若是系統掛了，對客戶的系統會形成比較大的影響，若是某臺服務器掛掉，致使服務不可用或不穩定，這種狀況客戶也是不可接受的。是否有完善的災備和緊急備選方案，保證在各類異常狀況下，整個系統均可持續使用，這是另外一個難點。

三、可擴展性
同盾是爲企業提供服務，不少大的客戶接進來數據量多是上百萬的流量，隨着客戶的增多，對系統要求的處理能力會愈來愈大，因此咱們整個系統架構設計要求具有隨時可進行線性擴展的能力，好比說如今可以處理500萬，流量增長一倍的話，可以經過簡單的加機器能夠把處理能力提高到1000萬，這也是一個難點。

系統搭建前期工做

這是最開始咱們的系統架構。咱們作的一些對用戶的管理，最主要的是策略配置，好比說咱們在針對借貸風險場景作一系列的規則配置，這些配置會直接寫到數據庫裏面。咱們提供的API，能夠加載一些客戶本身定的策略，用戶請求的時候能夠經過執行策略和規則，獲得風險評估的結果。

具體流程見上圖，能夠看到，這裏全部的流程幾乎都須要直接和 mysql 交互，致使 mysql 壓力很是大，系統性能一直不好。針對這個問題咱們作了兩方面的改進。

首先是讀優化，經過使用 Guava Cache，對用戶校驗和查找策略作了緩存處理，並在系統啓動時預先加載所有用戶數據和策略數據，並經過定時刷新緩存，保證請求基本不須要訪問 mysql，所有在內存中進行計算。

而後是寫優化，應用寫數據時並不直接操做 mysql，而是經過本地任務隊列異步保存數據。這裏咱們使用的本地隊列是 Berkeley DB。Berkeley DB 是一個內存數據庫。咱們用它主要考慮到Berkeley DB 支持持久化，以及自己處理性能高。若是咱們寫入的數據，消費端沒有及時刷新數據庫，或者寫到其餘地方處理完畢，數據將會堆積，若是全放在內存裏，會把內存撐爆。Berkeley DB 的持久化性能，恰好能夠解決這個問題。

在完成這兩項優化後，系統性能已經有了很大提高，但在性能上仍是不能知足咱們的要求，後面加上了 memcached 的緩存，將數據經過 base64 加 Gzip 進行壓縮後存到 memcached 當中，請求進來後，執行策略須要作指標計算時，能夠很快從cache中取到數據，減小與 MySQL 的交互。由於熱點數據比較少，爲了提升緩存利用率咱們將數據的過時時間從一天提高到一週，這樣大部分均可以命中緩存，無需再用 MySQL 讀取，對性能有較大提高。

系統前期處理好後，還存在不少單點問題，爲了保證整個系統的可用性，得將全部的單點問題消滅掉，首先作了MySQL主備，主機宕機以後用 Keeplived 自動切換到備機。另外Memcached 也是單點，有些應用出現問題會致使系統沒法效應，爲了消除單點故障，作了Memcached 集羣。

在這個過程當中還進行了其餘優化，主要包括：
MySQL服務器硬盤從 SAS RAID5 升級到 SSD RAID10，保證較快的讀寫速度。
數據庫從 MySQL 5.1 系統升級到 MySQL 5.6，以及對參數進行優化 。
客戶數據記錄單表更改成 按客戶分表 ，提高讀寫性能和防止表過分膨脹。
Apache 改爲了 NGINX，利用它的動態修改upstream server的組件，在發佈時將機器自動摘除，發佈完成以後再加入處處理集羣中，避免系統性能抖動問題。
另外利用好各類 JVM 工具，如 jstat、jstack、MAT 以及BTrace能夠方便地進行JVM的問題排查和優化。

災備和應急方案
應用放在一個地方的話，老是會遇到各類各樣的一些問題，因此，爲了保障服務的穩定性，咱們在阿里雲上部署了一套簡化版的服務，若是在主機房不能正常提供服務，還有最基本的應急方案。
關於應急方案，咱們在最前端 Nginx 的 lua 腳本中添加全局開關，若是某個後臺應用出現問題，能夠當即經過全局開關禁用，以避免由於某個服務異常而致使總體響應時間過長。同時也能夠針對特定用戶設定開關，若是某個用戶訪問有異常，也能夠經過開關直接關掉。經過後臺界面和定製腳本，在出現緊急狀況時，能夠作到一兩分鐘以內切快速切換開關。

監控報警

爲了保障實時瞭解整個系統線上運行狀況，須要一個完善的監控系統。同盾選擇了 Zabbix。
Zabbix 自己就有很完備的監控體系，而且還支持不少插件，能夠較方便的搭建一套完整的監控報警系統。
Zabbix 主要從幾個基本層面來完善監控報警。硬件層面，經過 Load、Memory、Disk、IO 等來判斷。應用層面，每一個應用都有一個默認接口，在 Zabbix 上調用，看應用是否正常返回來檢測。JVM 層面，經過 Heap 使用狀況、GC 狀況來監控。其餘，能夠經過 Memecached、Nginx、MySQL 的專有插件，來監控專門的應用，好比 Nginx的 QPS，Memcached 的命中率等。
Zabbix 對內部的監控仍是很強力的，但外部的，諸如 IP，Zabbix 監控不到。所以在 Zabbix的基礎上搭配了360 的雲監控，對 DNS、公網IP 等全部暴露在外部的接口都監控起來。

在完成上面的優化後，承載線上百萬級的容量沒有太大的問題。但隨着業務量的增長，咱們首先面臨的最大問題是存儲的問題，由於 MySQL 存儲有限，在數據增加過快的狀況下，分庫分表已經不能很好的解決問題，因此咱們又對系統架構作了一次調整：

經過引入 Cassandra 來實現自動水平擴展，整個系統承載能力又獲得了一次提高。

最後，從同盾這一年來的經驗來講，儘可能在選用一些熟悉、成熟和社區活躍的開源技術，在創業初期，以解決業務問題爲主，先知足業務需求再作優化。做爲第三方雲服務商，須要監控報警和應急預案放在很是重要的位置，若是出現問題能作出最快相應。系統的演變迭代是一塊兒複雜的過程，且會遇到不少問題，要搭建真正的能承載大數據訪問的系統，還需多實踐，在這個過程當中不斷進行優化。

UPYUN Open Talk是 UPYUN 發起主辦的行業技術沙龍，旨在以邀請各行各業優秀的企業技術負責人分享介紹本身工做過程當中的技術架構經驗的方式，推進整個移動互聯網時代的企業員工的我的技術成長，從「人」這個關鍵點的我的成長提高去幫助推進企業的快速成長。