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

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

在互聯(lián)網(wǎng)金融行業(yè)一百多億其實也算不上大平臺，也就是二級陣營吧，其實每次的架構(gòu)升級都是隨著業(yè)務重大推進而伴隨的，在前一代系統(tǒng)架構(gòu)上遇到的問題，業(yè)務開發(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è)務比較集中、功能滿足投資理財需求、快速上線

第二代架構(gòu)特點；分布式系統(tǒng)改造，平臺化初具規(guī)模，各項垂直業(yè)務系統(tǒng)搭建上線、產(chǎn)品端極大豐富用戶投資、大數(shù)據(jù)平臺研究并使用

第三代架構(gòu)特點；SOA治理，使用zookeeper作為注冊中心，dubbo做監(jiān)控和調(diào)度中心；cas實現(xiàn)單點登錄，使用shiro做權(quán)限控制

第四代架構(gòu)特點；全面啟用微服務開發(fā)模式，springboot+springcloud技術(shù)桟做為第四代架構(gòu)技術(shù)支撐

下面做詳細介紹

2014年應該算是互聯(lián)網(wǎng)金融元年，在之前其實已經(jīng)有很多互聯(lián)網(wǎng)公司用著各種模式在生存，一直不溫不火，但是到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)，負責計息、派息、到期等定時任務等使用了java開發(fā)。

基礎(chǔ)服務和中間件，mysql做了最基本的主從來支持，第一代系統(tǒng)只是使用了mysql的主庫，從庫只是同步備份；memcached用來處理用戶搶標的并發(fā)問題，也只用了這一塊；ActiveMQ用來使用二級市場的轉(zhuǎn)讓撮合以及其它一些異步消息通知。項目部署：php使用apache部署，定時服務使用tomcat6來做應用服務器，使用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這邊負責后臺管理和定時服務，我們一般給這個架構(gòu)叫做1.1代架構(gòu)。

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

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

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

第一個垂直子系統(tǒng)上線的是：合同系統(tǒng)，當時用戶投標后沒有一個合同，很多用戶很不放心，就把優(yōu)先級提到了前面。后來就單合同系統(tǒng)就改了三個版本，第一個版本只是生成pdf,第二階段上線電子簽章，第三個階段加水印，自定義動態(tài)生成pdf;緊接著開發(fā)積分系統(tǒng)：用戶邀請，投資等生產(chǎn)積分，用來兌換抵現(xiàn)卷等；抽離出消息系統(tǒng)：站內(nèi)消息、短信、郵件等；上線監(jiān)控系統(tǒng)、業(yè)務監(jiān)控和服務監(jiān)控，業(yè)務失敗預警；各業(yè)務部門繼續(xù)不斷提需求，上線財務系統(tǒng)：財務人員統(tǒng)計核算金額；風控系統(tǒng)：監(jiān)控異常用戶，異常交易；給銷售開發(fā)了銷售系統(tǒng)；因為和很多第三方系統(tǒng)對接，又開發(fā)了對外接入系統(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服務器端啟動一個監(jiān)控agent，實時監(jiān)控mysql的binlog日志，同時在mongodb的服務器端也起了一個服務端，agent監(jiān)控到數(shù)據(jù)變化后傳送給服務端，服務端解析后插入到mongodb集群中以達到實時同步的效果，如上圖，當初寫了一篇文章來介紹：大數(shù)據(jù)實踐-數(shù)據(jù)同步篇tungsten-relicator（mysql->mongo），其實這個工具在使用中，也不是特別的穩(wěn)定，但是當初的選擇方案并不多，幸好后期慢慢的熟悉后算是穩(wěn)定了下來。

數(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è)務系統(tǒng)，UI用戶層做了很多埋點來收集用戶數(shù)據(jù)，通過activeMQ傳輸接收最后存儲到mongodb，在進行數(shù)據(jù)清洗，將清洗后的結(jié)果存入到結(jié)果庫中，供前端業(yè)務系統(tǒng)使用；后來利用beego+echart重新做了一版數(shù)據(jù)分析系統(tǒng)。

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

因為后端數(shù)據(jù)庫的壓力不斷增大，后端管理系統(tǒng)、業(yè)務系統(tǒng)均作了主從分離；后臺管理系統(tǒng)增加緩存，啟動了redis做緩存；使用nginx搭建了獨立的圖片服務器；第二代系統(tǒng)開發(fā)過程中，也是公司發(fā)展最快的階段，上線了N多的活動。

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

稍等總結(jié)一下：
第二代架構(gòu)上線了各業(yè)務系統(tǒng)，做了主從分離，搭建了大數(shù)據(jù)平臺為以后更多的數(shù)據(jù)處理提供了技術(shù)基礎(chǔ)
缺點：各業(yè)務系統(tǒng)切分之后，各項目之間調(diào)用復雜；后臺系統(tǒng)繁多、各系統(tǒng)之間有多帶帶的賬戶系統(tǒng)，運營需要來回切換完成平臺運營監(jiān)控

第二代系統(tǒng)開發(fā)完成之后，留給我們了三個問題很痛苦，第一個是隨著業(yè)務系統(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)的配置文件，重新啟動服務，經(jīng)常因為更新一個系統(tǒng)，其它系統(tǒng)也需要被動更新，投產(chǎn)和出問題切換很復雜；第三個問題是我們開發(fā)了很多的后臺系統(tǒng)，但是賬戶沒有統(tǒng)一，每個子系統(tǒng)有各自的賬戶中心，運營和業(yè)務人員需要來回登錄才能完成日常工作，隨著業(yè)務量增大這個問題也日益突出。

于是又開啟調(diào)研、系統(tǒng)選型等，解決第一個問題就是引入SOA服務治理，通過服務的注冊和發(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)選型做了基礎(chǔ)，其實最后disconf也只是在少部分項目使用，也沒完全推廣開；解決第三個問題就是賬戶中心，使用了cas實現(xiàn)單點登錄，shiro做權(quán)限控制，dubbo來提供登錄后權(quán)限列表等服務端接口。

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

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

在后來，公司又啟動眾籌平臺的建設(shè)，這次系統(tǒng)完全采用java語言開發(fā)，app端采用混合開發(fā)模式，其中APP的所有一級頁面全部采用原生開發(fā)，所有的二級頁面都是H5+vue這種模式，后端全部采用dubbo做服務化，最終的架構(gòu)如下：

圖里面系統(tǒng)只羅列一部分，使用其它服務來代替

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

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

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

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

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

在這幾年中我們也想對開源世界做一點點貢獻，總共開源了兩個軟件：

generator-web

在項目中大量使用了mybaits，我們對mybaits的generator做了改造，并且做了一個系統(tǒng)界面，方便根據(jù)相關(guān)參數(shù)自動生產(chǎn)相關(guān)代碼（只需要設(shè)計好表結(jié)構(gòu)，系統(tǒng)會自動生成mappper、Entity、dao層的代碼），最后也開源了出來

generator-web

界面如下：

云收藏

為了鍛煉技術(shù)學習springboot我們開發(fā)了一個云收藏的開源軟件，使用的技術(shù)主要是springboot/Spring data jpa/redis/thymeleaf/gradle，功能主要是可以幫助用戶在云端收藏、分享和整理自己的收藏夾。

favorites-web

作者：純潔的微笑
出處：http://www.ityouknow.com/
版權(quán)所有，歡迎保留原文鏈接進行轉(zhuǎn)載：)