作者｜郝星宇編輯｜小智近年來，一個名叫Fintech的名詞悄然興起。網際網路科技與傳統金融行業的結合越來越深入，作為投行交易系統定海神針的市場資料平臺，有著怎樣的技術背景？其架構設計又是怎樣的？

投行的Global Markets或Sales&Trading部門主要服務於大型機構客戶，包括金融機構，企業，政府以及各種投資基金（私募基金，對衝基金等），從事包括做市商（Market Maker）, 外匯（FX）, 固定收益類交易（Currencies, Interest Rates and Credit）, 股票交易（Equity Securities），衍生品交易（Derivatives）及結構化產品（Structured Products）等以滿足機構客戶及投行自營交易等各種金融需求。

背景介紹金融背景

08年金融危機或者Dodd-Frank法案以前，投行內部依靠良好的融資渠道和低成本優勢，林立著各種高槓杆自營業務實體（類似對衝基金）從事量化交易，對衝，跨市套利，對賭等交易，如著名的高盛Global Alpha，大摩的PDT（Proess Driven Trading），這種高額暴利交易不但成就了投行本身，也成就了很多從Trading Floor直升的大佬，如花旗與大摩的前任CEO。

08年之後，美國政府明文規定投行停止自營交易，各大量化部門飽受打擊，要麼艱難的維持極小自營規模，要麼銷聲匿跡。與此同時，也簇生，發展，興盛了投行的專屬做市商（Designated Market Maker）自動化交易，尤其是指數，期權，外匯，國債等，包括B2B（Broker-to-Broker）市場和B2C（Broker-to-Client）市場。

技術背景

我們要介紹的系統平臺，則跨越了從支援自營業務交易到支援做市商自動化交易。

華爾街大行之所以稱之為大行，除了其金融業務實力之外，其技術功力也不可小噓，實力不亞於矽谷網際網路公司。紐交所，納斯達克市場70%的交易都是來自於機器自動化交易，其中的高頻交易系統更是大行必備之精良高階武器。如果你記得某年某月某日某行某Trader的彈指神功(Fat Finger)，使得道瓊斯指數分分鐘閃崩1000餘點（近10%左右），這可不是其頭寸足夠大，而是明顯是機器系統演算法的連鎖反應導致的雪崩效果啊。不誇張的講，整個華爾街都執行在IT系統之上，如果IT交易系統出個bug打個噴嚏，全球市場都要震盪一下。

各大行中，IT系統則又以大摩，前雷曼兄弟的基礎設施著稱，高盛則自成一派，從開發語言到資料庫都是自創，架構方面則從一開始就大統一，所有交易資料都在其核心資料庫中，所有後續的風控，清算，對衝，財務，監管，報表等都無後顧之憂。其它各行則少則數十，多則數百系統，各種交易資料傳來傳去，複雜異常。而成就大行這些頂級設計的則是全球頂尖名校的精英人才，不乏來自各數學，物理，計算機的P.h.D，更有甚者直接憑請業界大師，如大摩把Java之父招至靡下從而發揮其磁吸作用。

平臺業務

本文以某大行的Global Market Data（市場資料平臺）來探討其內部交易系統的基石，市場資料平臺。之所以稱之為定海神針，是因為所有的交易少不了市場資料，報價等支援，如外匯（FX），Rates, Credit, 當然此係統主要支援固定收益以及外匯交易（股票市場資料在各行中一般有獨立系統支援）。固定收益交易及外匯佔了全球交易量的2/3，其交易量之大可見一斑。每日全球產生的市場資料超過千萬，包括實時Ticker（報價）資料等。

交易樓層（Trading Floor）

作為投行重要的底層基礎支柱之一，衡量其重要可用及成功因素包括如下：

業務需求

• 支援高併發，高吞吐，快速訪問，查詢市場資料，並且資料可以持久化儲存

• 支援全球多個數據中心，臨近訪問，資料中心之間資料一致性

• 支援多個數據中心之間高可用HA 7*24, 自動Failover

• 支援低延遲實時市場資料報價訪問

• 支援歷史資料訪問查詢

• 支援客戶端多種協議訪問，如RPC, REST, Web, .Net, Excel等

• 支援實時系統狀況監控，自動運維／部署平臺

資料需求

• 主要資料來源更新來自路透社（Thomson Reuters），彭博(Bloomberg)，各大期貨交易所如CBOT（芝加哥期貨交易所）等。

• 每日新增市場資料大概20g；

• 每日新增Snapshot／EOD大概20-40g；

• 系統需要在快取中維護1-2個月的EOD Sanpshot，大概100-150g左右；

• 每日全球市場報價資料流量為20-100g，當然大多數是Ticker, 其中高頻段為100000次／分更新，或者高峰達到1500-10000次／秒更新（Ticker資料多為機器策略交易提供服務，無須持久化）總體來看，快取需要支撐大概200g左右，考慮到資料安全性及冗餘，共需要500g左右。

聽起來每個需求都合情合理，然而如果你是架構師，請問如何下手？筆者也並非此係統原始架構師，而平臺也早已經過多年自然演進，我們今天嘗試庖丁解牛，倒序分析，一步步逼近事實真相。另因涉及敏感資訊，一些名稱／架構等進行脫敏，但保留整體設計思想。

架構設計產品選型

根據上述之需求，其實我們大體可以想到方向應該是分散式 ＋ 快取 ＋ 資料庫／檔案＋資料倉庫／大資料分析等。

目前業界比較成熟，流行的大型分散式快取有Oracle Coherence, GemFire, Redis, Memcached以及Apache Ignite等，我們用表格羅列對比分析其主要特性。

分散式快取比較

其實，按照上述業務及資料需求分析，首先排除Ignite, 為啥？2014年才誕生，來不及啊。拋開時間不談，Ignite誕生於大資料時代，天生與Hadoop, Spark有著良好的整合，冉冉新星。

對於Redis這把“瑞士軍刀”，我們想要的需求大多可以滿足，可惜在3.0前無法很好支援服務端叢集以及全球化多站點部署，Memcached之鋒利則更適用於網際網路快取；

剩下的Coherence與Gemfire，集王者之大成，如何選？其實，Gemfire已於早些年大舉進軍華爾街，全心專注投行需求，如全球化多站點部署等，同時又與時俱進，從平行計算到MapReduce無所不能，2008金融危機後，更是激流勇進，壟斷大行快取平臺，據統計全球2/3以上的Gemfire服務運行於華爾街。

Gemfire水到渠成，況且在大公司有時候很多產品策略早已定好（基於產品的成熟性，可用性以及可維護性）。好的產品是成功基石，至於後來被證明在“全球最大線上交易系統12306”中卓越表現也再次被證明，然而一個好產品也並非萬能可以適應所有場景。

支援資料高併發快速訪問及持久化

高併發，快速訪問是採用快取的主要目的之一。而要做到這些必須對我們應用的需求瞭解，對我們的資料進行妥善管理，正所謂知己知彼才能百戰不殆。

 資料管理

資料管理的首要問題包括如瞭解應用需要管理多少資料， 如100g；資料型別及大小，如文字，500k檔案大小；資料之間有依賴否？資料的生命週期，如是否需要持久化等。另一方面，我們也需要了解這些資料會如何被使用，如多少併發客戶，使用者訪問資料的模式，如持續查詢還是事件訂閱等。

我們來看一張圖表來梳理一下：

快取資料分析

資料容量

對於我們市場資料快取的需要，上文分析大概需要200g左右，考慮到資料安全性及冗餘，共需要500g左右。

至於磁碟與資料庫持久化的容量，磁碟應該不是大問題，資料庫則每個資料中心實時資料庫需要500g到1T以上，歷史資料庫則5T - 10T左右，實時資料庫需要定時定期歸檔。

伺服器規劃

對於64位的平臺(Linux)，考慮到目前作業系統實際能支援的記憶體為大概192G左右(理論上限為16.8TB)，以及JVM GC（1.6/1.7）本身推薦管理記憶體大小，我們設定一個Data/Snapshot節點記憶體為10-16g，則單一資料中心一共需要30-50個nodes，3臺物理伺服器作為資料伺服器；

值得注意的是，建議上述伺服器作為資料專用伺服器，資料與其它應用分離，便於擴充套件同時也更加避免相互影響，尤其分散式中各服務需要相互通訊。

資料冗餘

資料冗餘方面，如果對資料有嚴格容錯要求，建議採用3個備份（基數），3是個神奇的數字，即做到了資料的充分備份可靠，又兼顧了資源。當資料出問題時候，一個copy可以用來恢復資料，另一個可以繼續實時服務。鑑於我們市場資料主要以報價以及EOD為主，我們採用1個數據冗餘即可（省錢），當然即便如此，後來也遇到了非常艱難的效能及穩定性問題，我們先埋個伏筆。

資料分割槽

有了資料的叢集，儲存無憂。然而想要做到支援高併發，低延遲訪問，資料佈局的內功不可少。分散式快取中較常用的資料分割槽有Partioned與Replicated。Replicated分割槽適用於資料量相對較小但高頻讀的資料，其資料會自動映象到所有叢集member；Partioned則適用於通常大資料量，寫相對要求高，內部則劃分成類似ConcurrentHashMap的Bucket或者Redis中的Hash Slot來儲存。

按照此思路，我們將一些常用的配置資訊作為Replicated來儲存，而真正市場資料則用Partioned分佈到各個節點存放。

 資料持久化

磁碟持久化

資料持久化，我們需要支援快取的Overflow to Disk以及資料庫的持久化。磁碟持久化大多數分散式快取已經支援做到LRU演算法，並且支援磁碟get/put等操作，需要配置一些Eviction的觸發閥值，閥值觸發後根據LRU演算法把最近最少用資料移除記憶體快取放置到磁碟。

資料庫持久化

至於快取資料庫的持久化，經典的演算法大概分為Write-Through與Write-Behind。

Write-Through主要是指當更新完快取資料後，系統會同步更新資料庫，直至全部完成結束。

Write-Through Cache

可以看出Write-Through可以精確做到資料的一致性，當然其帶來的弊端是會影響效能。

Write-Behind 則指當更新完快取資料後，系統把更新寫入訊息中介軟體或者佇列，無需等待最終更新至資料庫即返回，隨後由訊息中介軟體延遲更新至資料庫。

Write-Behind Cache

Write-Behind所採用的資料策略為最終一致性（Eventual Consistency）, 在帶來效能提升的同時，當然需要承擔一定資料丟失以及延遲的成本。

多數分散式快取系統也同時提供了快取資料的監聽器（Listener）便於定製化實現資料更新通知，以及其它如Write-Behind更新策略。下圖為Gemfire/Geode快取監聽器，提供了before/after事件。通常可以使用Cache Writer來實現Write-Through策略，使用Cache Listeners來實現Write-Behind策略。

Cache Listener

考慮到市場資料的敏感及時效性，以及持久化主要以報表，分析，歸檔為主，所以我們的採用EMS訊息中介軟體來實現Write-Behind快取更新策略。

支援全球多個數據中心，臨近訪問，資料中心之間資料一致性 四大中心

這個需求是大行的入門級，分行分佈全球，通常需要搭建紐約，倫敦，東京，香港／新加坡等4地作為資料中心，做到4地皆可訪問當地應用，資料中心之間資料則需要相互備份，如果某個資料中心出問題，自動切換至其他幾個資料中心，做到全球24小時不間斷交易，事實上正如全球市場一樣，澳洲，東京最早開市，隨後香港／新加坡，當亞洲閉市後倫敦開市，隨後紐約開始直至第二天。

全球多資料中心（WAN）

上圖為全球多資料中心的事例，我們系統需要做到支援4個數據中心（倫敦，紐約，東京，香港）。

各種分散式快取產品大都支援全球多資料中心（WAN）結構，資料中心多個Site之間的通訊協作配置，Gemfire/Geode的多資料中心即本配置如下圖。

WAN Site XML配置資訊

其中每個資料中心自成分散式叢集，資料中心之間則通過上述基本配置來連線共享。

 資料通訊

各個資料中心之間則通過Locator，Sender, Receiver來實現TCP/IP發現，非同步通訊，Replication等，每個資料中心或者叢集既有Sender作為傳送端也有Receiver作為接受端。

Sender通過Locator定位到遠端叢集的Locator，遠端Receiver則接受請求併發送遠端host／port資訊。也可配置多個並行Sender（Parallel Gateway Sender）。

WAN Sender / Receiver

而且內部則使用Queue作為快取非同步通訊渠道，通過Ack機制，兩個資料中心保證了資料的完整性，同時Queue則化同步為非同步，提升效率同時接耦合，一個數據中心出問題不會影響其它資料中心。多個數據中心可以通過環路或者全網路拓撲來連線。

通常垮多個數據中心，比較棘手的問題主要有如何在併發下保證資料一致性以及本身由於垮WAN導致的資料延遲性。

 資料一致性

多資料中心採用最終一致性策略來保證多資料中心資料的統一，預設情況，在多個數據中心併發更新某一Entry的情況下，系統會根據事件的時間戳選擇較新的更新作為最終資料；極端情況下，如果完全相同時間戳，則預設會各自選擇遠端的更新（有可能導致資料不一致）。系統也可以自己定義策略來選擇更新。

鑑於市場資料的精準性要求，我們從業務上規定某一種資料在某一個數據中心為主，即定製衝突優先順序策略來解決。

 資料延遲性

跨全球資料中心的資料傳輸，Replication往往受限於多種因素，如網路，流量以及本身傳輸大小等，從毫秒到數秒不等，資料延遲性面臨很大挑戰和不可控。

然而令人略微欣慰的是，業務上面每個資料中心大多隻需要自治，如東京開盤時間主要訪問東京資料中心獲取市場資料為主；每個資料中心只要在每日閉市後，把當日的EOD資料同步Replicated到全球其它資料中心即可，延遲性方面還好。

然而考慮到全球外匯市場主要以倫敦為主（外匯中心），東京，新加坡很多FX系統需要實時市場報價，目前方案有兩種：

其一，對於延遲性要求略微低一些的系統，直接連線倫敦資料中心。

其二，對於實時報價等低延遲資料則通過TIBCO RV（Rendezvous） Routing通過UDP協議，犧牲可靠性從而達到高實時性需求，直接從倫敦路由東京，東京到香港之類的。TIBCO公司的兩大旗艦產品EMS和RV專攻訊息中介軟體，RV則採用UDP協議適合小訊息，高實時性場景。使用TIBCO RV Reliable模式已經可以做到訊息釋出150萬/秒，50萬/秒接受的效能。

TIBCO RVRD（Rendezvous Routing Daemon）

按照如上兩種解決方案，目前暫時可以應對業務需求。

高吞吐，低延遲實時市場資料報價 高吞吐

吞吐量

系統初期為幾個主要系統訪問，幾年下來大客戶有10-20+個高頻系統，另外有其它10-20+多個普通系統（如報表，批處理等）訪問，以及大概有幾千個個人使用者通過定製瀏覽器來訪問。其中高頻系統包括高頻讀／寫操作，個人使用者主要只讀查詢為主。初期以為資料更新主要來自上述路透社，彭博以及全球期貨交易所，後來發現內部系統也進行海量資料釋出訂閱，釋出內容則主要是內部經過分析，修正的資料版本, 這樣一來資料量相當於數倍增長。

事件驅動架構（Event-Driven Architecture）

在系統平臺整體架構方面，我們採用了事件驅動架構，引入TIBCO EMS訊息中介軟體來作為跨系統通訊，在解耦同時做到了系統整合。

Event-Driven Architecutre

如果問為何選用EMS，而非MQ，RabbitMQ, 以及後起之秀Apache Kafka，這個問題麼介於公司本身策略以及TIBCO雙雄本身也功夫過硬。

在高吞吐大併發下，EMS Queue同樣可以大有作為。系統設計了幾十個Queue，分別用於資料查詢，資料更新，訂閱，釋出，EOD，甚至跨資料中心資料Replication,以及若干JDB Queue用於Write-Behind同步資料庫。可以看到，系統使用更為強大，成熟的中介軟體產品來保證平臺穩定性，吞吐。

 低延遲

大多數時間，系統需要支撐QPS集中在幾百至幾千，甚至高峰上萬，這些都是記憶體網格（In Memory Grid）快取的優勢。有某統計網站公佈資料如Gemfire 8在4個節點內嵌模式下，4G Heap, 1G頻寬，10個Threads10分鐘的平均簡單讀操作可達70000/秒，寫平均為23000/秒。

市場資料對於資料敏感性較高，查詢一般都是毫秒級別的，尤其對於依賴市場資料的自動交易系統，如FX等。曾經聽到一個段子，一投行高管說，如果一個經紀人或者Trader使用的自動交易平臺比對手慢5毫秒，則整體收益（Revenue）可能會損失1%，或者百萬美金每秒（包括了利潤加成本）。有點驚人誇張，但足以見得資料低延遲的重要性，同樣由於很多交易系統依賴於我們市場資料平臺，低延遲對於市場平臺的成功至關重要。

現實中，我們也遵循墨菲定律確實遇到問題導致延時超過幾分鐘，還好處理及時，15分鐘左右定位，恢復，但也造成了大級別的生產事故，時間就是金錢啊，對於過去的報價，交易系統會很敏感。

資料分割槽

對於一些高頻資料的查詢，我們在系統資料分割槽層面架構得當，叢集資料配置為Replicated, 叢集中任何一個數據節點都包含該快取資料，對於叢集Client端（非終端客戶／系統）也保留了一份客戶端快取，所以整體效能優異。

效能優化

對於其它絕大多數分散式快取資料，則為分割槽儲存。如果是簡單get(Key)，那麼整個世界都是官方資料。現實中的查詢，遠遠要比get複雜，包括許可權校驗，資料校驗，基礎資料關聯，其它關聯資料查詢，資料過濾等，受限於KV快取功能，而有些高階快取已經支援OQL，SQL，甚至索引（Index）, 當然至於索引如果資料只讀或者低頻更新則利器一把，否則要承擔更新額外負擔。

Map／Reduce

除此之外，分散式除了分散式儲存當然也要發揮其平行計算，MapReduce之功力。

MapReduce Execution

大多分散式快取都支援分散式計算／查詢，通常可以把複雜計算，查詢封裝成函式，部署或者動態分發到叢集執行計算。效率方面，分別部署至各個節點可能效率更高，而動態分發則保持了更好的隔離與解耦，當然由於需要序列化則犧牲了部分效能（多數分散式系統會重新實現自己序列化或者使用如Apache Thrfit之類的框架避免Java自身的序列化較低效率）。

持續查詢／訂閱

持續查詢或者訂閱（Subscribe）傳送實時報價資訊給訂閱系統使用者也另外一種變相減少查詢延遲吧。

廣播／多播網路

另外一種對資料延遲性的極致做法是引入高效廣播／多播網路，如我們上文提及的TIBCO RV，注意其釋出訂閱實現方式並非與熟悉的MQ／JMS模式，其創新的建立了資訊虛擬共享匯流排（TIB）。

RV並沒有採用傳統的基於佇列Queue的服務端快取設計，直接在IP層廣播／多播方式把訊息傳送到RV網路上，並通過UDP協議路由廣播推送到RV網路所有節點，接收端則通過Subject來匹配接受訊息並快取至客戶端佇列。與傳統MQ／JMS在服務端通過Topic來快取至訊息佇列的做法比，速度快多了，當然在享受飛速同時也需要承擔訊息丟失的風險。而對於市場實時報價來說，是可以容忍的。

另外RV也提供了RV Reliable 模式，通過自定義實現擴充了UDP協議，新增訊息包檢查與重傳機制，保證了一定程度的傳輸可靠性。還有RVCM模式，則更進一步，新增訊息確認機制，保證傳輸可靠性。當然這兩種模式的效能自然下降，正所謂魚和熊掌不可兼得也。

 高頻寫

系統碰到了關於高頻寫導致的異乎尋常的難題。上文提到的使用TIBCO RV來實現的廣播另闢蹊徑，然而與此同時這些高頻資料也需要寫入分散式快取供後續使用。

然而始料未及的是大多交易／釋出系統習慣併發同時開幾十至上百個執行緒同時釋出，更要命的是很多幾乎所有系統設定在每週／每天開市前如7點整點發布寫／查詢，造成了瞬間秒殺的功效。下圖是系統某天3分鐘的寫資料量統計，可以看到從第二分鐘開始高頻寫，top 3加起來有171000筆，由於系統統計是按照分鐘來統計，所以粗略估計每秒寫操作接近2800-17000+（注我們這裡的寫操作並非單純的寫操作，內部隱含了多步驟的業務邏輯），不亞於黑客攻擊，而這種高頻寫的壓力嚴重時會直接影響整個叢集的穩定性。

而這都是一個強大系統所需要經歷的痛苦過程，無需也無法從一開始就設計考慮到。

高頻寫TOP-3 In 3分鐘

這又是一個血淋淋的真實案例，目前其實仍在奮鬥解決中。但通過分析Thread Dump, GC log, 分散式快取Debug Level日誌，大致定位到是由於高頻寫的同時，資料需要做同步冗餘備份與其它節點通訊，當整個叢集的所有節點都處於高頻通訊，互動時，所有節點異常繁忙，很多節點處於等待Ack狀態，無法接受響應更多請求，致使很多節點看起來反應遲鈍甚至Hung在那裡導致從叢集中被強制Depature。

方案

目前的臨時方案時，節點等待ACK超時強制丟擲異常並釋放資源，緩解整個叢集壓力。

另外準備嘗試重新規劃資料分割槽，針對高頻寫／更新資料無須Redundancy Copy以減少節點間的通訊，以及採用網路中常用的限流漏桶演算法(Leaky Bucket)或者更適合分散式KV更新演算法Conflation歸併演算法。

Conflation演算法示例

分散式環境在獲得海量儲存，高效平行計算效能的同時，同時也帶來分散式問題除錯排查的異常複雜。

高可用HA, 自動Failover

高可用（HA High Avaiablity）通常包含系統服務高可用以及資料高可用，通常慣用做法是空間換時間-冗餘，不管快取資料，服務還是哨兵，資料庫，甚至資料中心。

 高可用資料

資料的高可用在分散式中的通用做法是資料冗餘（Redundancy Copy）了，可以冗餘1-3甚至多分備份。經驗來看1分冗餘通常已經足夠，如果對於資料完整性有嚴格要求則3份足矣，同時當主資料出問題時，備份1可以用來使用同時備份2則兼顧資料恢復。然而備份畢竟是資源，對於資金以及效能都會造成影響。

 高可用服務

對於一個數據中心通常做法也是開啟多個相同服務，通過反向代理（如Nginx），雙機熱備（Keepalived，DR）或者負載均衡（F5，LVS）來實現負載以及高可用，叢集內部節點則通過同時開啟多個Locator避免單點，包括選主演算法等。

 Failover

對於Failover，通常叢集內部都有各自的恢復方式，如同步／非同步資料備份恢復，重新選主，節點隔離等。

叢集之間要求比較高的話通常會設定熱備份叢集／資料庫，我們平臺則每個資料中心額外設定DR（災備）叢集。

系統Failover

多數系統／叢集Failover依賴人工干預，其原因並非無法做到自動failover，而大多是還沒有智慧到識別，快速，平滑切換。

通過雙機／雙叢集來災備雖然資源消耗較大，且大多數時間處於資源浪費狀態，然而對於金融交易來講，這是必須和必要的投入。

跨資料中心的Failover則更加智慧，抵抗風險，目前已經列入未來目標之一。

 訊息中介軟體

訊息中介軟體在高可用中同樣扮演舉足輕重的角色，當某些服務，資料庫不可用時，訊息中間則充當臨時的載體，避免訊息，事件及資料的丟失，這也是為什麼訊息中介軟體在金融機構被廣泛採用的原因之一。

支援歷史資料訪問查詢

市場的歷史資料雖然對於實時交易系統意義不大，但是對於很多交易策略，分析系統則意義非凡，經常需要獲取若干時間段的歷史海量資料資訊。

對於海量歷史資料的管理，查詢，使用則成為我們系統的一大挑戰。傳統的關係型資料庫無法很好支援支撐海量資料，即便是資料倉庫或者Cube也必須預先定製，很難做到實時使用。

我們的方案當然是借力於大資料平臺三兄弟 HBase + HDFS／Hadoop + ZooKeeper。

ZK + HBase + Hadoop/HDFS

值得慶幸是，由於我們的平臺採用異構事件驅動架構，我們只需要在資料儲存模組新增一個HBase訊息佇列，通過介面卡直接儲存至HBase，並不會對目前平臺功能及效能造成衝擊，之後則開發開放新的API供其它系統使用即可。目前該平臺仍在開發測試中。

支援客戶端多種協議訪問 事件驅動架構

在整個平臺的架構中，事件驅動架構本身為平臺異構，解耦，已經可以做到與各種平臺，語言，系統通訊，對接。

 RPC-X

在投行的資訊基礎設施部門，又把這個往前邁了一大步。研發了內部RPC或者SOA平臺框架，整合所有部門的系統之間的通訊，我們暫且稱之為RPC-X好了。

其技術架構設計因敏感性原因，不細述了。其大致目標是整合公司內部系統之間的通訊，包括跨平臺如Unix, Linx, Windows等，以及跨語言C/C++, Java, .NET等。

其功能涵蓋了：

-系統之間RPC通訊

• 封裝公司內部訊息中介軟體平臺通訊細節

• 封裝公司內部各個Region, 資料中心通訊細節

• 封裝地理，時區資訊

• 提供集中配置服務目錄管理，無須每個服務／客戶端配置

• 跨平臺，跨語言通訊

• 系統之間高可用及Failover

• 提供Event Bus服務

• 相容OSGi

• 提供RPC, EMS, RV, REST, Broadcast, On-demand, Monitor, Subject

實時系統狀況監控，運維／部署

系統監控，自動運維是從另一方面評估系統平臺成熟度的指標之一。

 系統監控

市場資料平臺除了有預設分散式叢集產品Gemfire/Geode自帶的叢集監控，快取效能監控等工具為，也自主研發看板（Dashboard）實時監控所有資料中心叢集中的節點服務狀況，EMS訊息佇列，記憶體使用，CPU使用，Heartbeats，磁碟，資料庫等每個元件的健康狀況。

 系統運維

系統運維屬於公共平臺，基礎設施部門也有自行研發自動化部署平臺，可以實時動態按照環境部署至全球各個資料中心，並監控每個元件執行狀況，甚至配置管理每個元件的執行時區及Sheduler。

另外，各自平臺系統層面，也會主動暴露一些JMX介面以便線上動態調整運營策略及應對各種突發事件。

目前來看，運維距離自動運維及DevOps還有距離。

寫在最後

簡單介紹 ，嘗試模擬倒序分析，架構了分散式市場資料平臺，傳統金融系統平臺的需求有著其天然的特殊性與複雜性，無法完全對比網際網路平臺，然而在技術的海洋裡則互通。相信隨著金融監管放鬆的預期及持續創新，金融與網際網路頂級技術，大資料，雲端計算，容器，區塊鏈，AI，深度學習等技術將會更佳完美結合。

作者介紹

郝星宇（Erix），現就職於Nomura擔任技術VP職務，2004年至2015年曾就職於Citi，參與技術研發並擔任技術VP等職務。關注金融系統技術架構及前沿技術，曾參與包括保險，操作風險，信用風險，信貸系統，銀行壓力測試及固定收益類相關係統平臺設計及研發。個人技術公眾號「技術極客TechBooster」。