金融交易系統設計思路

Mr. Neo Chen (陳景峯), netkiller, BG7NYT


中國廣東省深圳市龍華新區民治街道溪山美地
518131
+86 13113668890


版權聲明

轉載請與作者聯繫,轉載時請務必標明文章原始出處和作者信息及本聲明。

文檔出處:
http://netkiller.github.io
http://netkiller.sourceforge.net

微信掃瞄二維碼進入 Netkiller 微信訂閲號

QQ群:128659835 請註明“讀者”

2017-06-16


目錄

1. 架構縱覽

1.1. 網站部分

1.1.1. 網站前端

待續...

1.1.2. 網站後台

待續...

1.2. 交易伺服器部分

圖 1. 交易伺服器架構藍圖
交易伺服器架構藍圖

可以簡單的講交易伺服器分為三大塊:報價,交易,管理。

圖 2. 交易伺服器設計
交易伺服器設計

2. 應用層防火牆

什麼是七層防火牆,7層防火牆是在應用層工作的防火牆,它實時監控保護系統各個方面的行為。保護系統的安全運行,有效的保證系統的正常運行,有網絡系統安全中有良好的表現.

圖 3. Firewall
Firewall

這裡設計應用層防火牆是用來彌補3/4層防火牆的不足,我們的目的是保護我們伺服器安全。

應用層防火牆提供下面幾個特性
  1. IP地址黑白名單,地域區域封鎖,用於阻止某些IP地址訪問我們的伺服器
  2. 協議匹配,如果與應用伺服器建立連接後,發送的協議是錯誤的,我們視為嗅探行為
  3. 交易頻率控制,例如禁止機器人高頻交易
  4. 成交範圍,當用戶送出的訂單,價格不再我們的報價範圍,視為虛假交易
  5. Token 驗證,針對RESTFul等介面
  6. 數據收集(TCP/IP,在綫人數,各種協議操作人數,狀態...)收集這些數據用於伺服器監控。
  7. 擴展插件,我們希望這個防火牆能夠通過編寫插件擴展功能。

3. 集群實現

引入集群與分散式概念,傳統C/S伺服器軟件設計都是運行在一台伺服器上的,只能通過垂直擴展(升級硬件,如中央處理器,內存,硬碟),無法實現水平擴展(橫向增加節點擴展伺服器的並行處理性能)。

另外一個問題是傳統軟件任何更新都需要重啟,重啟已經不適合互聯網時代。所以軟件升級,配置檔案變更,我們要從設計的角度解決重啟的問題,最終我們要實現7*24小時不間斷運行。

最後是異構系統的支持與多語言支持,互聯網雲時代,任何一個系統不可能採用一種語言開發,通常是多個語言混合使用,取各種語言的有點。所以設計交易系統我們要考慮不同操作系統的差異與不同語言的通信。

分散式交易系統
  1. 負載均衡
  2. 橫向擴展,在不停機,不影響在綫用戶的情況下,動態增加或移除節點
  3. 節點健康狀態檢查
  4. 故障轉移
  5. 雙活,多活支持
<listitem>這樣的系統很容易實現多機房異地災備與多房鏈路負載均衡。</listitem>

4. Data feed 報價系統的設計

Data feed 是報價系統,主要的功能是為用戶提供實時報價。

圖 4. Data Feed
Data Feed

報價系統分為以下幾個部分
  1. 第三方數據接入
  2. 數據處理
  3. 數據送出

首先從第三方取得價格數據,這些數據源的對接方式,數據格式,頻率,所提供的產品類目均不同。所以我們需要為分別為各種第三方數據源寫插件對接他們的服務,插件的功能包括對數據的格式化,欄位調整等等,經過格式化處理後,輸出內容滿足我們的後續使用。

第二步是數據處理,為此我們需要創建一個分組,每個組中可以獨立設置產品種類,報價頻率,價格範圍,點差以及條件過濾。因為來自多個插件的數據報價速度不同,產品也可能存在重複,所以我們需要合併/拆分的功能,以滿足我們需要的數據,例如A、B、F、K幾個產品在來自某個插件,C、D、E 產品來自另一個插件。

第三步數據送出,將整理好的數據發送給用戶,展示在用戶的交易終端中。我們提供多種數據格式,以滿足異構系統與各種編程語言。

5. 核心交易系統的設計

交易系統的核心就是處理訂單,開倉,平倉,掛單等等。下圖展示了訂單處理的內部模型。

圖 5. Trade Core
Trade Core

5.1. 協議部分

客戶端需要與伺服器端交互,就需要通信協議,通信方式有兩種,一種是二進制協議,另一種是純文字檔案協議。

互聯網早期主要使用二進制協議,因為二進制協議體積小,占用頻寬少,傳輸效率高。二進制協議通常使用C/C++結構體作為資料結構,這種方式的有點是開發簡單,缺點是不能直接閲讀協議,並且與其他語言通信不靈活。

隨着網絡提速,解決了頻寬問題,於是出現了純文字檔案的協議,例如 HTTP、FTP、SMTP、POP3。這種協議可直接閲讀,大大提高了開發效率與開發難度,調試起來也極為方便,使用telnet就可以完成複雜也些的調試。

互聯網雲計算與大數據的提出,大家有意識到文本協議的開銷,於是二進制協議回歸,同時純文字檔案協議也在減肥。為瞭解決開發難度,同事保證開發效率,序列化誕生了,序列化分為兩派,一派是二進制,另一派是純文字檔案。

無論是二進制還是純文字檔案序列化,操作十分簡單只有encode/decode兩種操作方式,可以在任何語言中完成encode或decode操作,真正實現了跨語言,跨平台,所以交易通信協議這塊我們採用序列化替代結構體。

我們提供了多種協議供用戶選擇,協議轉換後對應後面的Trade Service

通過文本協議訪問

			
{"status":true, "error":0}		
			
			

通過二進制協議訪問

			
82 A6 status C3 A6 error 00
			
			

通過XML協議訪問

			
<xml>
	<status>true<status>
	<error>0<error>
</xml>
			
			

協議與服務是關係對象映射,例如上面的協議對應Class檔案

			
class Status {
	private status;
	private error;
}
			
			

5.2. 訂單處理

這裡開始涉及分散式軟件的開發,分散式軟件開發核心就是集中配置,分散式鎖,節點分配,健康檢查。

為了實現雙活,負載均衡,我們首先要將訂單持久化,這樣掉電,死機,崩潰等故障,能保證其他節點上的伺服器訂單是同步的。

為了同意調配所有節點,我們的系統配置是集中管理的。

訂單處理需要使用分散式鎖,流程是申請鎖,操作訂單,釋放鎖。鎖必須設置一個超時時間,這樣一旦某個節點申請了鎖,同時這個節點掛了,那麼鎖就一直不釋放,其他節點就無法操作該訂單,所以需要一個超時時間用於鎖的自釋放。注意:鎖是針對訂單的,可以稱為行級鎖。

定點採用事件觸發的方式,滿足條件即出發操作。

6. 管理員控制台的設計

通常交易系統有兩個控制台,分別是Adminstrator與Manager,Adminstrator是給運維人員使用,用於伺服器配置,例如權限分配,性能監控,日誌查看等等。Manager 是針對運營人員,主要共的功能客戶管理,交易品種管理,訂單管理等等

圖 6. Trade Adminstrator/Manager
Trade Adminstrator/Manager

6.1. Adminstrator

待續...

6.2. Manager

待續...

7. 總結