卷2：第24篇 ZeroMQ.pdf

卷2 ：第24章 ZeroMQ 原⽂链接：http://www .aosabook .org/en/zeromq .html ØMQ是⼀个消息通信系统，如果你愿意的话也可以称其为“⾯向消息的中 件” 。 ØMQ的应⽤环境很⼴泛，包括⾦融服务、游戏开发、嵌⼊式系统、学术研究以及航空 航天等领域。 消息通信系统完成的⼯作基本上可看作为负责应⽤程序之 的即时消息通信。⼀个应 ⽤程序决定发送⼀个事件给另⼀个应⽤程序 （或者多个应⽤程序），它将需要发送的 数据组合起来，点击“发送”按钮就⾏了——消息通信系统会搞定剩下的⼯作。 不同于即时消息通信的是，消息通信系统没有图形⽤户界⾯，并假设当出现错误时， 对端并不会有⼈为⼲预的智能化处理。因此，消息通信系统必须既要有⾼度的容错 性，也要⽐⼀般的即时消息通信更快速。 ØMQ最初的设想是作为股票交易中的⼀个极快速的消息通信系统，因此重点放在了⾼ 度优化上。项⽬开始的头⼀年都花在制定性能基准测试的⽅法上了，并尝试设计出⼀ 个尽可能⾼效的架构。 之后，⼤约是在项⽬进⾏的第⼆年⾥，开发的重点转变成为构建分布式应⽤程序⽽提 供的⼀个通⽤系统，⽀持任意模式的消息通信、多种传输机制、对多种编程语⾔的绑 定等等。 在开发的第三年⾥，重点主要集中于提⾼系统的可⽤性，将学习曲线平坦化。我们已 经采⽤了BSD套接字AP ，尝试整理单个消息通信模式的语义等等。 本章试图向读者介绍，ØMQ为达到上述三个⽬标是如何设计其内部架构的，也希望给 同样⾯对这些问题的⼈提供⼀些启⽰。 启动ØMQ项⽬的第三年⾥，其代码库已经膨胀的过于庞⼤。有⼀项提议要标准化 ØMQ 中所使⽤的协议，以及实验性地实现⼀个类ØMQ的消息通信系统以加⼊到Linux 内核中等等。不过，本书并未涵盖这些主题，更多细节可以参 考：http://www .250bpm .com/concepts ，http://groups.google .com/group/sp-discuss- group ，和http://www .250bpm .com/hits 。 24.1 应⽤程序 vs 程序库 ØMQ是⼀个程序库，不是消息通信服务器。我们花了好⼏年时 在AMQP上，这是⼀ 种在⾦融⾏业中尝试标准化⽤于商业消息通信的协议。我们为其编写了⼀个参考性的 实现，然后部署到⼏个主要基于消息通信技术的⼤型项⽬中使⽤——由此我们意识 到，智能消息服务器 （代理/broker ）和哑客户端之 的这种经典的客户机/服务器模型 是有问题的。 当时我们主要关⼼的是性能：如果中 有个服务器的话，每条消息都不得不穿越⽹络 两次 （从发送者到服务器，然后从服务器再到接收者），还附带有延迟和吞吐量⽅⾯ 的损耗。此外，如果所有的消息都要通过服务器传递的话，某⼀时刻它就必然会成为 性能的瓶颈。 第⼆点需要关⼼的是关于⼤规模部署的问题：当消息通信需要跨越公司的界限时，这 种中央集权式管理所有消息流的概念就不再有效了。没有⼀家公司愿意把对服务器的 控制权放在别的公司⾥，这包含有商业机密以及法律责任相关的问题。实际结果就是 每家公司都有⼀个消息通信服务器，可通过⼿动桥接的⽅式连接到其他公司的消息通 信系统中。因此整个经济系统被极⼤的划分开来，但是为每个公司维护这样⼤量的桥 接并没有使情况变得更好。要解决这个问题，我们需要⼀个分布式的架构。在这种架 构中每⼀个组件都可以由⼀个不同的商业实体来管辖。鉴于基于服务器架构的管理单 元就是服务器，我们可以通过为每个组件设置⼀个单独的服务器来解决这个问题。在 这种情况下，我们可以通过使服务器和组件共享同⼀个进程来进⼀步地优化设计。我 们最终得到的就是⼀个消息通信的程序库。 当我们开始设想⼀种不需要中 服务器的消息通信机制时，也就是ØMQ项⽬开始之 时。这需要⾃下⽽上的将整个消息通信的概念颠倒过来，将位于⽹络中央的集中信息 存储模型替换为基于端到端机制的“智能型终端，沉默化⽹络”的架构。正是由于这样 的技术决策，ØMQ从⼀开始就作为⼀个库⽽存在，它不是应⽤程序。 同时，我们也 已经证明了这种架构更加⾼效 （低延迟，⾼吞吐量）也更加灵活 （很容易在此之上构 建任意复杂的拓扑结构，⽽不必拘泥于经典的中⼼辐射模型）。 然⽽选择以库的形式发布，这其中还有⼀个意想不到的结果，那就是这么做提⾼了产 品的可⽤性。⽤户反复地表⽰由于他们不再需要安装和管理⼀个独⽴的消息通信服务 器了，为此他们感到很庆幸。事实证明，去掉中 服务器是⾸选⽅案，因为这么做降 低了运营的成本 （不需要为消息通信服