投行交易系统的定海神针

作者｜郝星宇

编辑｜小智

近年来，一个名叫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」。

不想与智能物联网大潮失之交臂、不想与Huawei LiteOS形同陌路、不想你的编码人生碌碌无为、不想你的好创意烂在肚子里…那就点击文末 「 阅读原文 」报名，参加1月7日-8日在北京由华为主办、InfoQ协办的Huawei LiteOS黑客松大赛吧。叫上你的小伙伴，来一场2天1夜的疯狂。 （或者识别以下二维码直接报名。）

今日荐文

点击下方图片即可阅读

是「技术」还是「业务」在驱动公司的发展？这个队你怎么站？