孢子框架-互聯網金融平臺微服務架構設計(轉)

很是感謝http://www.cnblogs.com/skyblog/p/4915383.html

 

對互聯網金融理財平臺進行微服務架構設計。假設咱們設計的目標是5年後的陸金所（https://www.lu.com/）。陸金所簡介，平安集團旗下理財平臺，是中國最大的網絡投融資平臺之一，2011年9月在上海註冊成立，註冊資本金8.37億元，lufax結合全球金融發展與互聯網技術創新，在健全的風險管控體系基礎上，爲中小企業及我的客戶提供專業、可信賴的投融資服務，幫助他們實現財富增值。截至2014年1月末，註冊用戶已逾570萬。

l 需求分析

參照陸金所，得到以下核心需求矩陣。

分類	功能	質量	約束
前端用戶首頁及其它	產品展現	及時響應、搜索引擎優化
	本週特推	及時響應、搜索引擎優化	根據用戶特性推薦
	廣告圖片	及時響應、搜索引擎優化	可隨時更換
	公告	及時響應、搜索引擎優化	可隨時發佈
	幫助中心	及時響應、搜索引擎優化	可隨時發佈
	上證指數顯示	及時響應	實時同步上證指數
	促銷活動	及時響應、搜索引擎優化	可隨時發佈
	媒體報道	及時響應、搜索引擎優化	可隨時發佈
	常見問題	及時響應、搜索引擎優化	可隨時發佈
	產品搜索	及時響應、搜索引擎優化
	投資某產品	及時響應、安全性、可靠性	多種投資品種，某些品種投資流程不同
	登陸、註冊	及時響應、安全性	符合國家安全等級標準
分類	功能	質量	約束
前端用戶會員中心	帳戶總覽	及時響應、安全性
	個人投資	及時響應、安全性
	個人借款	及時響應、安全性
	資金記錄	及時響應、安全性
	充值、取現	及時響應、安全性、可靠性
	帳戶安全設置	及時響應、安全性
	個人陸金幣	及時響應、安全性
	個人商品	及時響應、安全性
	個人消息	及時響應、安全性
	推薦好友	及時響應、安全性

 

分類	功能	質量	約束
前端用戶會員俱樂部	商品推薦	及時響應、搜索引擎優化	可隨時設置規則，自動推薦商品
	商品詳情	及時響應、搜索引擎優化
	購買商品	及時響應、安全性、可靠性
	秒殺購買商品	及時響應、安全性、可靠性
	活動類推薦	及時響應、搜索引擎優化
	活動類詳情	及時響應、搜索引擎優化
	活動類玩法	及時響應、搜索引擎優化	目前包括：刮刮樂、抽獎、競猜、競拍
	商品、活動搜索	及時響應、搜索引擎優化
	新手指南	及時響應、搜索引擎優化	可隨時更新
	登陸	及時響應、搜索引擎優化、安全性	會員登陸後免登錄
分類	功能	質量	約束
後臺運維業務需求	系統管理	及時響應
	不一樣產品的運維管理	及時響應、可擴展性
	不一樣產品的發佈管理	及時響應、可擴展性
	新聞及公告發布	及時響應
	統計及報表	及時響應

 

　　宏觀上講，陸金所的運營目標是要打造一個互聯網金融理財平臺。目前產品包括：穩盈-安e、穩盈-變現通、穩盈-鑫保、安盈-票據、點金計劃、大數金融等P2P理財產品，包括信託理財、粵股交等專享理財產品，還包括1000多隻基金，以及零活寶、保險理財等投資理財產品。全部理財對於前端用戶來講目的和操做只有一個，那就是投資，而後獲取收益。從需求分析來看，互聯網金融理財平臺能夠看作是一個金融類的電子商務網站，用戶在其上選擇產品並投資，這和傳統電子商務選擇產品進行購買操做相似。

       上面的需求我簡化了後臺運維功能的需求，一方面我不是陸金所的開發人員，也不知道他們具體有哪些需求。另一方面，金融產品後臺運維管理及其複雜，由於涉及到錢，咱們也很差去猜，因此就給出了幾個簡化的大項後臺功能需求。 

l 系統分析

       要將需求進行系統分析，還須要有企業的運營目標作支持。咱們假設陸金所5年後運營目標是：

       產品方面：繼續上線當前沒有的理財產品（好比期貨、現貨投資）

       註冊人數：達到3000萬

       年營業額：達到1000億

       網站日訪問量：3000萬PV

       產品購買併發：1000 QPS

那麼咱們按照上面的需求，進行系統分析，首先按大的職責將職責相同的劃分爲一個服務。而且有了上面這個經營目標，全部功能需求都須要增長一項「質量」特性，那就是「高併發」，高併發會影響到全部設計。若是隻有幾個用戶在使用整個系統，那麼顯而易見一個應用，也不須要什麼微服務，一個web服務器就搞定了全部事情。另外若是要將互聯網金融平臺質量特性排個序，很顯然最重要的是安全性、可靠性，這畢竟是關係到用戶的血汗錢。安全性和可靠性也會直接影響功能的技術實現，但並無併發性影響性大。深刻分析職責後把每一種功能的實現關鍵技術列出，以下：

分類	需求	實現子系統及服務	實現技術（軟硬件結合）
前端用戶首頁及其它	產品展現、產品搜索、促銷活動、推薦服務	平臺商品服務	集羣部署、高速緩存、分佈式緩存、搜索引擎技術、靜態化
	廣告圖片、公告、幫助中心、媒體報道、常見問題	平臺商品服務	集羣部署、高速緩存、分佈式緩存、搜索引擎技術、靜態化
	投資某產品	平臺會員服務	集羣部署、消息隊列、實時計算
用戶會員中心	帳戶總覽、個人投資、個人借款資金記錄、帳戶安全設置、個人陸金幣、個人商品、個人消息、推薦好友、充值	平臺會員服務	集羣部署
前端用戶會員俱樂部	商品推薦、商品詳情、活動類推薦、活動類詳情、商品、活動搜索	俱樂部商品服務	集羣部署、高速緩存、分佈式緩存、搜索引擎技術、靜態化
	購買商品、秒殺購買商品、活動類玩法	俱樂部會員服務	集羣部署、消息隊列、實時計算
新增系統服務需求	商品推薦	日誌採集系統	集羣部署
	充值、支付	第三方支付服務	集羣部署
	短信、郵件通知	通知服務	集羣部署、調用多家第三方短信接口
	安全性	服務受權及審計服務	集羣部署
	數據可靠性	自動對帳服務	集羣部署
前端頁面	網站前端頁面	平臺網站WEB、WAP端	集羣部署、高速緩存、分佈式緩存、搜索引擎技術、靜態化
	網站前端頁面	會員俱樂部WEB、WAP端	集羣部署、高速緩存、分佈式緩存、搜索引擎技術、靜態化
運維管理	系統管理、不一樣產品的運維管理、不一樣產品的發佈管理、新聞及公告發布、統計及報表	運維管理服務	集羣部署
	運維管理前端	運維管理WEB端	集羣部署
手機客戶端	手機客戶端	Andriod APP及蘋果APP

　　如上所述，要支持運營目標的陸金所平臺，能夠分爲大小十幾個服務和子系統。系統劃分的依據一方面是職責，一方面跟實現技術有關，同一職責下實現技術不一樣會被劃分爲兩個服務，好比購買商品和商品展現本來屬於同一個大的領域，但其由於實現技術和質量要求不一樣須要劃分爲兩個模塊。這是由於微服務和傳統SOA最大的區別就是技術實現的個性化，只有個性化才能作好作專，並節省成本。另外根據系統分析，咱們須要將第三方調用的地方抽取爲服務，好比支付，將這些第三方調用抽取爲一個單獨的服務首先也是基於職責考慮，其次是基於穩定性考慮，由於調用第三方的東西一般存在很大的不穩定性，當某一廠商提供的API不能用時，咱們的系統須要自動切換到可用的API。用戶購買產品產生訂單相關數據，訂單數據關係到商品和用戶兩方面，若是是超高併發的系統，用戶購買行爲須要單獨的服務，但限於互聯網金融的特殊性-不會在同一時刻產生大量交易，咱們將訂單服務合併到用戶帳戶服務，由於從數據角度來說，訂單屬於每個用戶。

       另外，金融平臺和會員俱樂部從大的方面來說是兩個獨立的系統。雙方不共用任何基礎數據，若是須要對方數據經過各自的接口進行交互。總的來講，雖然有十幾個服務，但有些服務工做量並非很大，有一些小的服務好比支付、通知等，一個開發人員能夠開發好幾個，因此整體上所需的開發成本比傳統SOA仍是要低不少，並且傳統SOA技術門檻太高，對開發工程師要求較高，不像微服務只要定義好接口和規則，普通開發人員都能作。

 

l 邏輯架構

邏輯視圖採用如下方法創建。

 　　

按照職責、通用性、技能及工做量綜合考慮和計量，平臺邏輯架構設計以下圖：

　　

　　十幾個子系統分別分佈在服務層、服務監控與治理、表現層。實體層和接口訪問層雖然屬於「層」，但它們並不單獨發佈，而是使用Jar包類庫的方式提供給其它服務調用，是邏輯上的層。業務服務模塊具備模塊化，構件化的特色，並能夠以各類不一樣的協議發佈服務，包括SOAP、RMI、REST、JMS等。

 

l 開發架構

系統所需的工程，「[ ]」裏面表示工程的名稱。

　　

所需公共模塊工程：

　　

 

開發環境：

編碼：UTF-8                                          

工具：Myeclipse 10

SVN：Site-1.8.22

註釋插件：Jautodoc_1.8.0

Web服務器：Tomcat7

JDK: JDK1.七、 Java EE 5

開發環境：Maven 3

 

開發技術選型：

表現層：Bootstrap+Html+Jquery

MVC框架：Spring MVC 3.2

安全框架：Spring security 3.2

Rest接口實現：Spring MVC Rest

持久層：Mybatis3.2

緩存框架：Ehcache 2.六、Redis

日誌管理：SLF4J 1.七、Log4j

數據庫：MySql 5.5

 

l 運行架構

　　此架構設計視圖的關注點是控制流組織。運行架構考慮一些非功能性的需求，如性能和可用性。它解決併發性、分佈性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一塊兒－即在哪一個控制線程上，對象的操做被實際執行。

　　

主要控制流包括：

l  頁面訪問控制流

由前端瀏覽器發起請求，部分請求首先會到緩存裏查詢，若是緩存裏有結果則返回，若是沒有緩存內容，則繼續請求web服務器。也有部分無需緩存的請求直接訪問web服務器獲取數據。

l  日誌採集

操做日誌採集有兩條控制流。一條是頁面的採集js，直接將用戶請求發送至日誌採集接口，由日誌採集接口提交給消息隊列，再由日誌採集模塊從消息隊列裏獲取數據並保存。另一條是在web服務器層面攔截訪問請求並提交給消息隊列，並由日誌採集模塊獲取和處理。

l  自動對帳

由接口訪問層攔截須要記帳的操做，並轉換成記帳憑證提交到消息隊列，由自動對帳模塊從消息隊列中獲取數據並保存。自動對帳功能是由定時任務觸發，由自動對帳服務按規則進行對帳計算，若是須要預警則產生預警數據。

l  手機APP訪問

由手機app發起，部分請求首先會到緩存裏查詢，若是緩存裏有結果則返回，若是沒有緩存內容，則繼續請求web服務器。也有部分無需緩存的請求直接訪問web服務器獲取數據。

l  運維管理

由瀏覽器發起請求，考慮到併發狀況並非很大，可不通過緩存服務器，直接與web服務器運維服務交互。

 

l 物理架構

此架構設計視圖的關注點是物理節點（Node）分佈，以及軟件到硬件的具體映射關係。

　　

主要關鍵技術：

l  負載均衡

1）採用負載均衡器來實現硬件級的四層交換負載均衡，或採用LVS來實現軟件的四層交換負載均衡。並經過nginx實現反向代理服務器集羣。

2)  接口若是使用rest使用nginx做爲負載均衡器，若是使用dubbo\netty\thrift\Mina則使用zookeeper實現業務服務的負載均衡。

l  緩存

1）系統使用Varnish 集羣以做爲靜態頁面和圖片的高速緩存。

2）使用Redis集羣做爲業務層的高速緩存，Redis具備高併發、高可用等特性。

l  文件存儲

鑑於平臺文件存儲業務並不複雜，經過NFS實現文件存儲集羣。

l  消息隊列

系統使用高併發、高穩定性消息隊列rabbitmq實現異步消息處理。

l  Docker集羣

系統採用最新的虛擬機技術docker做爲服務集羣發佈的載體。