百度基于金融場景構建高實時、高可用的分布式數據傳輸系統的技術實踐

Posted on 2024-01-18 11:22 Jack Jiang 閱讀(65) 評論(0) 編輯收藏

本文由百度搜索技術平臺研發部分享，本文有修訂和改動。

1、引言

分布式數據傳輸系統是一種用于在多個計算節點之間高效傳輸大量數據的系統，詣在高效的解決大規模數據遷移、備份、跨地域復制等問題。其廣泛應用在實時數據流傳輸、跨數據中心數據遷移、多媒體傳輸等場景，在大多數企業中的日志管理、業務數據建庫等場景中也都會使用到。

眾所周知，數據的高效傳輸往往直接影響著企業對市場先機的把握，對企業發展有重要意義，特別是在金融領域，如證券行業，它對分布式數據傳輸系統的設計提出了更高的要求，證券領域數據變化飛快，一個高時效、穩定的數據流傳輸系統不僅能有效的提升用戶體驗，更能提供用戶一手的投資信息，有助于用戶的投資決策，進而拉進企業與用戶的距離。

本文將通過一個百度搜索旗下的金融場景案例來分享構建高實時、高可用的分布式數據傳輸系統的技術實踐。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4602-1-1.html）

2、業務背景

作為百度搜索場景下時效性要求較高的業務，金融承載著每天數千萬次的用戶搜索請求。

而在2021年以前，金融業務的數據一直都是采用傳統的互聯網引入方式，該方式的特點是接入成本較低，但受公網等不可控因素影響，數據時效性較差，且數據斷流、錯誤等問題頻出，隨即而來的就是業務維護成本較高，十分不利于產品迭代。

我們基于此發起了一個證券數據直連項目，詣在通過接駁全球各大證券交易所數據中心來構建一個高時效、高可用的分布式傳輸系統，從而有效的解決傳統數據引入方式（公網抓取、推送）所帶來的時效性、穩定性、正確性等問題，進而滿足全國乃至全球用戶的金融需求。

3、設計目標

3.1業務目標

接駁全球各大證券交易所Level-1行情數據，來覆蓋全量上市公司股票、外匯、期貨、ETF、渦輪牛熊等證券業務來滿足用戶需求，時效性追平金融行業競品，為打造強大的金融生態做數據基建儲備。

Level-1行情簡稱LV1行情：是交易所根據交易規則發布的即時行情信息，數據格式包括基于FIX/FAST協議的接口和TXT文件、二進制數據流等，行情通過交易所信息技術公司的高速地面網和寬帶廣播衛星系統發布或上證所信息網絡有限公司的互聯網和專線傳輸。

3.2技術目標

1）基礎設施建設：協同交易所、運營商完成物理專線的鏈路部署，通過物理專線接入的方式在百度云機房接入上海、深圳、香港、納斯達克證券交易所數據中心，適配交易所單、組播協議將二進制流/文本數據引入到百度內部，再分別完成華南、華北、華東、香港（支持海外訪問）地域的數據存儲與轉發，同時支持負載和流量調度來支撐各地域的用戶請求。(注：這里的物理專線特指光纜）

2）時效性和穩定性提升：行情數據檢索99分位耗時不超過200ms，數據穩定性從99%提升至99.99%以上，數據災備能力從1主0備升級至1主2備。

3）數據安全：基于百度安全能力，構建類似的防火墻策略來嚴格控制每一個機房、每一個集群的出入權限，并且配置好相應的安全組策略。

4、關鍵思路

從功能和網絡拓撲上來看，一個高時效、高可用的金融數據傳輸系統至少需要包含以下幾個部分，我們逐個來進行解讀。

4.1接入層

適配全球各大交易所單、組播傳輸協議，確保數據能在專線物理網絡正常傳輸。

接入主要有2種方式：

1）一種是走互聯網；
2）一種是走物理專線。

前者相對比較靈活：各類數據協議基本都可以支持，有直接走HTTP（GET/POST），或者是走消息隊列的發布訂閱等等，接入成本較低，屬立即接入那種，但受公網的不可控因素影響，在傳輸效率和安全性上相對后者會有比較大的差距，我們一般會把互聯網的方式當做一個災備能力存在。

專線方式的特點：是僅點對點傳輸，由于用的是獨立的光纜，在有限帶寬內理論可以做到無爭用狀態，不受公網影響，屬可靠傳輸，傳輸協議私有化，增加了更多的認證機制。因此也更安全，區分不同應用場景，像證券類數據傳輸，一般交易所采用的是單播、組播方式，當下用的多的是組播。另外專線中也有主備的概念，一般會預留1-2條線路做災備，整體下來，專線的費用要更昂貴一些，接入的周期也更長，往往長達幾個月。

4.2網絡層

完成華南、華北、華東百度云機房虛擬網絡架構建設，包括子網、路由、網關等。

虛擬網絡的核心組成部分主要是子網、路由、網關、虛擬機，其中每個子網關聯著一個虛擬機集群，我們把整個組成部分（域）統稱為一個VPC（Virtual private Cloud），路由又區分為TGW路由和對等連接。

這里主要關注對等連接，它是為用戶提供了VPC級別的網絡互聯服務，使用戶實現在不同虛擬網絡之間的流量互通，實現同區域/跨區域，同用戶/不同用戶之間穩定高速的虛擬網絡互聯，其核心是基于對路由表的操作，對等連接也支持配置地域級的DNS同步。

網關又分為NAT網關和專線網關：

1）一個對外：比如設置SNAT和DNAT規則用于統一網段的外網出口；

2）一個對內：對內其實就是確保能夠走專線和內部網絡打通。

4.3傳輸層

完成各機房內的數據解析、存儲、同步、轉發等。

對于接入層獲取到的數據我們分為三個級別：

1）像交易所主要是二進制流、文本為一級數據，我們需要保留近一段時間的原始數據落在本地（一級數據管理集群），以便用作應急回放。

2）而解碼后的數據為二級數據，落在二級數據管理集群上，主要用于跨地域同步。

3）最后，對解碼后的數據進行計算&加工，作為三級數據，落在三級數據管理集群用于承接應用服務。同時，按協議解碼后的數據按照使用場景區分為實時流（如分時）、延時流（如K線），延時流經過實時流計算得來，實時流同步進內存用于提升IO效率，延遲流通過實時流的計算后異步進DB，DB維護在三級數據管理集群上。

4.4應用層

負載/流量調度、監控能力等建設。

應用層的設計，主要有兩個方面的考慮：

1）一方面是對于接入層的負載和流量調度，如通過部署websocket/http服務來支撐百度用戶流量，使用BLB（Baidu Load Balance）將同一區域的多臺百度智能云服務器虛擬成一個組，設置一個內網或外網的服務地址，將前端并發訪問轉發給后臺多臺云服務器（BCC），實現應用程序的流量均衡，性能上實現業務水平擴展。

負載均衡還通過故障自動切換及時地消除服務的單點故障，提升服務的可用性，支持服務器調度權重策略配置，并支持TCP、HTTP等協議。

2）一方面是對監控的應用，如請求/數據傳輸日志落盤、統計、分析以及流量和sla監控等。

4.5小結

將以上四層能力建設后，此時單機房內的網絡拓撲應該如下圖所示。

注：DCC/BBC/BCC都是百度云范疇的機器類型，更多細節可以參考百度智能云私有網絡：https://cloud.baidu.com/doc/VPC/s/Vjwvytu2v。

5、核心難點1

公網和私有網絡方式下如何在云上完成多協議適配，尤其是在私有網絡中適配單播、組播協議以及如何做組播轉單播。

5.1公網&私有網絡接入介紹

對于一個數據傳輸系統來說，最重要的一點其實就是能支持多協議的數據適配來提升系統的靈活性，證券交易所一般提供的接入方式有公網接入和私有網絡接入，公網接入的成本較低，一般周粒度就可完成，沒有復雜協議約束。

而私有網絡往往會有更高的要求，協議上大部分都要求具備單播介入能力，少部分像納斯達克和深圳交易所會要求下游支持組播接入。絕大多數的云廠商是無法直接在虛擬機上適配的，傳統券商基本都是完全使用昂貴的物理機資源來承載，雖然物理機插拔更方便也更穩定，但運維管理成本也更高。

兩種方式在效果和成本上也有本質的區別：

1）公網接入：公網比較常見的數據接入方式主要是HTTP/HTTPS方式，當然也會有RPC/FTP，只是用的相對少一些。

為了提升數據傳輸安全，雙方可以在調用前協商好數據加密算法和密鑰。優點是接入成本較低，能快速應用，尤其在跨洋傳輸上會有體現。缺點是走的公共線路，網絡不可靠，且數據易被截獲，當攻擊者捕獲兩端的數據包后，哪怕不能完全解析，也可以實施一些流量攻擊手段以影響服務穩定性。總的來說，一般不會對于安全性、時效性要求較高的數據采用該方式接入，更多是只是一種備用方式（特殊場景除外，如跨洋傳輸）。

2）私有網絡接入：公司內網其實就屬于一個私有網絡，但是對于跨公司傳輸數據的場景，要想構建私有網絡，一般會走物理專線接入的方式。

這種點對點傳輸方式的顯著優點是專網專用且安全性較高，基本不受公共網絡影響（自然災害等不可抗力除外），在帶寬范圍內基本可以做到無網絡爭用狀態（數據即發即達），由于是私有網絡（雙端內網傳輸），基本不用擔心數據安全問題，而且往往還會增加額外的數據校驗手段，尤其在金融場景，會有嚴格的token（硬/軟）認證，該方式的缺點是成本相比公網傳輸接入成本更高，一般要持續數月，費用更昂貴，一般在上百萬元，依賴選取的傳輸介質（一般選擇光纖）和帶寬。

5.2私有網絡中單播、組播協議接入方案

私有網絡有單播、廣播、組播之分。

1）單播：相對比較好適配一些，走靜態路由的方式在同一個VLANID下分別配置云端和IDC端的IP段作為IPV4專線互聯地址即可。

2）廣播：一般是對于服務端而言，比如證券交易所下游對接著全球范圍的所有券商，數據源是相同的，一般會采用廣播的機制把數據推送給所有下游。

3）組播：一般是要求下游需要適配，現如今大部分業務都已經上公有云，在云上常用虛擬化技術來完成服務器集群的部署。

對于虛擬機來說，更多的支持單播傳輸，不支持組播傳輸，往往需要在專門的物理設備（組播路由器、或特定的組播軟件）上配置轉發組播報文的路由，路由表關聯著具體的路由協議（如PIM），再用IGMPV3協議來完成組播成員和報文的管理，通過動態BGP維護鄰居關系（現在的云廠商上對BGP的可能是固定分配AS號，如果有AS的要求還是需要在物理機上單獨做），我們可以圈出一部分物理資源專門承載組播數據傳輸，通過配置IGMP Snooping（可以將組播報文轉發到二層數據鏈路層，實現組轉單，注意版本需要是3，否則無法轉發IGMPV3報文）+ AP完成組播轉單播配置，再通過雙網卡（WAN口+LAN口）形式實現專線網絡數據接入&同步到百度內網，物理機通過三層交換機來關聯，構造出類似下面的網絡拓撲（如下圖所示）。

6、核心難點2

6.1概述

數據管理&跨地域同步，數據災備能力、時效性提升。

數據的分層管理主要是應對單機房內的場景，而對于跨機房或者說跨地域的主要難點是數據同步，后者需要更多的考慮跨機房數據傳輸效率和災備管理，核心是網絡設計。

6.2數據管理

按使用場景的不同，將數據分交易所二進制流數據（原始數據流）、文本數據、業務數據/日志等。

1）原始數據流：主要應對單機房、跨機房傳輸場景，當出現下游業務服務異常導致的數據展現錯誤時，存儲的原始數據流可以很好的對數據進行回放，以便快速恢復業務，尤其是應對金融證券數據傳輸場景，證券交易所一般不會推送重復數據，如果下游業務服務異常導致存儲的業務數據全部失效或為臟數據，那可能只能通過refresh主動請求上游來重新獲取。

但這樣做可能會出現核心數據丟失，由于這種方式的效率較低，還會擴大業務受損的影響面，因此一般會先存儲交易所下發的原始數據流，業務可以自定義存儲方式和周期，當出現問題時，可以通過『重播』原始數據流來止損。

另外原始數據流還能用于在對等網絡中的跨機房恢復業務數據。

2）業務數據流：主要應對單機房傳輸的場景，根據模塊分工的不同，分證券的實時行情、歷史行情等等，對于單機房數據集群的管理我們有很多方式，對于自研的DB，在調度上可以用一些標準的分布式管理手段（如zk），數據同步的手段一般需要自定義，對于傳統的DB如Mysql、Redis、Mongo等，一般有標準化的數據同步方式和調度模式。

6.3跨地域同步

跨機房地域同步的前提是多個機房之間需要有直接或間接關聯關系的專用物理網絡，即確保網絡是可達的，然后再結合虛擬網絡完成子網及路由配置。

對于具有直接網絡關聯關系的2個機房來說，我們的對等網絡（Peer Connection）設計稍微簡單一些。

現在各個云廠商也基本都支持直接配置了，其原理是首先在同一個VPC下劃分好子網并規劃好集群規模，其次通過配置路由表的方式完成本端和對端的下一跳關聯，這樣就完成了2個直接對端的對等網絡建設。

接著再配置和內網專線的路由，就能做到云機房->內網機房的網絡互通。

但如果2個機房沒有直接關聯關系，而又需要完成本端和對端數據同步怎么辦呢，比如有A B C三個機房，只有A-B B-C有直接關聯關系，而我們想要讓A-C關聯，這時候不可能說再建立一條物理鏈路，我們可以采用類似橋接的方式（或者叫隧道），同時關聯A-B-C三個機房，其中B作為一個"網橋"，再通過NAT技術完成IP地址轉換，確保C可以識別從A過來的路由，而A-B B-C 正常采用對等網絡的方式完成基礎網絡配置，這樣就可以胯多個機房進行通信，由于是物理網絡傳輸，機房間的耗時不會有很大差別（30ms內）。

由于網絡細節的篇幅較多，我們不做詳細的贅述，這里我們看看跨地域同步的網絡架構（如下圖所示）。

注：圖中網段可以根據不同場景做劃分，這里只做簡單介紹。

6.4數據災備能力、時效性提升

數據災備：我們一般選擇離各個證券交易所就近的一個接入點，比如上證選擇在上海機房接入，深證選擇在廣州接入，納斯達克在香港接入，每個接入點配置2條專線用做物理鏈路的主備，同時擴展一條互聯網通路（注意這里的互聯網也是直接和交易所對接，已經不是傳統數據引入渠道）做次備，鏈路默認都是活躍狀態，有專們的物理設備會根據專線的健康狀況（自定義邏輯）自動切換。

最后，再根據上面提到的跨地域同步的原理，在云機房關聯各條物理鏈路，在每條物理鏈路上抽象出獨立的VPC，通過構建網絡拓撲實現跨機房數據復制及災備。

時效性：物理專線（光纜）接入方式天然的優勢就是數據"即發即達"，因為在固定帶寬內基本不存在網絡爭用，而且現在大部分線路都會配置中繼，其損耗帶來的影響相對可控，因此接入方式就決定了數據傳輸的時效性。

相比傳統互聯網接入方式，單從數據上來看，專線接入SLA超過5個9（互聯網接入2個9），當然也會配置上重傳機制來進一步提升數據到達的可靠性。

交易所下發數據的數據頻率按市場劃分，A股一般3s/筆，港美股沒有特殊限制，即有成交即下發，除去光損耗帶來的影響，最快可以到3ms/筆，由于頻率越高，對機器要求也越高，為此我們特殊做了一些限頻操作，整體的數據時效性基本會在60ms（99.99+分位）內。

7、核心難點3

7.1概述

集群管理&單地域、跨地域流量調度。

流量調度生效在應用層，主要是找到一種高效的調度/負載方式來對內/外的業務提供數據支撐，從協議上/應用場景劃分主要有TCP/HTTP，策略上因業務而異，主要還是基于對流量分配中權重的定義。

比如有基于RS健康檢查的分配，每隔一段時間探測一下下游集群的健康狀況來動態調整流量配比，也可以根據下游機器的連接數來分配，還可以基于對資源訪問的熱度來分配，區分單地域和跨地域場景如下面所述。

7.2單地域場景

現在各個云廠商都有相應的流量調度產品支撐，比如百度云上有BLB（Baidu Load Balance），可以很輕松構建一個調度規則出來，在BLB下可以設置調度集群的協議（TCP/HTTP），然后關聯對應的服務器集群，最后給不同的服務器集群配置權重策略。

當流量進來時，BLB會幫我們完成自動分配，在某一個集群出現問題時，可以手動調整集群權重來干預流量配比，即所謂的切流。

7.3多地域場景

多個機房間的流量調度策略是在云上一般是隔離開的，當然我們可以在多個機房的最上層再抽象出一個專門的調度集群，對外暴露一個VIP。

在這個VIP上配置多個地域之間的調度關系，互聯網公司基本上也都是這么做的，更多的是針對超大集群規模的場景，而且VIP的選取也是有條件/成本的。

但如果想低成本快速在云上創建一個能支持多地域同時訪問且具備自動化流量調度的應用，且云上又不支持多地域共享VIP的功能時，我們可以盡可能多的基于云上已有的功能自己完成，在每個機房內部單獨抽出一個類似nginx的集群，每個集群上維護著不同于本地域的調度關系，它們的下游就是不同于本機房的BLB，同時互相檢查對方的健康狀況并上報監控系統，這樣當出現異常時，除了能針對性的在本機房內完成BLB級的流量調度，還能做到多機房間的流量切換，以提升機房間的災備能力。當然，也需要有足夠的容量。

8、總體設計

上圖各個模塊的作用如下（各模塊均采用多路復用）：

1）源數據接入集群：適配2種方式（互聯網/物理專線）+各類協議（互聯網、單播、組播）的數據源接入；

2）源數據轉發集群：確保各機房源數據的一致性，降低由于業務服務本身帶來的數據不一致問題；

3）數據解析集群：公共模塊，主要是針對源數據進行統一的處理，以便轉發給下游各業務；

4）業務數據集群（實時/延時流）：負責將數據解析集群下發的內容轉換成業務詳細數據，也就是B端或C端用戶看到的數據；

5）網關集群：負責承載用戶訪問流量；

6）監控集群：負責收集各個集群上報的日志情況，并作為穩定性管理手段之一。

可以看到：機房B相比其他機房，少了接入層配置，這主是基于成本和性能上考慮，把機房B當做數據傳輸樞紐，不僅能保證本機房數據傳輸，也能支持跨機房的數據同步&復制。該分布式傳輸系統從數據接入到監控集群，整體機器規模不大（100左右），但可支撐超過10億的流量。

9、本文小結

一個良好的產品體驗及產品矩陣，其背后一定離不開一個高可用、高時效的數據支撐，尤其是在金融領域，用戶只可能會為一手的信息、完善的產品功能買單。

自21年完成數據通路建設以來，金融的穩定性和業務規模都有了質的飛躍，證券數據時效性問題從季度數十個降低到年度1個以內，99分位耗時更是從過去的分鐘級降低到60ms以內，數據SLA從2個9左右提升至5個9以上，產品覆蓋股票、外匯、基金、期貨等諸多領域，也是第一個在搜索領域支持行情長連接的業務，基于搜索生態也孵化出來了像百度股市通PC站、app等多個獨立端產品，目前正在結合AI能力進行持續優化，期望從完善用戶體驗->幫助用戶決策進階，也讓金融投資變得更智能，更簡單。

本文主要結合一個金融數據接入案例對分布式數據傳輸系統做了一個簡單的介紹，包括傳輸系統中的一些核心節點的設計，如數據接入層的多協議適配、數據的分層管理以及跨地域的數據同步對應的網絡拓撲等，通過實驗得出結論，該方案能很好的應用在各種規模的分布式數據傳輸系統設計中。當然，由于篇幅問題，也省略了很多實現上的細節，讀者有任何問題可以留言，可以一起探討，也會盡量答復。