高效程序員如何優雅落地需求

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

 

整體介紹

在互聯網金融行業一百多億其實也算不上大平臺，也就是二級陣營吧，其實每次的架構升級都是隨着業務重大推動而伴隨的，在前一代系統架構上遇到的問題，業務開發過程當中積累一些優秀的開發案例，在下一代系統開發中就會大力推動架構升級。一方面能夠平滑過分，一方面公司資源能夠大力支持，同時技術的小夥伴們可使用到前沿的技術，更有開發的成就感，就這樣咱們大概也就是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緣由有三，一、dubbo多年都沒有更新了，spring cloud不斷的在更新升級；二、dubbo主要作服務治理和監控，spring cloud幾乎考慮了微服務所須要方方面面，好比統一配置中心、路由中心；三、spring cloud更是無侵而且完美和spring其它項目整合，開發效率更高。

 

既然選定了使用spring boot+spring cloud來改造，微服務技術選型這邊就定了下來，那麼如何開啓改造呢，畢竟在進行新一代系統改造的同時也不能影響原有業務，其中最主要的問題就是最初的系統雖然都是按照分佈式的開發模式來進行，因爲老系統的緣由有的系統仍是共用了一個數據庫，微服務要求每一個獨立的子系統有本身獨立的庫操做，別的系統若是須要修改或者查詢子系統的數據，須要根據服務間接口調用來獲取。所以計劃先重新開發的項目和須要改造的項目中啓用springcloud項目，別的系統暫時先經過路由器模式來通信，最終的系統架構圖以下：

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

上面所涉及到的技術不是靠幾句話就能講清楚，不少問題其實答案很簡單，可是背後的思考和邏輯不簡單，要作到知其然還要知其因此然。所以在這裏給你們推薦一個交流平臺：架構交流學習羣650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，如下的課程體系圖也是在羣裏獲取。

 

注：加入要求

一、具備必定工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。

二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。

四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！

6.小號或者小白之類加羣一概不給過，謝謝。