跨境網際網路券商架構最佳實踐
引言
近年來，隨著監管層面對金融科技的擁抱態度，券商通過網際網路展業的力度日漸加大，越信智慧科技核心團隊有幸加入兩家港美股券商，並負責從 0 到 1 建設香港 G 券商的跨境網際網路證券系統。因未有歷史包袱，G 券商的系統總體架構均為在目前主流技術基礎上進行重新選型，包括各端架構、CI/CD 及團隊協作工具，目前系統已平穩執行半年以上，未發生任何生產事故。後臺微服務、移動端元件化、DevOps 等在證券金融領域的實踐，希望可以給到同行一些啟發，更期望能獲得一些探討指點，在思維的碰撞中，完善認知。
正文內容概要：
- 系統特性
- 技術架構
- 部署架構
- 金融安全
- 核心系統選型
系統特性
跨境網際網路券商兼具金融、網際網路、跨境屬性，每個屬性對系統有著不同要求。
金融屬性：跨境券商的金融屬性決定系統對合規、安全性及穩定性有較高要求；
網際網路屬性：網際網路化運營思維則期望系統的擴充套件性良好，迭代效率高，以跟上需求的不斷變化；
跨境屬性：系統需提供給多地區使用者（大陸及香港地區）訪問，要求系統架構選型及部署時考慮版本國際化及跨境訪問的問題。
在符合監管規定的前提下，系統圍繞安全性、穩定性、易擴充套件性、國際化四個特性進行設計，考量以下細節：
- 安全性：終端安全、儲存安全、通訊安全、服務安全、資料安全；
- 穩定性：通訊穩定（HTTPDNS，專線），服務穩定（多點部署，閘道器支援熔斷、限流，監控告警），資料穩定（熱備）；
- 易擴充套件：服務分層，橫向擴容支援，前後端分離；
- 國際化：多券商、多面板、多語言支援，跨境加速。
技術架構
沒有祖傳程式碼，我們可以比較開放、客觀的在目前主流技術上進行選型，充分考量並平衡各技術方案的當下穩定性、生態及未來發展性。下圖為我們既定的技術棧架構圖：
後臺微服務架構
如上圖所示，我們基於 Spring Cloud 進行後臺架構設計，服務界限及層次均有一個較好的劃分，只允許上層服務依賴下層，不允許出現平級呼叫或下層服務呼叫上層服務的情況。萬一出現，則是組內討論，看是否有必要做服務下沉，調整服務層級。
兩個註冊中心：因為行情服務屬於我們之前的沉澱，久經考驗，高效穩定，為兼顧業務進度，暫未做註冊改造；
兩個閘道器：為提升推送速度及節約跨境頻寬成本，行情服務設計成無狀態服務，不依賴統一閘道器，可在全球多站點部署。
移動端元件化架構
在移動端，我們分別基於 Swift 及 Kotlin 語言進行元件化設計。
除無法替代的三方庫尚在使用 objc 以及 java 外，業務元件開發均使用新語言編寫，Crash 明顯減少（型別安全的語言特性），程式碼更加簡潔，開發效率變高。
元件化設計則讓移動端業務元件徹底解耦，在規範每個元件的程式碼目錄及呼叫約定後，程式碼結構非常清晰。不過前期在各個元件間呼叫上還是花了些時間。
Web 前後端分離架構
在 Web 端我們則採用前後端分離架構，並選擇 Vue 做為主體框架，因為其學習曲線相對較平滑（相比 react），國內生態也不錯，同時支援移動端 H5、PC 端開發，可較好的進行前端技術棧的統一。硬廣一個小夥伴們利用閒暇時間做的體驗一流的移動端 H5 行情。點此體驗。
DevOps
我們使用 jira 做為敏捷交付的專案管理工具，首個版本上線後，三週左右一個迭代；使用 jenkins+gitlab+docker 進行 docker 化持續整合交付，測試環境提交程式碼則自動釋出，生產環境由釋出人員確認後一鍵釋出；使用 yapi 用作我們介面文件及 mock server 工具，不再依賴後臺邏輯編寫即可聯調；使用 gitlab flow 統一程式碼協作規範。
有了專案晨會溝通，沒有了 JAR 包上傳發布，沒有了需依賴後端造資料聯調的痛苦，沒有了分支管理混亂導致不該上線程式碼上到生產及頻繁的衝突解決，團隊協作盡是一片歡聲笑語。
部署架構
部署架構設計時考慮要素：
- 客戶跨境訪問穩定性；
- 業務擴充套件性（如將來可能對接境內外地區券商，如境內 A 股、東南亞）；
- 成本；
- 符合交易所要求。
綜合考量，最終使用阿里雲部署相關服務，架構圖如下：
交易所要求
期望自行對接交易所行情或交易的公司需注意，因港交所線路不斷升級（如從 SDNet/1 升級到 SDNet/2），會對託管機房本身提出更高要求，有些機房就不一定能滿足這些硬性條件了，因此需提前瞭解清楚交易所的要求，找好對應機房。若不是自行對接，行情櫃檯供應商選擇的機房一般情況下都會符合要求。
業務擴充套件性
根據規劃，核心服務將來可以擴充套件提供 A 股、東南亞股市交易功能，且業務重心可能會更偏向境外，因此我們將核心服務均部署在香港阿里雲。不過阿里雲香港例項比華南區的會稍微貴一些，測試環境部署在境內可節約一些成本。
跨境訪問
因國際出口頻寬限制，若通過公網進行跨境訪問，偶爾還是會出現網路不可達情況，我們在沒使用專線的情況下確實碰到過網路問題，使用專線服務後情況有很大改觀。
特別注意的是：境內訪問境外 HTTPS 站點不穩定，需拉設專線解決。
成本
大型券商的架構中，大部分網路訪問是在專線內進行，但對於剛起步的券商，專線成本需考量（10M 基本上 1 萬 / 月），我們僅在大陸跨境訪問、櫃檯連線交易所使用專線，其餘部分專線替換為 VPN 訪問，不犧牲安全性的前提下，犧牲部分穩定性，迄今為止網路基本上未出現過問題。
另外專線還是儘量做到多方詢價，可以有三種方式搭建專線（直接從網路運營商拉設專線比較實惠）：
1、向網路運營商詢價並拉設專線；
2、向阿里雲有合作的供應商詢價並拉設專線；
3、找系統供應商負責對應的專線拉設，如櫃檯到阿里雲的專線可交由櫃檯供應商負責。
金融安全
安全的設計是貫穿在整個系統中，從架構設計、程式碼開發到運維，從使用者輸入到最終資料落地的整個鏈條均應考慮安全問題。
重點描述下我們在網路傳輸過程中的一些安全措施：
網路傳輸
從以下幾個方面保證資料的網路傳輸安全：
- 全站 HTTPS
並非申請一個 HTTPS 證書就萬事大吉，客戶端儘量對 SSL 證書進行嚴格校驗，避免中間人攻擊導致使用者資料洩漏。 - 敏感資料加密
部分敏感的資料我們會在 HTTPS 之內再進行一層加密，主要採用 RSA 非對稱加密方式，以防範 HTTPS 證書頒發機構出問題，隨意簽發證書導致的安全問題。 - API 簽名防篡改
所有面向終端的介面均要求籤名，防止介面資料被惡意篡改。
核心系統選型
在證券系統中，交易和行情屬核心的業務系統，選擇自研還是外部供應商？市場上供應商情況又如何？
交易櫃檯（港股）
目前市面上的外部供應商可定製化能力普遍較弱，定製化需求排期較慢，擁有自己櫃檯，相當於有了技術壁壘，因此很多公司有自研櫃檯的想法。但目前實際自研櫃檯的券商非常之少（宣稱的不算）個人認為主要是兩個原因：
業務能力：港股品種眾多（除常見的股票、基金外還有窩輪、牛熊證、股指期貨、股票掛鉤票據等豐富的衍生品），交易規則多樣（手數、價格步長不是確定值），支援融資融券業務。考慮的異常（業務異常，如孖展風控預警、牛熊回收、臨時休市等）非常之多，對團隊的港股業務經驗有著較高要求；
成本及週期：業務的複雜度與研發成本、週期正相關，並且考慮到交易所交易權的申請、專線鋪設、櫃檯的 MR 測試、生產試執行等流程，若可達到正式客戶使用，少則 1 年（有櫃檯研發經驗），上不封頂，小券商基本不會選擇這條路。
因公司業務時間限制，我們最終選擇對外部供應商進行選型對比，目前市面上頭部選手為 ayers、iasia、恆生三家，恰好我們基本都有使用過，大概做個總結：
Ayers：簡單、易上手，統一版本，定製開發較難，價格相對便宜，適合小客戶起步階段；
iAsia：大客戶較多，系統相對穩定，API 相對豐富（英文文件），價格相對較高，適合對系統高可用、高併發有要求和定製化開發要求較多的券商；
恆生：最符合中資券商習慣，服務比前面兩家好，對港股業務理解暫時沒趕上前面兩家本土供應商，不過個人認為成長性較好。PS：恆生收購 Ayers 會有什麼影響需自行判斷。
行情供應商（港股）
行情繫統我們有較好的沉澱，目前已是可支援直接解析港交所資料來源，提供實時和延時行情服務，屬自研系統。
資訊供應商（港股）
資訊供應商可選較多（如 AAStocks、ETNet、天匯等），基本都是以 ETL 形式接入，所以相對來說看中的是資料的質量，穩定性在可接受範圍內即可。
結束語
從 0 到 1 建設起一個網際網路券商系統大約需 1 年時間，20 人左右團隊，800 萬左右成本，不算是一個小工程。期間遇到的問題繁多，無奈團隊實在給力，準時交付且平穩執行。待花開，你們值得擁有更多的美好。亦願所有讀者的 2019，美味紛呈，精彩綻放。
作者簡介：童軍，越信智慧科技（深圳）有限公司技術總監。10 年以上網際網路從業，4 年網際網路金融、6 年管理經驗，重點關注網際網路金融領域。聯絡方式：微信 keyva33。