摘要：量化派是一家數據驅動的科技金融公司，通過人工智能大數據機器學習等前沿技術提供消費信貸撮合及消費場景下的白條服務，每年處理千萬級用戶信用及信用消費申請。

「小楊」最近裝修房子，準備去銀行貸款，但是聽說好多人會因為個人征信問題被銀行拒絕貸款！于是，他先查了一下自己的央行征信，發現竟然沒有自己的征信信息，「小楊」陷入了沉思，自己經常在淘寶、jd 上買東西，也有淘寶花唄和京東白條，怎么會沒有征信呢？

其實，還有很多人都像「小楊」一樣各項手續備齊了跑去銀行貸款，卻因為征信問題很不幸地被拒之門外！那么，沒有征信信息就沒有辦法辦理貸款了么？

小編打聽到，現實中除了央行的征信之外，其實還有很多互聯網金融公司可以通過用戶日常的網絡消費習慣等信息，再通過人工智能進行計算，從而生成一份信用評價。對于「小楊」這類人來說，這無疑是個好消息。

那么問題來了，這些互聯網金融公司是如何通過人工智能測算出一個人的隱形征信呢？背后的黑科技到底是什么呢？

今天，小編就帶大家走進一家通過微信、手機話費、淘寶或者京東電商賬戶等第三方信息自動生成信用評價的公司 —— 量化派。

量化派是一家數據驅動的科技金融 Fintech 公司，通過人工智能、大數據機器學習等前沿技術提供消費信貸撮合及消費場景下的白條服務，每年處理千萬級用戶信用及信用消費申請。在 QingCloud Insight 2017「金融云架構與實踐」專場中，量化派技術總監周乾，分享了「量化派的云端架構實踐」議題，講述在原有的 IDC 托管服務已經無法滿足量化派在基礎設施快速擴容、高可用及監控管理等方面的需求時，量化派的解決之道。

先介紹一下量化派的流量大概是怎么接入的？作為一個互聯網企業，網站的入口是最為重要的，量化派使用了青云的負載均衡技術，它是一個基于四層網絡的負載均衡，自身有非常多的特性，可以方便的搭建企業網站。

量化派是如何使用青云的負載均衡的呢？

第一是加速高層協議，包括七層 HTTP 和 HTTPS 的協議。量化派通過最遠端的負載均衡器，先是通過防火墻，一個青松的防護，還有青云提供的 CDN 技術，作為量化派前端的流量平臺。通過路由器帶領到終端的轉發到四層負載均衡器上，四層負載均衡器后面有一層 Nginx 平臺，Nginx 平臺作為七層的流量服務，就接入到了后面的 Web Server 以及服務器。

為什么這樣做？

第一，可以抗高并發。因為許多小企業很難把一個大的流量接入做起來，通過四層的負載均衡器，方便地提升 Nginx Server 的個數，在這里面接入流量還有一個明顯的特點，量化派的 Nginx 通過系統 Linux 自帶的 rsyslog，通過 UDP 的方式，把日志匯總到目標日志機上，這個目標日志機做了一個類似于流量監聽堂路，監聽到七層流量堂路后，量化派會監控用戶訪問的行為，一旦發現有異常的用戶，比如說類似爬蟲這種，系統就會反饋到七層流量平臺上。這個七層流量平臺是可以通過 Lua 進行編程的，異常 IP 給封殺掉。

量化派用到的第二個青云的負載均衡器的特性，基于四層做了很多代理，包括消息隊列的代理，消息隊列集群的代理，包括多個數據庫的代理，通過負載均衡器，可以提升后端的數據庫以及消息隊列的性能，保證并發的數量。

量化派是公有云和私有云混合的。

量化派有若干個網段，第一個種類型的網段是在青云的 VPC 里面，用 256 個機器組成的一個局域網。

第二個，因為量化派是一個基于大數據的互聯網金融公司，所以有自己的 HBase 集群，在把 HBase 牽到青云上的時，有一個基本問題，性能問題。為什么呢？青云的硬盤在寫的時候是有多重復本，復本加上 HBase 自己設置的復制級個數，類似于當寫入一條數據時，如果復制級的個數是 3 的話，在磁盤上就寫了 6 次，解決這個問題的根本就是搭建了一個混合云的服務，利用自己的物理機，同時在青云的機房部署服務的機器，把 HBase 遷移過去，讓服務器的性能達到我們使用要求。公有云和私有云混合部署的方式，中間通過 GRE 隧道去打通。

再說一說量化派的高可用架構方案，首先，因為歷史原因，量化派的數據庫在自己的 IDC 機房里面，在后來牽到了青云，所以沒有用到青云的數據庫方案，量化派自己利用 MHA 的架構搭建了一套數據庫的集群，做到了高可用。

第二個高可用方案，量化派利用 Zookeeper 一致性的中間件做了高可用方案，它適用的場景是什么呢？因為量化派有很多微服務，這些微服務之間每個可能都有定時任務。定時任務中心會去 Zookeeper 里選取一個主節點，這個主節點會通知各個業務系統，在合適的時間做合適的任務。另外，量化派的 RPC 也是用 Zookeeper 構建起來的，RPC 可以做到各個微服務之間的協調，上線和下線做到非常完備。

第三個高可用技術是 Keepalived，利用的虛擬冗余路由協議，偽造了一個虛 IP，這個場景用到什么情況下呢？Keepalived 在數據庫里面，當我們在做 double master 一個架構的時候，其實可以用 Keepalived 讓一個數據庫一直在線上服務，當他的數據庫掛掉，可以迅速切換到第二個服務器上去。在用 MHA 的時候，也用到 Keepalived，MHA 架構只有一個單主機數據庫，這個單主機數據庫，線上應用一直連到這個數據庫，當這個主數據庫掛掉，MHA會自動重啟另外一個數據庫，讓從庫選取一個新的主，從庫就開啟一個 Keepalived 結點，線上應用完全可以做到對數據庫的切換沒有感知。

第四個高可用技術，是 Redis 里面用到 Sentinel Master Slave 這樣一種結構， Redis 會去啟用一堆監聽結點，它會去監控每一個 Redis 結點的存活，當有 Redis 主掛掉的時候，這些監聽結點可以選取出一個新的 Redis。

第五個高可用的技術架構是 Hazelcast，它是基于 UDP 廣播的形式去做一個服務的發現，目前在 Java 里面很多框架已經有 Hazelcast 的案例了。利用這些高可用的技術架構，就可以保證量化派的服務是穩定可靠的。

量化派的公有云和私有云之間是跨網段的，他們之間會有通信，經常需要大流量的數據傳輸，我們怎么保證公有云和私有云之間，或與外部的流量接入有序，保證服務是穩定的？

首先我們用到了一些限流技術，主要的限流技術包括哪些呢？第一個我們會利用消息隊列緩存消息，避免網絡擁塞。舉一個典型的例子，量化派有 6 億的用戶數據，這 6 億的數據構成了一個網絡，這些數據是在私有云里面，如果分別將三百個結點的數據庫，做成一個用戶聯系人網絡，一定會涉及到數據傳輸。數據傳輸，如果在兩個服務之間直接調用的話，線上的帶寬會都被占滿，利用消息隊列把數據緩存出來，做了一個限流的傳輸。在此過程中，消息隊列在大量數據情況下，也會有被壓崩潰的可能，所有需要用到更多的限流技術，包括利用 amqp API 控制發送速率。

另外在量化派的生產端和服務端，分別用了一些限流的技術，包括利用谷歌的 guava ratelimiter 控制發送和消費的速率。還有包括利用 Nginx 限流插件控制消費速率，這個也可以保證服務器接收到的流量是比較穩定的。最后用到的限流和服務降級是 hystrix，在微服務之間如果調用過量，它可以做到降級以及限制流量的大小。

量化派是一個由很多微服務組成的大型系統，這個系統里面有一個典型的問題，量化派對接了多家的流量，有時對接這些流量的 API 需要知道后臺的貸款狀態，那怎樣讓這些公司知道貸款狀態呢？這里涉及到一種典型的事件解耦技術，首先業務端不需要知道貸款的變化，當用戶在平臺貸款發生變化時，數據庫會自動增長。

量化派開發了一套基于 canal 的程序，它偽裝成數據庫的從庫，去訂閱這個數據庫的 binlog，訂閱到 binlog 之后，解析到數據庫定單的狀態發生變更，緊接著就把它發送到隊列里，這個隊列就會把它廣播到各個業務系統，做到典型的業務和業務之間的解耦。那么消費到這個定單狀態變更的服務，接著就可以把定單的狀態變化發送給第三方公司了。

說說量化派多角度監控，首先收集日志，從數據庫里面收集監控的狀態，因為這樣對系統的負載以及復雜度都會有提升。業務系統會產生日志，通過 File beat 這樣一個中間件，把日志的數據送到 Kafka 的集群里去，接著在另外一個集群里，有一堆日志解析器，他們去監聽 Kafka 集群，把數據收集出來之后，通過相對平穩的速率，把日志放在搜索引擎中，這個搜索引擎里基本上有一些被檢索的數據，開發人員需要在日志里去埋點。

一個典型的例子，比如風控，有些用戶的定單會按照一些規則通過，有些回按照一些規則把它拒絕，如果想看每時每刻的通過率和規則情況，開發人員通過 Falcon 這個系統，定時的檢索搜索引擎，把關鍵的字段作為檢索項拿出來去和另外的數據進行對比，再產生報表，這個報表里面設定一些監控的準則，把這個監控給做起來。下圖是量化派一個典型的監控樣例，剛剛講的是一個業務數據的監控。

說一下量化派并發思想，量化派的自動化部署和編譯系統，用的是典型的 Fork join 模型，在線上把代碼給編譯起來，之后會通過自研的一套平臺，去各個機器上拷貝包和部署。這中間其實有一個 Fork join 過程，假如你有一百臺機器，基本上會并發上線前 50 臺機器，再并發的上線后 50 臺機器。

第二個并發思想大量的用到了池化技術，量化派的各服務之間大多沒有暴露接口，暴露的是 SDK，比如消息中心，消息中心接了非常多的短信，他們之間通過消息隊列去發送消息，消息隊列的連接用的池化技術進行包裝。還有大量的利用了并行功能，有時候用戶下一單，如果希望用戶能快速的看到結果，這樣用戶會去過一下規則引擎，這個規則引擎中間又有模型，又有各種各樣的數據，這個數據要做到實時響應就一定要用到并行計算，里面用到的 Java 8 的 Parallel Stream，它會把提取數據的任務首先去塞到 list 里，塞到數組里面去，然后并行地把數據獲取出來，這里面關鍵的思想就是找到數據之間的依賴項，把不依賴的任務盡量的并行化。其次，量化派還利用了異步 IO 技術增加吞吐量。

另外，提升并發的技術是利用消息隊列分解我們大事務，量化派會將一些事務送到不同的服務上去執行，這個執行是通過消息隊列去完成的，前端直接返回一些偽造的數據。還有一些技術，包括一個單進程里面，希望用戶能夠盡快的得到響應，有一些事務在單進程里面自己慢慢的消化掉，這里用到了 Spring event，異步內部化的一些事務。

安全方面，量化派用的機器是堡壘機，量化派走了兩段歷史：

第一個是改造一個開源的堡壘機系統，系統中用戶的登錄、統計、審計等都可以看到。

第二個數據庫審計。青云現在已經有了數據庫審計，當年我們用青云的時候還沒有，所以我們自己改造了一套數據庫審計。其基本的原理就是，我們會做一個客戶端，這個客戶端提供給大家訪問，我們解析這個 MySQL 的協議，最后會把誰執行了什么語句，在什么 IP 上，都會進行日志留痕。

對于 B 端的接口，量化派自研了一個安全層，其目的是什么呢？大家去對接第三方接口的時候一直有各種各樣的加密標準，并且很多時候研發會把精力集中到安全的標準上面去，這個加密本身也是挺困難的一件事。量化派是怎么做的呢？做了一個七層的代理，這個代理帶有安全功能，并且對外分發公鑰，去交換公鑰。B 端系統通過接入我們安全層，就可以由 B 端自己實現安全，B 端接口數據加密通過安全層把它過濾成一個明文數據，反過來代理到量化派的系統上，這樣整個加密規范，最終就是一模一樣的。

對安全的考慮，包括一些關鍵的接口上采用動態密碼，避免回放攻擊，采用 HTTPS 進行通信，避免劫持以及中間人攻擊，另外還采用 orm，利用 pojo 訪問數據庫，杜絕 SQL 注入等手段。

量化派的架構拆分，服務治理就是利用通信中間件做到的，包括異步的話 MJQ 集群去做通信治理，RPC 調用的話，會用一些 RPC 的技術進行通信。各個服務之間有一個基本的問題就是，用戶的狀態怎么去考慮？大家都知道，一個用戶登錄了系統，緊接著跳到支付中心去，支付中心怎么知道這個人是誰？因為是一個異構的系統。量化派中間有兩種不同的通過方式，包括服務之間的 Session，以及通過用戶系統直接訪問 Token 去做安全校驗。

「加速助力」AppCenter 2.0 提供包括計費、支付、財務報表、監控告警、工單系統、用戶管理等一系列運營管理功能，為合作伙伴提供完善的商業運營支持。借助 AppCenter 2.0 平臺，合作伙伴可以直接擁有云計算平臺所需各類功能模塊，快速便捷地開啟商業運營之路。

青云QingCloud AppCenter 是一個生態平臺，歡迎更多其它企業服務應用入駐 AppCenter，一起為 QingCloud 逾 8 萬家用戶提供優質服務。申請加入：

https://appcenter.qingcloud.c...

一、面向合作伙伴

AppCenter 認證應用服務商獎勵計劃

應用服務商在 AppCenter 發布應用經 QingCloud 認證后，可獲得的獎勵額度為 QingCloud 用戶通過部署該應用所帶來的資源（僅含主機和硬盤）消費的 10%。

“平步青云” AppCenter 伙伴計劃

企業服務方向的創業項目，經 QingCloud 認證審核后，可獲得 2 萬元的云服務資源贊助，同時應用可以入駐 AppCenter。了解更多：

https://www.qingcloud.com/pro...

二、面向用戶 —— AppCenter 資源優惠計劃

公有云用戶通過 AppCenter 應用所使用的主機和硬盤資源可享受 10% 的優惠。