[[196273]]

從公司成立敲出第一行代碼到現(xiàn)在也快三年了，平臺的技術(shù)架構(gòu)，技術(shù)體系也經(jīng)歷了四次比較重大的升級(目前第四代架構(gòu)體系正在進行中)，本文將帶大家回顧一家小公司從最開始的零交易到現(xiàn)在交易量超過百億背后的技術(shù)變遷。

[[196274]]

在互聯(lián)網(wǎng)金融行業(yè)一百多億算不上大平臺，也就是個二級陣營，它每次的架構(gòu)升級都是伴隨著業(yè)務(wù)的重大變化而推進的，在前一代系統(tǒng)架構(gòu)上遇到的問題，業(yè)務(wù)開發(fā)過程中就會積累一些優(yōu)秀的開發(fā)案例，在下一代系統(tǒng)開發(fā)中就會大力推進架構(gòu)升級。

一方面可以平滑過度，另一方面公司資源可以大力支持，同時技術(shù)團隊可以使用到前沿的技術(shù)，更有開發(fā)的成就感，我們大概9個月對系統(tǒng)架構(gòu)做一次升級，直到現(xiàn)在的第四套架構(gòu)。

很多網(wǎng)友經(jīng)常會問，你們平臺的TPS是多少，最大并發(fā)是多少，性能怎么樣，說實話我們是一家小公司，最夸張也就是上萬人同時搶標，但是作為一個中型的互聯(lián)網(wǎng)金融平臺要做的事情真的不少，遠遠不只是這些參數(shù)可以說的清楚的。

我們也不是什么高大上的平臺，使用的技術(shù)也是目前比較主流的開源產(chǎn)品，但在公司不斷發(fā)展的過程中也遇到了很多的問題，我們盡量去使用比較主流的、開源的、適合我們的一些解決方案來構(gòu)建整個系統(tǒng)，在這里分享平臺發(fā)展背后技術(shù)升級換代的變化。

我們進行了四次大的架構(gòu)變化，每代架構(gòu)都用一句話來總結(jié)：

• 第一代架構(gòu)特點：業(yè)務(wù)比較集中、功能滿足投資理財需求、快速上線。
• 第二代架構(gòu)特點：分布式系統(tǒng)改造，平臺化初具規(guī)模，各項垂直業(yè)務(wù)系統(tǒng)搭建上線、產(chǎn)品端極大豐富用戶投資、大數(shù)據(jù)平臺研究并使用。
• 第三代架構(gòu)特點：SOA 治理，使用 zookeeper 作為注冊中心，dubbo 做監(jiān)控和調(diào)度中心;cas 實現(xiàn)單點登錄，使用 shiro 做權(quán)限控制。
• 第四代架構(gòu)特點：全面啟用微服務(wù)開發(fā)模式，springboot+springcloud 技術(shù)棧做為第四代架構(gòu)技術(shù)支撐。

第一代系統(tǒng)架構(gòu)

2014 年是互聯(lián)網(wǎng)金融元年，在此之前已經(jīng)有很多互聯(lián)網(wǎng)公司用著各種商業(yè)模式在生存，一直不溫不火。直到 2014 年突然火爆了起來。

首先是網(wǎng)貸之家，網(wǎng)貸天眼這種第三方網(wǎng)站流量突然暴增，接著是媒體報道的不斷跟進，再后來各種互聯(lián)網(wǎng)金融公司獲得XXX美元投資的報道越來越多，政策也慢慢明朗，于是很多大型公司(集團)也就趁著這股熱潮跟進，其中就包括我們。

第一代系統(tǒng)最主要就是搶時間，公司希望用最短的時間內(nèi)保證系統(tǒng)上線，那時候移動浪潮已經(jīng)啟動，于是決定優(yōu)先上線移動端，網(wǎng)站可以暫不考慮。

公司當時有 PHP 和 Java 兩種開發(fā)語言技術(shù)儲備，因為 PHP 在快速開發(fā)上面有著非常大的優(yōu)勢，因此決定采用前端 PHP+后端 Java 這種模式。

系統(tǒng)分成了三層：

• 用戶層：安卓和 iOS 移動端;
• 接口層：PHP 提供用戶和交易接口;
• 后端：包括兩部分，后臺和定時系統(tǒng)。后臺的 PHP 開發(fā)和接口層公用了一個系統(tǒng)，另一個是定時系統(tǒng)，負責計息、派息、到期等定時任務(wù)，使用了 Java 開發(fā)。

基礎(chǔ)服務(wù)和中間件，MySQL 做了最基本的主從支持，第一代系統(tǒng)只是使用了 MySQL 的主庫，從庫只是同步備份;memcached 用來處理用戶搶標的并發(fā)問題，也只用了這一塊;ActiveMQ 用來使用二級市場的轉(zhuǎn)讓撮合以及其他一些異步消息通知。

項目部署：PHP 使用 Apache 部署，定時服務(wù)使用 tomcat6 來做應(yīng)用服務(wù)器，使用 lvs 做前端 Apache 的負載，基本上第一代也就這些技術(shù)了，下面是第一代系統(tǒng)的架構(gòu)圖。

第一代系統(tǒng)上線之后，網(wǎng)站和 H5(手機瀏覽器或者微信端)系統(tǒng)建設(shè)就變的特別突出，作為一個互聯(lián)網(wǎng)金融公司不能沒有官網(wǎng)，于是又馬不停蹄的開始開發(fā)網(wǎng)站和 H5 系統(tǒng)。

在這個期間將 PHP 之前做的后臺這塊摘了出來，用 Java 重新規(guī)劃了一版，至此 PHP 就負責了網(wǎng)站、APP 接口、H5 這三個系統(tǒng)，三個系統(tǒng)共用一個核心交易，Java 負責后臺管理和定時服務(wù)，我們一般給這個架構(gòu)叫做 1.1 代架構(gòu)。

第1.1代系統(tǒng)架構(gòu)圖如下，綠色部分為變動部分。

第一代系統(tǒng)的缺點是業(yè)務(wù)過于集中，倉促上線，后期問題較多。

第二代系統(tǒng)架構(gòu)

第二代系統(tǒng)的背景是隨著公司業(yè)務(wù)量的快速發(fā)展，很多初期所欠的技術(shù)債統(tǒng)統(tǒng)爆發(fā)，線上出現(xiàn)了很多問題，最嚴重的一次是給個別用戶重復(fù)派息，各種被罵，現(xiàn)在仍記憶猶新。

另一方面，各業(yè)務(wù)部門需求不斷增加，公司產(chǎn)品需求不斷增加，所以這個階段就是忙著修復(fù)各種生產(chǎn)問題，還需要開發(fā)垂直業(yè)務(wù)系統(tǒng)。

那段時間差點被逼瘋了，第一代系統(tǒng)是封閉開發(fā)，回來還沒緩過勁來，這邊又開始趕馬上架，真是痛并快樂著。

第一個垂直子系統(tǒng)上線的是：

• 合同系統(tǒng)：當時用戶投標后沒有一個合同，很多用戶很不放心，然后就把優(yōu)先級提到了前面。

后來單就合同系統(tǒng)就改了三個版本，第一個版本只是生成 PDF，第二階段上線電子簽章，第三個階段加水印，自定義動態(tài)生成 PDF。

• 積分系統(tǒng)：用戶邀請，投資等生產(chǎn)積分，用來兌換抵現(xiàn)券等。
• 消息系統(tǒng)：站內(nèi)消息、短信、郵件等。
• 監(jiān)控系統(tǒng)：業(yè)務(wù)監(jiān)控和服務(wù)監(jiān)控，業(yè)務(wù)失敗預(yù)警。
• 財務(wù)系統(tǒng)：財務(wù)人員統(tǒng)計核算金額。
• 風控系統(tǒng)：監(jiān)控異常用戶、異常交易。
• 銷售系統(tǒng)：為銷售部門開發(fā)。
• 對外接入系統(tǒng)：實現(xiàn)與第三方系統(tǒng)的對接。

一代系統(tǒng)做的時間很趕，產(chǎn)品界面的用戶體驗不好，隨即啟動規(guī)劃了網(wǎng)站 2.0、APP2.0、H52.0，針對前端系統(tǒng)的需求，在后端開發(fā)了 CMS 系統(tǒng)來發(fā)布項目、公司的公告新聞等。

第二代產(chǎn)品端普遍規(guī)劃了很多大數(shù)據(jù)分析的一些需求，會在官網(wǎng)展示全量數(shù)據(jù)分析后投資偏好、投資的金額流向分析，用地圖形式進行展示。

對于個人也會有還款日歷，代收數(shù)據(jù)分析等，因為需要跑全量數(shù)據(jù)，在規(guī)劃的時候都設(shè)計為離線處理，將數(shù)據(jù)從 MySQL 從庫同步到 mongodb 的集群中，利用 mongdo 的 mapreduce 技術(shù)來處理大量的數(shù)據(jù)。

于是，我們的數(shù)據(jù)庫層就變成下面的這個架構(gòu)。

MySQL 實時同步到 mongodb，我們使用的是 tungsten-relicator 這個工具，會在 MySQL 服務(wù)器端啟動一個監(jiān)控 agent，實時監(jiān)控 MySQL的binlog 日志。

同時在 mongodb 的服務(wù)器端也起了一個服務(wù)端，agent 監(jiān)控到數(shù)據(jù)變化后傳送給服務(wù)端，服務(wù)端解析后插入到 mongodb 集群中以達到實時同步的效果。

數(shù)據(jù)清洗系統(tǒng)，我們大膽使用了 golang 來開發(fā)，當時使用的 golang 版本是 1.3，現(xiàn)在都 1.8 了，以前也是沒有接觸過，也算是鍛煉了隊伍。

好在 golang 語言本身非常簡潔和高效，雖然踩了 N 多坑，但是最終我們還是按時投產(chǎn)了，后來又使用了 golang 開發(fā)了一個后臺，是在 beego 框架的基礎(chǔ)上來做的。

大數(shù)據(jù)分析系統(tǒng)后來又升級了一代，在前端的各業(yè)務(wù)系統(tǒng)，UI 用戶層做了很多埋點來收集用戶數(shù)據(jù)，通過 activeMQ 傳輸接收，最后存儲到 mongodb。

再進行數(shù)據(jù)清洗，將清洗后的結(jié)果存入到結(jié)果庫中，供前端業(yè)務(wù)系統(tǒng)使用，后來利用 beego+echart 重新做了一版數(shù)據(jù)分析系統(tǒng)。

大數(shù)據(jù)系統(tǒng)的架構(gòu)圖如下：

因為后端數(shù)據(jù)庫的壓力不斷增大，后端管理系統(tǒng)、業(yè)務(wù)系統(tǒng)均作了主從分離，后臺管理系統(tǒng)增加緩存，啟動了 redis 做緩存，使用 nginx 搭建了獨立的圖片服務(wù)器。

第二代系統(tǒng)開發(fā)過程中，也是公司發(fā)展最快的階段，上線了 N 多的活動。

第二代系統(tǒng)架構(gòu)圖如下：

第二代架構(gòu)上線了各業(yè)務(wù)系統(tǒng)，做了主從分離，搭建了大數(shù)據(jù)平臺為以后更多的數(shù)據(jù)處理提供了技術(shù)基礎(chǔ)。

缺點：各業(yè)務(wù)系統(tǒng)切分之后，各項目之間調(diào)用復(fù)雜，后臺系統(tǒng)繁多、各系統(tǒng)之間有單獨的賬戶系統(tǒng)，運營需要來回切換完成平臺運營監(jiān)控。

第三代系統(tǒng)架構(gòu)

第二代系統(tǒng)開發(fā)完成之后，留給我們了三個很痛苦的問題：

• 隨著業(yè)務(wù)系統(tǒng)不斷增多，系統(tǒng)之間的調(diào)用關(guān)系成指數(shù)級別上漲，在第三代系統(tǒng)初期，我們又開發(fā)了很多基礎(chǔ)組件，更是加劇了這個問題。
• 第二個問題和第一個問題相輔相成，系統(tǒng)之間調(diào)用關(guān)系太多，如果移動其中一個子系統(tǒng)，可能需要修改關(guān)聯(lián)系統(tǒng)的配置文件，重新啟動服務(wù)，經(jīng)常因為更新一個系統(tǒng)，其他系統(tǒng)也需要被動更新，投產(chǎn)和回退切換很復(fù)雜。
• 我們開發(fā)了很多的后臺系統(tǒng)，但是賬戶沒有統(tǒng)一，每個子系統(tǒng)有各自的賬戶中心，運營和業(yè)務(wù)人員需要來回登錄才能完成日常工作，隨著業(yè)務(wù)量增大這個問題也日益突出。

于是又開啟調(diào)研、系統(tǒng)選型等，解決了上面三個問題：

• 第一個問題的解決方案是引入 SOA 服務(wù)治理，通過服務(wù)的注冊和發(fā)現(xiàn)解決系統(tǒng)之間的解耦，當時考察了很多，最后選型 dubbo，原因無它，有大量的群眾使用基礎(chǔ)，該趟的水都趟過了。
• 第二個問題的解決方案是引入配置中心，當時調(diào)研了 360 的Qihoo360/QConf、Spring 的 spring-cloud-config、淘寶的 diamond、還有百度的 disconf，最后糾結(jié)半天選定了 disconf，完美和 spring cloud 擦肩而過。

但是正是從這里開始讓我們注意到了 spring-cloud、Spring-boot 為第四代的架構(gòu)選型留下了伏筆，其實最后disconf也只是在少部分項目中使用，也沒完全推廣開。

• 解決第三個問題就是賬戶中心，使用 cas 實現(xiàn)了單點登錄，shiro 做權(quán)限控制，dubbo 來提供登錄后權(quán)限列表等服務(wù)端接口。

改造后的架構(gòu)圖如下：

在這個基礎(chǔ)上面，我們又抽離出來很多基礎(chǔ)組件，common 組件處理共用的基礎(chǔ)類，包含字符類、日期類、加密類….，搭建了 fastDFS 集群來處理文件系統(tǒng)，做了 redis 集群的測試。

單獨開發(fā)了定時調(diào)度系統(tǒng)，將所有的定時任務(wù)統(tǒng)一集成到調(diào)度系統(tǒng)，那個系統(tǒng)需要的定時任務(wù)都可以在頁面自動添加調(diào)度策略;前端 PHP 做了系統(tǒng)改造，主從分離、靜態(tài)優(yōu)化等。

在后來，公司又啟動了眾籌平臺的建設(shè)，這次系統(tǒng)完全采用 Java 語言開發(fā)，APP 端采用混合開發(fā)模式。

其中 APP 的所有一級頁面全部采用原生開發(fā)，所有的二級頁面都是 H5+vue 這種模式，后端全部采用 dubbo 做服務(wù)化，最終的架構(gòu)如下：

上圖里面系統(tǒng)只羅列了一部分，因為服務(wù)太多就用其它服務(wù)代表剩余的系統(tǒng)。

第三代系統(tǒng)啟動了 SOA 服務(wù)治理，引入了統(tǒng)一賬戶中心、基礎(chǔ)組件，缺點是開發(fā)環(huán)境較復(fù)雜。

第四代系統(tǒng)架構(gòu)

人總是不滿足，技術(shù)也總是希望可以使用最好的架構(gòu)體系，在第三代系統(tǒng)架構(gòu)的開發(fā)中，了解到了 spring cloud 和 spring boot，在不斷的學(xué)習(xí)之后，越發(fā)的感覺到 springboot 的便利性，對它快速開發(fā)的優(yōu)點甚是喜愛。

spring cloud 體系也完全滿足一個大型系統(tǒng)需要考慮的方方面面，微服務(wù)的概念不斷地被提出來，以上為技術(shù)背景。

另一方面國家開始嚴格要求 P2P 公司必須接入銀行存管，分析了銀行的相關(guān)接口后發(fā)現(xiàn)如果嚴格按照規(guī)則走，我們的系統(tǒng)需要大改造，同時公司為了滿足監(jiān)管要求，又開發(fā)出白條相關(guān)產(chǎn)品也是一個大項目。

趁著以上的兩個背景，我們決定在進行銀行存管和白條項目的同時全面擁抱微服務(wù)。

至于為什么我們要拋棄 dubbo 轉(zhuǎn)而全面擁抱 spring cloud 的原因有三：

• dubbo 多年都沒有更新了，spring cloud 不斷地在更新升級;
• dubbo 主要做服務(wù)治理和監(jiān)控，spring cloud 幾乎考慮了微服務(wù)所需要的方方面面，比如統(tǒng)一配置中心、路由中心;
• spring cloud 更是無侵并且完美和 spring 其他項目整合，開發(fā)效率更高。

既然選定了使用 spring boot+spring cloud 來改造，微服務(wù)技術(shù)選型這邊就定了下來，那么如何開啟改造呢?

畢竟在進行新一代系統(tǒng)改造的同時也不能影響原有業(yè)務(wù)，其中最主要的問題就是最初的系統(tǒng)雖然都是按照分布式的開發(fā)模式來進行。

由于老系統(tǒng)的原因，有的系統(tǒng)還是共用了一個數(shù)據(jù)庫，微服務(wù)要求每個獨立的子系統(tǒng)有自己獨立的庫操作，別的系統(tǒng)如果需要修改或者查詢子系統(tǒng)的數(shù)據(jù)，需要根據(jù)服務(wù)間接口調(diào)用來獲取。

因此計劃先從新開發(fā)的項目和需要改造的項目中啟用 springcloud 項目，別的系統(tǒng)暫時先通過路由器模式來通訊，最終的系統(tǒng)架構(gòu)圖如下：

結(jié)語

在架構(gòu)的這條路上，技術(shù)沒有終點，變化就是永遠的不變，架構(gòu)的升級更是為了更好的支撐業(yè)務(wù)，二者相輔相成。微服務(wù)化，動態(tài)化、自動化是未來金融機構(gòu)架構(gòu)的發(fā)展趨勢。