「小楊」最近裝修房子,準備去銀行貸款,可是據說好多人會由於我的徵信問題被銀行拒絕貸款!因而,他先查了一下本身的央行徵信,發現居然沒有本身的徵信信息,「小楊」陷入了沉思,本身常常在淘寶、jd 上買東西,也有淘寶花唄和京東白條,怎麼會沒有徵信呢?html
其實,還有不少人都像「小楊」同樣各項手續備齊了跑去銀行貸款,卻由於徵信問題很不幸地被拒之門外!那麼,沒有徵信信息就沒有辦法辦理貸款了麼?前端
小編打聽到,現實中除了央行的徵信以外,其實還有不少互聯網金融公司能夠經過用戶平常的網絡消費習慣等信息,再經過人工智能進行計算,從而生成一份信用評價。對於「小楊」這類人來講,這無疑是個好消息。數據庫
那麼問題來了,這些互聯網金融公司是如何經過人工智能測算出一我的的隱形徵信呢?背後的黑科技究竟是什麼呢?編程
今天,小編就帶你們走進一家經過微信、手機話費、淘寶或者京東電商帳戶等第三方信息自動生成信用評價的公司 —— 量化派。後端
量化派是一家數據驅動的科技金融 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...
1、面向合做夥伴
AppCenter 認證應用服務商獎勵計劃
應用服務商在 AppCenter 發佈應用經 QingCloud 認證後,可得到的獎勵額度爲 QingCloud 用戶經過部署該應用所帶來的資源(僅含主機和硬盤)消費的 10%。
「平步青雲」 AppCenter 夥伴計劃
企業服務方向的創業項目,經 QingCloud 認證審覈後,可得到 2 萬元的雲服務資源贊助,同時應用能夠入駐 AppCenter。瞭解更多:
https://www.qingcloud.com/pro...
2、面向用戶 —— AppCenter 資源優惠計劃
公有云用戶經過 AppCenter 應用所使用的主機和硬盤資源可享受 10% 的優惠。