[[196273]]

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

[[196274]]

在互聯網金融行業一百多億算不上大平臺，也就是個二級陣營，它每次的架構升級都是伴隨著業務的重大變化而推進的，在前一代系統架構上遇到的問題，業務開發過程中就會積累一些優秀的開發案例，在下一代系統開發中就會大力推進架構升級。

一方面可以平滑過度，另一方面公司資源可以大力支持，同時技術團隊可以使用到前沿的技術，更有開發的成就感，我們大概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 集群中以達到實時同步的效果。

數據清洗系統，我們大膽使用了 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 來提供登錄后權限列表等服務端接口。

改造后的架構圖如下：

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

單獨開發了定時調度系統，將所有的定時任務統一集成到調度系統，那個系統需要的定時任務都可以在頁面自動添加調度策略;前端 PHP 做了系統改造，主從分離、靜態優化等。

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

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

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

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

第四代系統架構

人總是不滿足，技術也總是希望可以使用最好的架構體系，在第三代系統架構的開發中，了解到了 spring cloud 和 spring boot，在不斷的學習之后，越發的感覺到 springboot 的便利性，對它快速開發的優點甚是喜愛。

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

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

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

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

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

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

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

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

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

結語

在架構的這條路上，技術沒有終點，變化就是永遠的不變，架構的升級更是為了更好的支撐業務，二者相輔相成。微服務化，動態化、自動化是未來金融機構架構的發展趨勢。