金融交易系統設計思路

文章還沒有寫完,接下來筆者要出差一段時間,回來在繼續完成該文。

目錄

• 1. 架構縱覽
  • 1.1.1. 網站前端
  • 1.1.2. 網站后臺
  • 1.1. 網站部分
  • 1.2. 交易服務器部分
• 2. 應用層防火墻
• 3. 集群實現
• 4. Data feed 報價系統的設計
• 5. 核心交易系統的設計
  • 5.1. 協議部分
  • 5.2. 訂單處理
• 6. 管理員控制臺的設計
  • 6.1. Adminstrator
  • 6.2. Manager
• 7. 總結

1. 架構縱覽

1.1. 網站部分

1.1.1. 網站前端

待續...

1.1.2. 網站后臺

待續...

1.2. 交易服務器部分

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

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

圖 2. 交易服務器設計

2. 應用層防火墻

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

圖 3. 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

報價系統分為以下幾個部分

1. 第三方數據接入
2. 數據處理
3. 數據送出

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

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

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

5. 核心交易系統的設計

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

圖 5. 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

6.1. Adminstrator

待續...

6.2. Manager

待續...

7. 總結