宜人貸系統架構

宜人貸系統版本的迭代

1.0 版本——簡單的煩惱

1.PNG

迭代以前宜人貸的系統，其實就是一個前臺，一個後臺，一個 DB ，前臺採用的是多機部署的方式。軟件層也是跟最傳統的軟件同樣分三層，第一層是 Controller ，第二層是 Service ，第三層是 DAO 。顯然這個系統並不適合互聯網，有一些難以免的問題。首先當用戶過萬，在線用戶上千的時候，這樣的部署方式會產生一些瓶頸，包括服務器和數據庫兩方面。第二個就是團隊規模變大，全部開發人員集中開發同一個系統，衝突嚴重。

1.5 版本——「吃大補」試試！

針對上面的問題咱們作了一些修改，我把它定義成「吃大補」。吃大補一般有一個很明顯的特色，就是立馬見效，可是反作用也很大。

2.PNG

首先，咱們在宜人貸的頁面層更加關注性能的提高，好比說使用瀏覽器緩存，壓縮傳輸，頁面都通過了 YSlow 的優化，鏈路層增長了 CDN ，作了靜態化甚至反向代理，這樣能夠抵擋 80% 的流量。應用服務器與數據庫層增長了一個緩存集羣，這個緩存集羣基本上又能夠擋掉 80% 流量，最後系統層按照業務垂直拆分紅多個系統。數據庫也有一些變化，開始只是一臺主機，一臺數據庫，如今變成了主從，甚至一主多從。用戶能夠撐到過百萬，在線用戶上萬。即使如此，咱們的制約因素依然在數據庫，優化的兩層雖然擋掉了大約 95% 的流量，可是業務發展依然超過了數據庫所能承受的負載，因此數據庫依然是一個很大的瓶頸。

第二個問題就是團隊劃分，其實每一個團隊都作本身的系統，可是你們仍然使用同一個數據庫，這個時候對於設計和修改數據庫，都很是麻煩。甚至每次都要問一下其餘團隊，我這麼改行不行，對你有什麼影響等等。

第三個問題也很是棘手，大量使用了緩存，數據的時效性和一致性的問題愈來愈嚴重。

2.0 版本——「開小竈」精細化

爲了解決 1.5 版本存在的問題，咱們須要作精細化的優化，我把它定義成開小竈。首先，合理規劃數據歸屬、優化查詢效率、縮短數據庫事務時間；其次，分系統，每一個系統用固定的表。咱們天天都要作的事，就是讓運維找出線上最慢的SQL有哪些，對它們作優化。第三，作去事務，或者儘量地縮短事務的時間。

而後開始關注代碼質量，提升執行效率，而且開始關注併發問題。用戶達到這個量的時候，就會有用戶幫咱們測試併發問題。舉一個例子，同一個用戶用同一個賬戶登陸了兩個客戶端，他同時點取現，這個時候若是程序處理的很差，頗有可能讓他提現兩次。

最後，要區分強一致性與最終一致性的請求，合理使用緩存與讀寫分離來解決這些問題。

2.0 解決了不少性能問題，但仍是會有新的問題——系統愈來愈多，系統間依賴關係變得複雜，這個時候很容易出現 A 調 B ， B 調 C ， C 再調回 A 的循環調用。第二個是系統間互相調用增多，上游系統壓垮下游系統；第三個也是很是頭疼的問題，系統不少，查找線上問題變得愈來愈困難——試想一下多個系統部署到不少機器上，想找一個線上的問題，經過日誌的形式會很是難查。

因此在這個基礎上咱們作了幾件事。一是限流。限流一般基於兩點：最大活動線程數和每秒運行次數；活動最大線程數適合於高消耗的任務，每秒運行次數適合於低消耗的任務。第二，我建議在這個時期儘量統一內部系統間的返回值，返回值中必定要記錄返回狀態（業務正常、業務異常、程序異常）和錯誤說明；第三，可重用RPC框架或在原框架基礎上繼續開發完成限流工做。

3.PNG

再說一下關於查找日誌的問題。圖中爲宜人貸日誌系統部署框架，最左側的是咱們的業務系統，在業務系統上把日誌收集到 Kafka 隊列，而後把 Kafka 隊列日誌放到 ES 集羣作索引，最終採用 Kibana 和咱們本身研發的日誌查詢系統去查看日誌，這樣日誌被集中到一個點後會更便於查找。

關於軟件方面，宜人貸統一使用 SLF4J+Logback 來輸出日誌，而後業務系統間實現日誌串聯，全部服務端和客戶端之間都隱含地傳遞一些參數，這些參數會隨着調用鏈一步一步往下傳，經過 AOP 來實現。日誌串聯須要傳遞哪些參數，或者日誌中到底要打哪些參數呢？第一個是時間，這個時間應該到毫秒級，第二個是流水號，流水號就是每次請求生成的一個惟一的值。而後是用戶 Session 、設備號、調用者時間（ APP 使用手機本地時間）、本機 IP 、客戶端 IP 、用戶真實 IP 、跨越系統次數——若是咱們發現了一個錯誤，根據錯誤日誌能夠找到流水號，再經過流水號能夠到日誌查詢平臺查詢出此次請求途徑的全部系統和每一個系統對此次請求的日誌。有了這些找問題就很是容易。

作到 2.0 以後，宜人貸的網站基本能支撐中大型網站的規模，短期內不會有太多的性能問題了，可是咱們依然會繼續往下走，進一步提高系統版本。

3.0 版本——拆分作服務化

3.0 總結下來就是要作服務化，通俗一點說就是拆分，包括業務上的垂直拆分，以及垂直拆分基礎上的系統之上的水平拆分，那麼服務化要怎麼作呢？

首先，作業務拆分的時候，能夠按照基礎服務和業務服務先作一個大的服務拆分，而後基礎服務又包括無業務型的基礎服務和有業務型的基礎服務，無業務型的系統很是明顯跟其餘的系統沒有太大的關係。而業務型基礎服務跟業務之間的關係很小，基本上跟業務系統之間的關聯關係僅限於主鍵和外鍵的關聯關係。

5.PNG

宜人貸能夠自然地拆卸分紅兩大系統，一個是借款業務，一個是理財業務，借款業務能夠拆分紅後臺、 Web 、合做渠道等，這個系統之下會有一個基礎服務，就是提供一些基礎服務和接口的一層系統。而基礎服務又拆成了兩部分，一個是基礎服務的進件，一個是基礎服務的貸後。在拆分過程當中咱們又發現一個問題，理財和借款有兩個業務怎麼拆都拆不開，就是撮合業務和債券關係，這種拆不開的能夠單獨再提成一個系統來提供服務。

666.jpg

拆分系統看起來好像很容易，可是實際操做問題會不少。拆分的辦法我總結了以下幾個：

第一，適當冗餘，冗餘能夠確保數據庫依然能夠進行關聯查詢。大部分重構過程並非作一個全新的系統，而是在原來系統之上進行修改，這個時候能夠作一些冗餘，避免修改代碼。

第二，數據複製，但必須保證數據歸屬系統有修改和發起複製的權限。這個比較適合於上文說的全局配置，好比說基本上全部公司都會有幾張表，記錄了全國的省市區縣，這些在每一個系統中都會用，不必定每一個系統都以接口的形式調用它，能夠在每一個系統裏面都冗餘一份數據。

第三，小技巧——如何驗證數據庫，並不必定非把它拆分紅兩個物理的數據庫來驗證，能夠一個數據庫上建兩個賬號，這兩個賬號分別的權限指向拆分以後的表，這樣就能夠經過賬號來直接驗證拆分效果。

第四，提早規劃服務，拆分以前肯定一下服務類型是讀多仍是寫多的服務，是快請求仍是慢請求服務，不一樣服務須要分開部署。

最後，同一數據不能由超過一個以上的系統控制，同一系統不能由超過一個以上的團隊負責。

4.0 版本——雲的展望

作到以上幾點， 3.0 版本已經作的差很少了，可是後面宜人貸依然還有不少要作的，4.0 版本是否是要作雲平臺，異地部署的方案，表很大的時候是否是要作垂直拆分，去 IOE 或者使用 Docker 快速部署等等這些，這些其實都是咱們作 4.0 或者 5.0 未來要考慮的事情。

宜人貸理財系統的優化

合理預估流量——強一致與最終一致

圖中這三個界面分別爲首頁、列頁，詳情頁。

6.5.PNG

在作優化以前，首先要合理預估流量，經常使用方法有下面兩個。

評估方法一：平日 PV / 熱度時間；

評估方法二：熱度時間內在線用戶數 平均每人操做次數/熱度時間。以宜人貸理財端爲例，假設在高峯時期有 N 萬人，而後平均作 M 次操做，在R分鐘左右基本上就把全部的債券搶光，計算出來大概是 N M / R 萬次 / 秒。

預估完之後要作更細的預估，區分什麼是強一致，什麼是最終一致，這兩個流量分別是多少。強一致性要求請求的數據必須是當時最準確的數據，這個數據不能用讀寫分離或緩存。最終一致性的數據時效性沒有那麼高，只要最後的結果是正確的就能夠。

假設這 M 次操做包含：註冊、註冊驗證碼、登陸、解鎖手勢密碼、首頁、瀏覽產品列表等等這些操做，這裏面其中有一些操做，好比說產品餘額、生成訂單、支付短信、付款，這些都是強一致的要求。

針對最終一致的方案很是簡單，增長機器就能夠解決，實時性較高的能夠直接使用數據庫的讀寫分離，若是使用 cache 的話，能夠縮短 cache 時間；實時性較低的應當使用較長時間的 cache 。

7.PNG

強一致性的流量處理方案，總的來講就是加鎖，可使用數據庫的鎖，也可使用 ZK （ Zookeeper ）這樣的分佈式鎖，或者直接使用隊列，由於隊列總得來講也是一種鎖。若是使用數據庫的鎖，基本上能夠支持到併發在 2000 次每秒上下。使用數據庫的鎖來處理併發，第一個方法就是有事務的處理併發。先開啓事務，加鎖共享資源，而後再更新共享資源，最後再查詢一次共享資源，而後判斷一下結果。假如說這個結果是成立的，就直接繼續執行，假如說這個結果是不成立的，直接回滾事務。第二個方法就是無事務的處理併發，在數據庫 SQL 的 where 條件加上判斷條件，若是 update 條數爲 1 則更新成功，若是爲 0 則更新失敗，這時須要用寫代碼的形式回滾數據。

若是流量依然承受不住該怎麼辦？

作到這些其實已經可以承受很是大的流量，可是業務可能繼續發展，還承受不住怎麼辦呢？

首先的一個原則就是，沒有任何一個分佈式算法適合併發操做，最好的方法就是單點並排隊進行處理。

第二，單點併發過大，使用合適的方式拆分鎖的粒度。

第三，增長降級需求，不影響用戶正常使用狀況下能夠適當下降服務質量。適當修改需求、適當增長用戶等待結果的時間；若是讓用戶多等一倍的時間，可能就能承受以前兩倍的併發，這個能夠在交互上優化，讓用戶有更好的體驗。

最後，適當調整運營策略，分散用戶的集中活躍時間。

 

文／數人云（簡書做者） 原文連接：http://www.jianshu.com/p/410250e006cb 著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。