從零到百億互聯網金融架構發展史

回想起從公司成立敲出的第一行代碼算起到現在也快三年了，平台的技術架構，技術體系也算是經歷了四次比較重大的升級轉化（目前第四代架構體系正在進行中），臨近年底也想抽出時間來回顧一下，一個小公司從最開始的零交易到現在交易量超過百億背後的技術變遷。

總體介紹

在互聯網金融行業一百多億其實也算不上大平台，也就是二級陣營吧，其實每次的架構升級都是隨著業務重大推進而伴隨的，在前一代系統架構上遇到的問題，業務開發過程中積累一些優秀的開發案例，在下一代系統開發中就會大力推進架構升級。一方面可以平滑過度，一方面公司資源可以大力支持，同時技術的小夥伴們可以使用到前沿的技術，更有開發的成就感，就這樣我們大概也就是9個月就行系統架構一次升級，就到了我們現在的這套架構中。

很多網友經常會問，你們平台的TPS是多少呀，最大併發是多少呀，性能怎麼樣，說實話我們是一個小公司，最誇張也就上萬人同時搶標，但是做為一個中型的互聯網金融平台要做的事情也真的不少，遠遠不只是這些參數可以說的清楚；我們也不是什麼高大上的平台，使用的技術也是目前比較主流開源產品，但在公司不斷發展的過程中也遇到了很多的問題，也盡量去使用比較主流的、開源的、適合我們的一些解決方案來構建整個系統，在這裡分享平台發展背後技術換代的變化，同時希望和大家多做一些交流，多提一些建議。

我們進行了四次大的架構變化，每代架構都用一句話來總結：

• 第一代架構特點：業務比較集中、功能滿足投資理財需求、快速上線
• 第二代架構特點；分散式系統改造，平台化初具規模，各項垂直業務系統搭建上線、產品端極大豐富用戶投資、大數據平台研究並使用
• 第三代架構特點；SOA治理，使用zookeeper作為註冊中心，dubbo做監控和調度中心；cas實現單點登錄，使用shiro做許可權控制
• 第四代架構特點；全面啟用微服務開發模式，springboot+springcloud技術桟做為第四代架構技術支撐

下面做詳細介紹

第一代系統架構

2014年應該算是互聯網金融元年，在之前其實已經有很多互聯網公司用著各種模式在生存，一直不溫不火，但是到2014年突然火爆了起來，首先是網貸之家，網貸天眼這種第三方網站流量突然增加，接著是媒體報道不斷跟進，再後來就報出各種互聯網金融公司獲得XXX美元投資的報道越來越多，政策也慢慢明朗，於是很多大型公司（集團）也就趁著這股熱潮跟進，其中就包括我們。

第一代系統最主要就是搶時間，公司希望用最短的時間內保證系統上線，那時候移動浪潮已經啟動，於是決定優先上線移動端，網站可以暫不考慮。公司當時有PHP和Java兩種開發語言技術儲備，因為PHP在快速開發上面有著非常大的優勢，因此決定採用前端PHP+後端Java這種模式。系統分成了三層：用戶層：安卓和IOS移動端；介面層：php提供用戶和交易介面；後端：後端有兩部分，後台和定時系統。後台用PHP開發和介面層公用了一個系統，另一個是定時系統，負責計息、派息、到期等定時任務等使用了java開發。

基礎服務和中間件，mysql做了最基本的主從來支持，第一代系統只是使用了mysql的主庫，從庫只是同步備份；memcached用來處理用戶搶標的併發問題，也只用了這一塊；ActiveMQ用來使用二級市場的轉讓撮合以及其它一些非同步消息通知。項目部署：php使用apache部署，定時服務使用tomcat6來做應用伺服器，使用lvs來做前端apache的負載，基本上第一代也就這些技術了，下面是第一代系統的架構圖。

第一代系統上線之後，網站和H5(手機瀏覽器或者微信端)系統建設就變的特別突出，作為一個互聯網金融公司沒有官網不能忍，於是又開始馬不停蹄的開始開發網站和H5系統，在這個期間PHP之前做的後台這塊摘了出來，用java從新規劃了一版，至此PHP就負責了網站、APP介面、H5這三個系統，三個系統共用的一個核心交易，java這邊負責後台管理和定時服務，我們一般給這個架構叫做1.1代架構。

第1.1代系統架構圖，綠色部分為變動部分

第一代系統的缺點是業務過於集中，倉促上線，後期問題較多

第二代系統架構（架構師/大數據/馬士兵 489034603）

第二代系統的背景是隨著公司業務量的快速發展，很多初期所欠的技術債務統統爆發，線上出現了很多問題，最嚴重的一次是給個別用戶重複派息，各種被罵，現在記憶猶新。另一方各業務部門需求不斷，公司產品需求不斷，所以這個階段就是忙著修復各種生產問題，一邊還需要開發垂直業務系統。那段時間差點被逼瘋了，第一代系統是封閉開發，回來還沒緩過勁，這邊又趕馬上架，真是疼並快樂著。

第一個垂直子系統上線的是：合同系統，當時用戶投標后沒有一個合同，很多用戶很不放心，就把優先順序提到了前面。後來就單合同系統就改了三個版本，第一個版本只是生成pdf,第二階段上線電子簽章，第三個階段加水印，自定義動態生成pdf;緊接著開發積分系統：用戶邀請，投資等生產積分，用來兌換抵現卷等；抽離出消息系統：站內消息、簡訊、郵件等；上線監控系統、業務監控和服務監控，業務失敗預警；各業務部門繼續不斷提需求，上線財務系統：財務人員統計核算金額；風控系統：監控異常用戶，異常交易；給銷售開發了銷售系統；因為和很多第三方系統對接，又開發了對外接入系統。

一代系統做的很趕，產品界面又很爛，隨即啟動規劃了網站2.0、APP2.0、H52.0，針對前端系統的需求，在後端開發了CMS系統來發布項目、公司的公告新聞等；第二代產品端普遍規劃了很多大數據分析的一些需求，會在官網展示全量數據分析后投資偏好、投資的金額都跑到哪裡去，前端用地圖來展示，對於個人也會有還款日曆，代收數據分析等，因為需要跑全量數據，在規劃的時候都是設計離線來處理，將數據從mysql從庫同步到mongodb的集群中，利用mongdo的mapreduce技術來處理大量的數據，於是我們的資料庫層就變成下面的這個架構

mysql實時同步到mongodb，我們使用的是tungsten-relicator這個工具，會在mysql伺服器端啟動一個監控agent，實時監控mysql的binlog日誌，同時在mongodb的伺服器端也起了一個服務端，agent監控到數據變化後傳送給服務端，服務端解析后插入到mongodb集群中以達到實時同步的效果，如上圖，當初寫了一篇文章來介紹：大數據實踐-數據同步篇tungsten-relicator（mysql->mongo），其實這個工具在使用中，也不是特別的穩定，但是當初的選擇方案並不多，幸好後期慢慢的熟悉后算是穩定了下來。

數據清洗系統我們大膽的使用了golang來開發，當時使用的golang版本是1.3吧，現在都1.8了，以前也是沒有接觸過也是鍛煉了隊伍，好在golang語言本身非常簡潔和高效，雖然踩了N多坑，但是最終我們還是按時投產了；後來又使用了golang開發了一個後台，是在beego框架的基礎上來做的。大數據分析系統後來又升級了一代，在前端的各業務系統，UI用戶層做了很多埋點來收集用戶數據，通過activeMQ傳輸接收最後存儲到mongodb，在進行數據清洗，將清洗后的結果存入到結果庫中，供前端業務系統使用；後來利用beego+echart重新做了一版數據分析系統。

大數據系統的架構圖

因為後端資料庫的壓力不斷增大，後端管理系統、業務系統均作了主從分離；後台管理系統增加緩存，啟動了redis做緩存；使用nginx搭建了獨立的圖片伺服器；第二代系統開發過程中，也是公司發展最快的階段，上線了N多的活動。

第二代系統架構圖：

稍等總結一下：第二代架構上線了各業務系統，做了主從分離，搭建了大數據平台為以後更多的數據處理提供了技術基礎缺點：各業務系統切分之後，各項目之間調用複雜；後台系統繁多、各系統之間有單獨的賬戶系統，運營需要來回切換完成平台運營監控

第三代系統架構（架構師/大數據/馬士兵 489034603）

第二代系統開發完成之後，留給我們了三個問題很痛苦，第一個是隨著業務系統不斷增多，系統之間的調用關係成指數級別上漲，在第三代系統初期，我們又開發了很多基礎組件，更是加劇了這個問題；第二個問題和第一個問題相輔相成，系統之間調用關係太多，如果移動其中一個子系統，可能需要修改關聯繫統的配置文件，重新啟動服務，經常因為更新一個系統，其它系統也需要被動更新，投產和出問題切換很複雜；第三個問題是我們開發了很多的後台系統，但是賬戶沒有統一，每個子系統有各自的賬戶中心，運營和業務人員需要來回登錄才能完成日常工作，隨著業務量增大這個問題也日益突出。

於是又開啟調研、系統選型等，解決第一個問題就是引入SOA服務治理，通過服務的註冊和發現解決系統之間的解耦，當時考察了很多，最後選型dubbo，原因無它，有大量群眾使用基礎該趟的水的趟過了。解決第二個問題就是引入配置中心，當時調研了360的Qihoo360/QConf、Spring的spring-cloud-config、淘寶 的diamond、還有百度的disconf，最後糾結半天選定了disconf，完美和spring cloud擦肩而過，但是正是從這裡開始讓我們注意到了spring-cloud、Spring-boot為第四代的架構選型做了基礎，其實最後disconf也只是在少部分項目使用，也沒完全推廣開；解決第三個問題就是賬戶中心，使用了cas實現單點登錄，shiro做許可權控制，dubbo來提供登錄后許可權列表等服務端介面。

改造后的架構圖

在這個基礎上面，我們又抽離出來很多基礎組件，comomn組件處理共用的基礎類，包含字元類、日期類、加密類….，搭建了fastDFS集群來處理文件系統，做了redis集群的測試；單獨開發了定時調度系統，將所有的定時任務統一集成到調度系統，那個系統需要定時任務都可以在頁面自動添加調度策略；前端PHP做了系統改造，主從分離、靜態優化等

在後來，公司又啟動眾籌平台的建設，這次系統完全採用java語言開發，app端採用混合開發模式，其中APP的所有一級頁面全部採用原生開發，所有的二級頁面都是H5+vue這種模式，後端全部採用dubbo做服務化，最終的架構如下：

圖裡面系統只羅列一部分，使用其它服務來代替

第三代系統啟動了SOA服務治理，引入統一賬戶中心、基礎組件；缺點是開發環境較複雜

第四代系統架構

人總是不滿足，技術呢也總是希望可以使用最好架構體系，在三代系統架構的開發中，了解到了spring cloud和spring boot，在不斷的學習之後，越發的感覺到springboot的便利性，快速開發的優點甚是喜愛，spring cloud體系也完全滿足一個大型系統需要考慮的方方面面，微服務的概念不斷的被提出來，以上為技術背景；另一方面國家開始嚴格要求P2P公司必須與銀行存管，分析了銀行的相關介面后發現如果嚴格按照規則走，我們的系統需要大改造，同時公司為了滿足監管要求，又開發出白條相關產品也是一個大項目，趁著以上的兩個背景，我們決定在進行銀行存管和白條項目的同時全面擁抱微服務。

至於為什麼我們要拋棄dubbo轉而全面擁抱spring cloud原因有三，1、dubbo多年都沒有更新了，spring cloud不斷的在更新升級；2、dubbo主要做服務治理和監控，spring cloud幾乎考慮了微服務所需要方方面面，比如統一配置中心、路由中心；3、spring cloud更是無侵併且完美和spring其它項目整合，開發效率更高。

既然選定了使用spring boot+spring cloud來改造，微服務技術選型這邊就定了下來，那麼如何開啟改造呢，畢竟在進行新一代系統改造的同時也不能影響原有業務，其中最主要的問題就是最初的系統雖然都是按照分散式的開發模式來進行，由於老系統的原因有的系統還是共用了一個資料庫，微服務要求每個獨立的子系統有自己獨立的庫操作，別的系統如果需要修改或者查詢子系統的數據，需要根據服務間介面調用來獲取。因此計劃先從新開發的項目和需要改造的項目中啟用springcloud項目，別的系統暫時先通過路由器模式來通訊，最終的系統架構圖如下：

在架構的這條路上面沒有終點，變化就是永遠的不變，架構的升級更是為了更好的支撐業務，二者相輔相成。