從零到百億網際網路金融架構發展史

純潔的微笑發表於2017-01-13

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

總體介紹

在網際網路金融行業一百多億其實也算不上大平臺，也就是二級陣營吧，其實每次的架構升級都是隨著業務重大推進而伴隨的，在前一代系統架構上遇到的問題，業務開發過程中積累一些優秀的開發案例，在下一代系統開發中就會大力推進架構升級。一方面可以平滑過度，一方面公司資源可以大力支援，同時技術的小夥伴們可以使用到前沿的技術，更有開發的成就感，就這樣我們大概也就是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代系統架構圖，綠色部分為變動部分

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

第二代系統架構

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

第一個垂直子系統上線的是：合同系統，當時使用者投標後沒有一個合同，很多使用者很不放心，就把優先順序提到了前面。後來就單合同系統就改了三個版本，第一個版本只是生成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多的活動。

第二代系統架構圖：

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

第三代系統架構

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

於是又開啟調研、系統選型等，解決第一個問題就是引入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專案，別的系統暫時先通過路由器模式來通訊，最終的系統架構圖如下：