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

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

其實(shí)，還有很多人都像「小楊」一樣各項(xiàng)手續(xù)備齊了跑去銀行貸款，卻因?yàn)檎餍艈栴}很不幸地被拒之門外！那么，沒有征信信息就沒有辦法辦理貸款了么？

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

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

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

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

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

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

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

為什么這樣做？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一、面向合作伙伴

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

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

“平步青云” AppCenter 伙伴計(jì)劃

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

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

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

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