出色的通信机制

在由分布式组件构成的系统的架构设计中，还有另一个非常重要的方面，就是组件之间如何相互通信。每一个高频交易系统的设计者都必须认真地考虑这个问题。在组件之间传递的数据称为信息( message )，而这些负责信息交互的机制则被称为系统的通信基础设施。信息在某些时候也称作事件( event )，高频交易系统和其他一些与事件的交互联系紧密的系统也称作事件驱动( event-driven ) 系统。在这类系统中，任务并没有清晰定义的开端和结束。组件初始化之后就会一直处于等待状态，直到某些特定的事件发生(或者说某些特定事件的到达)，然后通过一些确定的机制对其做出反应，并触发一些会引发其他组件反应的事件，系统就这样循环往复地运行下去。"发布与订阅" ( pub-sub ) 是一个非常流行的通信机制。在这个机制中，组件被定义成消息的发布者、消息的订阅者，或者同时是消息的发布者和订阅者。例如， 一个市场行情数据组件会负责把从外部接收到的实时行情在系统中发布；而另一些组件， 比如定价引擎组件， 则会是这些实时行情的订阅者。为了实现这个机制，系统通常会维护某种形式的消息类型目录， 有时也被称作标签( tag )或者话题( topic ) ， 组件必须在发布或订阅消息之前进行登记( 一个单独的组件通常不会既是一个标签的发布者，又是同一标签的订阅者)。

一个很容易想到的类比是杂志。出版商发布各种各样标题的杂志， 而家庭客户则会订阅他们感兴趣的标题， 当新的杂志出版的时候，它们被各向投递给不同的订阅者( 一个杂志出版商同样会订阅其他的杂志来对市场上的竞争形势保持关注)。另一个类比则来自于微生物领域，不同的细胞会通过细胞膜分泌不同的化学物质，而细胞膜也允许一些特定的化学物质通过它而进入细胞。这种机制让细胞能够只得到它们想要的物质，而不论其他的细胞分泌了多少种不同的东西。这很像一个通过"发布和订阅"机制来进行通信的系统内部所发生的事情，就像我们在图4-1 中描述的那样，一些类型的消息被允许进入某个组件，而其他的消息则进不去。

这种"发布与订阅"的模式得到了广泛的接受和应用，不过实现这种机制则有多种不同的方法。在这里，我们恰好找到了一个例子能够证明， 事实上不少高频交易系统的需求都能够通过第三方软件商提供的解决方案得到很好的满足。当然，一些高频交易公司总是想要自己构建系统的通信基础设施，但有一些很成功的公司通过把这项工作交给软件提供商，也很好地完成了这一部分的任务。这个领域中最著名的一个例子是由Tibco 公司提供的叫做Rendezvous 的产品。这个名声显赫的产品已经存在很多年了，而且我认为基本上可以说至少有一半的高频交易公司的系统核心中都能看到Tibco 公司产品的影子。但Tibco 公司在这个行业中还算不上垄断者， 比它更年轻的公司，例如29West 和Tervela ( 我们会再次提到这家公司) 都在这个领域向Tibco 发起了挑战。

而在系统通信中， 需要做出的另外一个重要选择是消息应该如何从一个组件发送到另一个组件。一种方法是在两个组件之间建立一个直接且无中断的连接，即TCP/IP 套接字。这就像是和另外一个人的直接电话线连接一样， 这种电话连线只对你和对方开放， 并且总是处于畅通状态。这种排他性， 正是信道连接被认为是两个组件之间最可靠的通信方式的重要原因之一。但它天生就只是一种一对一的解决方案，当成百上千个组件需要互相通信时，在每一对可能发生信息传递的组件之间都建立套接字显然是一种笨拙得可怕的办法。

组播( multicast )是一种流行的替代方案。在这种方式下， 一个信息发布组件通过网络将消息经由广播的方式发布出去，这个消息并没有特定的订阅者，它仅仅是像无线电天线一样把消息扩散出去，而是否接收消息则是那些可能需要订阅这个消息的组件的任务了。如果一个组件想要接收一个组播信息，它必须使用接收天线来对消息进行监听( 网络中的路由器必须经过一定的设置来保证组播信息能够最快地到达接收者)。组播是一种很实用的同时向多个订阅者发送消息的方法，但它并非一种传统的可靠性很强的消息传递机制。组播无法提供TCP/IP 套接字的可靠性来保证某条消息、能够一次就发送到其订阅组件，就像通讯公司无法保证你拨出的第一个电话就能拨通一样。不过TCP/IP 套接字和组播并不是仅有的通信机制选项，高频交易系统的设计师也的确会花上不少时间在不同的选项之间进行权衡，试图选出最合适的通信机制。