429
互聯網金融架構如何升級蝶變，才能實現百億級的跨越？
回想起從公司成立敲出的第一行代碼算起到現在也快三年了，平台的技術架構，技術體係也算是經曆了四次比較重大的升級轉化（目前第四代架構體係正在進行中），臨近年底也想抽出時間來回顧一下，一個小公司從最開始的零交易到現在交易量超過百億背後的技術變遷。
總體介紹
在互聯網金融行業一百多億其實也算不上大平台，也就是二級陣營吧，其實每次的架構升級都是隨著業務重大推進而伴隨的，在前一代係統架構上遇到的問題，業務開發過程中積累一些優秀的開發案例，在下一代係統開發中就會大力推進架構升級。一方麵可以平滑過度，一方麵公司資源可以大力支持，同時技術的小夥伴們可以使用到前沿的技術，更有開發的成就感，就這樣我們大概也就是9個月就行係統架構一次升級，就到了我們現在的這套架構中。
很多網友經常會問，你們平台的TPS是多少呀，最大並發是多少呀，性能怎麼樣，說實話我們是一個小公司，最誇張也就上萬人同時搶標，但是做為一個中型的互聯網金融平台要做的事情也真的不少，遠遠不隻是這些參數可以說的清楚；我們也不是什麼高大上的平台，使用的技術也是目前比較主流開源產品，但在公司不斷發展的過程中也遇到了很多的問題，也盡量去使用比較主流的、開源的、適合我們的一些解決方案來構建整個係統，在這裏分享平台發展背後技術換代的變化，同時希望和大家多做一些交流，多提一些建議。
我們進行了四次大的架構變化，每代架構都用一句話來總結：
-
第一代架構特點：業務比較集中、功能滿足投資理財需求、快速上線；
-
第二代架構特點；分布式係統改造，平台化初具規模，各項垂直業務係統搭建上線、產品端極大豐富用戶投資、大數據平台研究並使用；
-
第三代架構特點；SOA治理，使用Zookeeper作為注冊中心，dubbo做監控和調度中心；cas實現單點登錄，使用shiro做權限控製；
-
第四代架構特點；全麵啟用微服務開發模式，Spring Boot+Spring cloud技術桟做為第四代架構技術支撐。
下麵做詳細介紹。
第一代係統架構
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的集群中，利用MongoDB的MapReduce技術來處理大量的數據，於是我們的數據庫層就變成下麵的這個架構：
MySQL實時同步到MongoDB，我們使用的是tungsten-relicator這個工具，會在MySQL服務器端啟動一個監控Agent，實時監控MySQL的binlog日誌，同時在MongoDB的服務器端也起了一個服務端，Agent監控到數據變化後傳送給服務端，服務端解析後插入到MongoDB集群中以達到實時同步的效果，如上圖。
當初寫了一篇文章來介紹：《大數據實踐-數據同步篇tungsten-relicator（MySQL->mongo）》（https://www.cnblogs.com/ityouknow/p/4918164.html），其實這個工具在使用中，也不是特別的穩定，但是當初的選擇方案並不多，幸好後期慢慢地熟悉後算是穩定了下來。
數據清洗係統我們大膽的使用了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，在不斷的學習之後，越發的感覺到Spring Boot的便利性，快速開發的優點甚是喜愛，Spring Cloud體係也完全滿足一個大型係統需要考慮的方方麵麵，微服務的概念不斷的被提出來，以上為技術背景；另一方麵國家開始嚴格要求P2P公司必須與銀行存管，分析了銀行的相關接口後發現如果嚴格按照規則走，我們的係統需要大改造，同時公司為了滿足監管要求，又開發出白條相關產品也是一個大項目，趁著以上的兩個背景，我們決定在進行銀行存管和白條項目的同時全麵擁抱微服務。
至於為什麼我們要拋棄dubbo轉而全麵擁抱Spring Cloud原因有三：
-
dubbo多年都沒有更新了，Spring Cloud不斷地在更新升級；
-
dubbo主要做服務治理和監控，Spring Cloud幾乎考慮了微服務所需要方方麵麵，比如統一配置中心、路由中心；
-
Spring Cloud更是無侵並且完美和spring其它項目整合，開發效率更高。
既然選定了使用Spring Boot+Spring Cloud來改造，微服務技術選型這邊就定了下來，那麼如何開啟改造呢，畢竟在進行新一代係統改造的同時也不能影響原有業務，其中最主要的問題就是最初的係統雖然都是按照分布式的開發模式來進行，由於老係統的原因有的係統還是共用了一個數據庫，微服務要求每個獨立的子係統有自己獨立的庫操作，別的係統如果需要修改或者查詢子係統的數據，需要根據服務間接口調用來獲取。因此計劃先從新開發的項目和需要改造的項目中啟用springcloud項目，別的係統暫時先通過路由器模式來通訊，最終的係統架構圖如下：
在架構的這條路上麵沒有終點，變化就是永遠的不變，架構的升級更是為了更好的支撐業務，二者相輔相成。
開源軟件
在這幾年中我們也想對開源世界做一點點貢獻，總共開源了兩個軟件：
generator-web
在項目中大量使用了mybaits，我們對mybaits的generator做了改造，並且做了一個係統界麵，方便根據相關參數自動生產相關代碼（隻需要設計好表結構，係統會自動生成mappper、Entity、dao層的代碼），最後也開源了出來。
https://github.com/zhongxintech/generator-web
favorites-web
為了鍛煉技術學習Spring Boot我們開發了一個雲收藏的開源軟件，使用的技術主要是Spring Boot/Spring Data jpa/Redis/thymeleaf/gradle，功能主要是可以幫助用戶在雲端收藏、分享和整理自己的收藏夾。
原文發布時間為：2017-01-17
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-15 17:32:30