華泰證券:如何自研高效可靠的交易系統通信框架?

一、引言

華泰證券自研交易系統經過近兩年的建設,取得了階段性的成果,並在線上爲華泰自營部門和部分機構客戶提供了優質的服務。本文對自研交易系統的通信框架進行總體的介紹。

首先,我們以委託(交易下單)這個最普通的場景爲例,大致觀察下數據是如何在系統內部流動的。如圖1,客戶端從下單到接收成交回報,數據大致流經了網關、OMS(訂單管理系統,以下簡稱OMS)、DownStream(報盤)、訂閱中心。

image

圖1-委託(交易下單)

看似簡單的數據流,在項目設計和開發的過程中,我們自己、業務後臺,提了很多的問題,比如:
1)客戶端與網關間通信的安全如何保障?如何避免用戶感知鏈路的通斷?
2)成交回報如何快速回到客戶端?
3)業務系統只想關注於業務邏輯,不關注權限的控制,可行嗎?
4)OMS是內存交易系統,爲了解決用戶規模問題,需要基於分片水平擴展,高可用方案需要支持分片內的主備機切換,通信框架可以支持這些需求嗎?
5)DownStream有多個節點,這些節點面向不同的報盤對象,如櫃檯、交易所等,可以對上游的使用者(OMS)屏蔽這些差異嗎?
6)部分應用沒有狀態,可以平行擴展,消費者可以負載均衡地訪問我們的應用,可以嗎?
7)是否可以支持灰度升級?
帶着對這些問題的探索和解決,我們來介紹自研系統的通信框架。

二、通信框架

我們先給出系統整體的示意圖(如圖2所示),然後介紹我們通信框架的核心組成部分。
外部系統訪問交易相關的任何後臺服務,需要通過NGINX代理,訪問相應的網關服務組,通過網關路由到相應的後臺系統。內部訪問交易相關後臺服務時,通過XSTEP的服務發現機制,直接對目標服務發起訪問。

image

圖2-自研交易系統示意圖

2.1 XSTEP協議

2.1.1協議分層

XSTEP協議是自研交易系統內部採用的協議,爲了與Dubbo更好的兼容,我們將XSTEP協議進行了分層設計,由會話層和應用層協議兩部分組成。業務系統可以在會話層與應用層皆使用XSTEP協議,也可以會話層使用Dubbo,應用層使用XSTEP。

2.1.1.1 會話層協議

會話層協議採用了輕量級的設計理念:信任TCP的可靠傳輸能力,正常情況下可以保證消息的完整與順序,當出現異常情況時(如協議類型異常、校驗異常),代表網絡環境異常,會話層中斷重連,不嘗試進行消息的重傳。

會話層規定T爲標準空閒間隙,3個間隙未有任何報文傳輸,需要中斷鏈路。XSTEP會話層在實現時,提供了鏈路空閒自動心跳的能力。爲了防止惡意攻擊或數據異常跳變引起的通訊異常,XSTEP會話層規定了最大報文長度,超過此大小的報文會被丟棄。

會話層在實現時,支持自動重連,支持自動重連策略的設置。同時爲兼顧安全與效率,會話層支持非加密方式傳輸和TLS加密方式傳輸,應用可以根據應用場景自由選擇。

會話層還提供了服務發現與路由的能力,將在2.1.2節中介紹。

2.1.1.2 應用層協議

XSTEP應用層協議定義了數據在內存中的組織形式,並通過統一的數據結構,提供數據的訪問接口。
Event數據結構的定義如圖-3所示。數據結構通過MAP<K,V>鍵值對的方式作爲基本的數據存儲結構,接口上,支持所有的基礎數據類型。

image

圖-3 Event結構示意

同時爲了支持數組及嵌套結構,還提供了Group數據結構(如圖-4),該結構支持嵌套定義,形成無限擴展的樹形結構。上述數據形式的定義,在實踐中可以滿足目前所有業務的數據形式。

image

圖-4 Group結構示意

2.1.2 服務發現與路由

協議設計過程中,我們定義了幾個原則:1)服務的消費者不應感知具體服務提供者的變化2)要支持服務的負載均衡訪問 3)要支持服務的主備訪問4)要支持服務分組,以隔離不同的用戶或業務或版本,並支持服務的灰度升級 。

基於上述目標,我們設計了服務的自動發佈與發現機制,並設計了兩級路由。通過XSTEP開發包開發的應用,啓動後將會自動發佈到註冊中心。

2.1.2.1 服務發佈

註冊中心包含多級目錄,頂級目錄XSTEP表示這個一個XSTEP應用;第二級目錄爲系統名;第三級目錄區分了服務的提供者和消費者,同時該級提供了一個名稱爲router的固定文件,用於系統自定義分片路由規則;第四級目錄用於區分不同的分片;第五級目錄是真正的服務實體,該信息是動態創建和消失的,同時第五級還提供了一個名稱爲master的固定文件,用於主備模式下主機地址的註冊。

服務提供者在發佈服務時,需指定自身的系統名稱、所屬分片(不指定默認分片)、服務地址和端口(不指定則默認)。

如果該服務需要由服務提供者自行決定分片路由的規則,則服務提供者應該在router中寫入路由的規則。如果該服務工作在主備模式下,則服務提供者應根據自身策略,在master中寫入相應的IP、PORT等信息。

應用可以根據報文中存在的任意一個字段來定義路由的規則,非常靈活,路由的目的地是系統內的不同分片號。分片號可以根據不同的用戶來劃分,也可以根據不同的業務來劃分(如A股OMS、期權OMS),還可以根據不同的版本來劃分,這樣系統升級時可以做到部分升級,用戶逐步切換,達到灰度發佈的目的。

2.1.2.2 服務發現

XSTEP開發包提供統一的服務消費類,使用時需要指定目標系統的名稱,分片的路由方式,具體服務的路由方式(主備或負載均衡)。

開發包會根據應用提供的上述信息,自動將數據投送到具體的服務提供者,並自動管理服務註冊信息的變更、鏈路的變化等。 在主備模式下,當主節點發生變化時,開發包會自動建立與新主節點的連接關係。

2.2 網關與訂閱服務

完整的通信框架中,僅有協議開發包是不夠的,因此基於XSTEP協議開發包,又實現了統一的網關和訂閱中心服務,搭建完整的通信框架。

爲了統一開發模型,我們定義了開發框架和運行時容器XGATEWAY-PLATFORM,網關和訂閱中心作爲不同的插件在該框架中開發,並運行在統一的容器中。

2.2.1 網關

網關面對的是一個複雜的環境。首先是協議的複雜性:1)接入協議目前使用XSTEP,後期也有支持FIX接入的需求。2)面對的後臺應用有XSTEP協議,也有Dubbo協議,也有使用Restful協議。

其次是部署的複雜性:1)爲了交易的穩定可靠,需要區分資訊接入和交易接入。2)需要區分API接入和客戶端接入3)出於安全或合規的考慮,某些接入網關上需要屏蔽特定的後臺應用。

網關的解決思路是:1)每種協議的接入作爲獨立插件開發 2)用戶登錄狀態的管理、流量控制、權限控制等作爲公共基礎服務提供。3)部署時,根據不同的需求,配置不同的插件和路由規則,形成不同定位的網關服務組。4)網關在設計上是無狀態的,每個網關組內的網關可以平行無限擴展。5)網關內部通過事件驅動的方式投遞事件,通過本地路由規則決定事件最終歸屬的插件。
下一步網關還將對接入的後臺服務進行質量管理,可以做到服務降維,防止部分服務異常導致的系統性風險。

image

圖-5網關框架

2.2.1.1登錄狀態管理

外部系統訪問網關時,必須通過認證的鏈路。一個鏈路通過認證,有兩種方式:1)發送登錄報文,並攜帶合法的用戶標識與口令。2)攜帶此前登錄成功時,獲取到的未過期TOKEN標識。

登錄報文處理邏輯:網關通過統一認證校驗標識和口令的合法性,對於驗證合法的登錄,網關緩存統一認證辦法的TOKEN,將鏈路標識爲合法,並將TOKEN返回客戶端。由於TCP長連接的安全特性,在該鏈路未中斷的情況下,對於鏈路上發起的請求,網關不再校驗合法性。但是網關會定期通過統一認證校驗此前頒發的TOKEN是否失效,如果失效則通知相應鏈路的接入者。

在實際應用中有一種常見的場景,鏈路發生了中斷重連,此時並不希望用戶重新輸入用戶名和口令。網關在未經認證的鏈路上,此時則會通過緩存TOKEN進行校驗,自動對鏈路進行合法性認證。
另一種場景是某一臺網關服務中斷,或接入者鏈路中斷,重連時接入了一臺新的網關。新的網關上並沒有緩存的TOKEN信息,此時網關會向統一認證發起一個TOKEN校驗,並獲取該TOKEN對應的用戶基本信息,自動進行鏈路的合法性校驗。

2.2.1.2 流量控制

網關支持鏈路級的用戶流量控制。通過IBOS運行平臺可以設置每個用戶每秒允許的最大流量及特定功能每秒允許的最大流量。

爲了提升流量控制的效率,網關並不會統計每條報文的時間,而是基於目標數進行控制。假設用戶的流量限制爲N,則網關會在該用戶接入消息達到N時,認爲一個統計週期結束,並檢查(結束時間-週期開始時間)是否超過一秒。超過限制則觸發流控,該鏈路報文將禁入時間T。未超過限制,則清空統計報文,開始一個新的統計週期。

2.2.1.3 權限控制

網關爲OMS等關鍵系統提供了統一的權限控制服務,使得業務可以專注於業務本身。用戶權限相關數據存儲於IBOS平臺,網關會在鏈路鑑權時獲取該數據。

權限模型定義了交易、訂閱、查詢等權限,網關將每種權限作爲獨立的鑑權實例開發,同時支持通過消息類型配置消息所適用的權限模型,未配置的消息則不進行權限控制。

2.2.2 訂閱中心

訂閱中心與網關採用相同的框架開發,運行在相同的容器中,只是加載了訂閱中心插件。訂閱中心支持多種訂閱維度,並支持較爲複雜的訂閱條件過濾。

訂閱中心將訂閱關係存儲在REDIS中,並通過KAFAK接收應用推送的消息。因此訂閱中心本身是無狀態的,可以水平擴展,並且通過KAFKA的PARTITION機制,可以負載均衡地處理推送消息。

image

圖-6 訂閱中心

三、結語

現在讓我們回到初始的幾個問題,並進行回答。
1)客戶端與網關間通信的安全如何保障?如何避免用戶感知鏈路的通斷?

答:XSTEP支持TLS鏈路加密,並提供加密算法,可對特定字段加密。通過網關的登錄狀態管理和XSTEP開發包的自動重連機制,可以不感知鏈路的通斷。

2)成交回報如何快速回到客戶端?

答:OMS接收到成交回報後,推送至訂閱中心,訂閱中心根據用戶的訂閱信息,主動將成交回報通過網關推送至客戶端。無需客戶端主動查詢。

3)我們的業務系統只想關注於業務邏輯,不關注權限的控制,可以嗎?

答:我們在接入網關層實現了通用的權限控制模型,可以做到消息級的權限控制。

4)OMS是內存交易系統,爲了解決用戶規模問題,需要基於分片水平擴展,高可用方案需要支持分片內的主備機切換,通信框架可以支持這些需求嗎?

答:XSTEP的服務發佈機制,支持分片,並且服務提供者可自主控制分片的路由規則。XSTEP服務發佈支持分片內的主備,並對消費者屏蔽具體的切換邏輯。

5)DownStream有多個節點,這些節點面向不同的報盤對象,如櫃檯、交易所等,可以對上游的使用者(OMS)屏蔽這些差異嗎?

答:使用分片機制,可以解決上述問題。

6)我們的應用沒有狀態,可以平行擴展,所以我們希望消費者可以負載均衡地訪問我們的應用,可以嗎?

答:XSTEP服務支持分片內的負載均衡的訪問方式,並且對使用者屏蔽細節。

7)可以支持灰度升級嗎?

答:通過分片支持,新的版本部署在新的分片中,並通過用戶屬性配置,逐步將用戶切換到新的服務分片中。

作者介紹:李想,華泰證券信息技術部系統架構師。關注內存交易系統、高性能網絡、容器等領域。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章