按照孢子框架要義對網際網路金融理財平臺進行微服務架構設計。假設我們設計的目標是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伺服器就搞定了所有事情。另外如果要將網際網路金融平臺質量特性排個序，很顯然最重要的是安全性、可靠性，這畢竟是關係到使用者的血汗錢。安全性和可靠性也會直接影響功能的技術實現，但並沒有併發性影響性大。深入分析職責後把每一種功能的實現關鍵技術列出，如下：

　　如上所述，要支援運營目標的陸金所平臺，可以分為大小十幾個服務和子系統。系統劃分的依據一方面是職責，一方面跟實現技術有關，同一職責下實現技術不同會被劃分為兩個服務，比如購買商品和商品展示原本屬於同一個大的領域，但其因為實現技術和質量要求不同需要劃分為兩個模組。這是因為微服務和傳統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作為服務叢集釋出的載體。