按照孢子框架要義對互聯網金融理財平臺進行微服務架構設計。假設我們設計的目標是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.7、 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.6、Redis
日誌管理：SLF4J 1.7、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) 使用zookeeper實現業務服務的負載均衡。
l 緩存
1）系統使用Varnish 集羣以作爲靜態頁面和圖片的高速緩存。
2）使用Redis集羣作爲業務層的高速緩存，Redis具有高併發、高可用等特性。
l 文件存儲
鑑於平臺文件存儲業務並不複雜，通過NFS實現文件存儲集羣。
l 消息隊列
系統使用高併發、高穩定性消息隊列rabbitmq實現異步消息處理。
l Docker集羣
系統採用最新的虛擬機技術docker作爲服務集羣發佈的載體。