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

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

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

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

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

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

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

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

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

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

為什么這樣做？

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

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

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

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

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

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

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

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

第四個高可用技術(shù)，是 Redis 里面用到 Sentinel Master Slave 這樣一種結(jié)構(gòu)， Redis 會去啟用一堆監(jiān)聽結(jié)點，它會去監(jiān)控每一個 Redis 結(jié)點的存活，當(dāng)有 Redis 主掛掉的時候，這些監(jiān)聽結(jié)點可以選取出一個新的 Redis。

第五個高可用的技術(shù)架構(gòu)是 Hazelcast，它是基于 UDP 廣播的形式去做一個服務(wù)的發(fā)現(xiàn)，目前在 Java 里面很多框架已經(jīng)有 Hazelcast 的案例了。利用這些高可用的技術(shù)架構(gòu)，就可以保證量化派的服務(wù)是穩(wěn)定可靠的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

青云QingCloud AppCenter 是一個生態(tài)平臺，歡迎更多其它企業(yè)服務(wù)應(yīng)用入駐 AppCenter，一起為 QingCloud 逾 8 萬家用戶提供優(yōu)質(zhì)服務(wù)。申請加入：

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

一、面向合作伙伴

AppCenter 認(rèn)證應(yīng)用服務(wù)商獎勵計劃

應(yīng)用服務(wù)商在 AppCenter 發(fā)布應(yīng)用經(jīng) QingCloud 認(rèn)證后，可獲得的獎勵額度為 QingCloud 用戶通過部署該應(yīng)用所帶來的資源（僅含主機(jī)和硬盤）消費的 10%。

“平步青云” AppCenter 伙伴計劃

企業(yè)服務(wù)方向的創(chuàng)業(yè)項目，經(jīng) QingCloud 認(rèn)證審核后，可獲得 2 萬元的云服務(wù)資源贊助，同時應(yīng)用可以入駐 AppCenter。了解更多：

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

二、面向用戶 —— AppCenter 資源優(yōu)惠計劃

公有云用戶通過 AppCenter 應(yīng)用所使用的主機(jī)和硬盤資源可享受 10% 的優(yōu)惠。