本文主要是探究学习比较流行的一款消息层是如何设计与实现的
ØMQ是一种消息传递系统，或者乐意的话可以称它为“面向消息的中间件”。它在金融服务，游戏开发，嵌入式系统，学术研究和航空航天等多种环境中被使用。
消息传递系统基本上像应用程序的即时消息一样工作。应用程序决定将事件传送到另一个应用程序（或多个应用程序），它组装要发送的数据，点击“发送”按钮，消息传递系统负责其余的事情。然而，与即时消息传递不同，消息传递系统没有GUI，并且在出现问题时，在端点处没有人能够进行智能干预。 因此，消息系统必须是容错的并且比常见的即时消息传送快得多。
- ØMQ最初被构想用于是一个针对股票交易的极速的消息传递系统，所以重点是极端优化。该项目的第一年用于设计基准方法，并尝试定义一个尽可能高效的架构。
- 后来，大约在第二年的发展时，重点转向了提供一个通用系统，该系统用于构建分布式应用程序和支持任意消息模式，多种传输机制，任意语言绑定等。
- 在第三年，重点主要是提高可用性和扁平化学习曲线。 我们采用了BSD套接字API，试图清除单个消息模式的语义，等等。
Application vs. Library
ØMQ是一个消息库，而不是一个消息服务器。我们花了几年时间研究AMQP协议（一个金融行业尝试标准化企业消息传递的有线协议），为其编写参考实现并参与了好几个大规模的基于消息传递技术的大型项目，并最终意识到意识到使用经典客户端/服务器模型的智能消息传递服务器（代理）和哑消息传递客户端的方法有问题。
我们首要关注的是性能：如果中间有一个服务器，每个消息必须通过网络两次（从发送方到代理，从代理到接收方），这在延迟和吞吐量方面都会有一定代价。 此外，如果所有消息都通过代理传递，在某一时刻，服务器必然成为瓶颈。
次要关注的是大规模部署：当部署跨组织（如：公司等）时，管理整个消息流的中央授权的概念不再适用。由于商业秘密和法律责任，没有公司愿意将控制权交给不同公司的服务器。在实践中的结果是，每个公司有一个消息服务器，用桥接器连接到其他公司的消息传递系统。整个系统因此严重分散，并且为每个涉及的公司维护大量的桥接器不会使情况更好。为了解决这个问题，我们需要一个完全分布式的架构，该架构中每个组件都可能由不同的业务实体控制。考虑到基于服务器的架构中的管理单元是服务器，我们可以通过为每个组件安装单独的服务器来解决上述问题。在这种情况下，我们可以通过使服务器和组件共享相同的进程来进一步优化设计。这样我们最终得到一个消息库。
我们已经能够证明这种架构比标准方法更高效（更低的延迟，更高的吞吐量）和更灵活（很容易构建任意复杂的拓扑，而不是限定为经典的hub-and-spoke模型）。
其中一个出乎意料的结果是，选择库模型改善了产品的可用性。 一次又一次，用户因不必安装和管理独立的消息服务器而感到开心。 事实证明，没有服务器是一个首选项，因为它降低了运营成本（不需要有一个消息服务器管理员），并加快上线时间（无需与客户协商是否运行服务器，以及管理或运营团队的问题） 。
Global State
全局变量不能很好地与库交互。 即使只有一组全局变量，库可能在进程中也会加载多次。 图1显示了一个从两个不同的独立库中使用的ØMQ库的情况。 然后应用程序使用这两个库的示例
图１: ØMQ 库在两个不同的独立库中被使用
当这种情况发生时，ØMQ的两个实例访问相同的变量，导致竞态条件，奇怪的错误和未定义的行为。为了防止这个问题的出现，ØMQ库中没有全局变量。相反，库的用户负责显式地创建全局状态变量。包含全局状态的对象称为context。 虽然从用户的角度来看，context看起来或多或少像一个工作线程池，但从ØMQ的角度来看，它只是一个存储任何我们碰巧需要的全局状态的对象。在上图中，libA有自己的context，libB也有自己的context。没有办法让他们中的一个破坏或颠覆另一个。
这里的教训很明显：不要在库中使用全局状态。如果你这样做，当它恰好在同一个进程中被实例化两次时，库很可能会被中断。
Performance
当ØMQ项目启动时，其主要目标是优化性能。 消息传递系统的性能使用两个度量来表示：吞吐量 - 在给定时间内可以传递多少消息; 延迟 - 消息从一个端点到另一个端点需要多长时间。
我们应该关注哪个指标？ 两者之间的关系是什么？ 不是很明显吗？ 运行测试，将测试的总时间除以传递的消息数，得到的是延迟。 单位时间内的消息数是吞吐量。 换句话说，延迟是吞吐量的逆值。 简单，对吧？
我们花了几个星期详细评估性能指标而不是立即开始编码，从而发现吞吐量和延迟之间的关系远没有那么简单，而且是与直觉相反的。
想象A发送消息到B（参见图2）。 测试的总时间为6秒。 有5个消息已通过。 因此，吞吐量为0.83个消息/秒（5/6），延迟为1.2秒（6/5），对吗？
图二：从Ａ发送消息到Ｂ
再看看图二。 每个消息从A到B需要不同的时间：2秒，2.5秒，3秒，3.5秒，4秒。 平均值是3秒，这与我们原来计算的1.2秒相差很大。 这个例子显示了人们对性能指标直观倾向的误解。
现在来看看吞吐量。 测试的总时间为6秒。 然而，对于A而言，它只需要2秒就可以发送完所有的消息。 从A的角度来看，吞吐量为2.5 msgs / sec（5/2）。 对于Ｂ而言，接收所有消息需要4秒。 所以从B的角度来看，吞吐量为1.25 msgs / sec（5/4）。 这些数字都不符合我们原来计算的1.2 msgs / sec的结果。
长话短说：延迟和吞吐量是两个不同的指标; 这很明显。重要的是要了解两者之间的差异及其关系。延迟只能在系统中的两个不同点之间度量; 单独在点A处没有延迟的概念。每个消息具有其自己的延迟。你可以得到多个消息的平均延迟; 而消息流是没有延迟的。
另一方面，只能在系统的单个点处测量吞吐量。发送端有一个吞吐量，接收端有一个吞吐量，两者之间的任何中间点都有一个吞吐量，但是没有整个系统的整体吞吐量。而吞吐量只对一组消息有意义; 没有单个消息的吞吐量的概念。
至于吞吐量和延迟之间的关系，事实证明真的有一种关系; 然而，公式涉及积分，我们不会在这里讨论它。 有关更多信息，请阅读有关排队理论的文献。 在基准化消息系统中有很多的陷阱，我们不会进一步深入。 我们应该把精力放在学到的教训上：确保你理解你正在解决的问题。 即使一个简单的问题，“让程序更快”也需要大量的工作才能正确理解。 更重要的是，如果你不理解这个问题，你可能会在你的代码中构建隐式假设和流行的神话，使得解决方案有缺陷，或者至少要复杂得多或者比可能的少。
Critical Path
我们在优化过程中发现三个因素对性能有至关重要的影响：
- 内存分配数
- 系统调用数
- 并发模型
然而，不是每个内存分配或每个系统调用对性能有相同的影响。我们对消息传递系统感兴趣的性能是在给定时间内我们可以在两个端点之间传输的消息数。或者，我们可能感兴趣的是消息从一个端点到另一个端点需要多长时间。
然而，鉴于ØMQ是为具有长连接的场景设计的，建立连接所需的时间或处理连接错误所需的时间基本上是不相关的。这些事件很少发生，因此它们对整体性能的影响可以忽略不计。
一个代码库的反复频繁使用的部分被称为关键路径; 优化应该关注关键路径。
让我们看看一个例子：ØMQ并没有在内存分配方面进行极大优化。例如，当操作字符串时，它通常为转换的每个中间阶段分配一个新字符串， 但是，如果我们严格查看关键路径（实际的消息传递），我们会发现它几乎不使用内存分配。如果消息很小，则每256个消息只有一个内存分配（这些消息保存在一个大的分配的内存块中）。此外，如果消息流稳定，没有巨大的流量峰值，则关键路径上的内存分配数量将降至零（已分配的内存块不会返回到系统，而是重复使用）。
经验教训：优化产生显著差异的地方。优化不在关键路径上的代码段是是无效的。
Allocating Memory
假设所有基础设施都已初始化，并且两个端点之间的连接已建立，则在发送消息时只需要为一个东西分配内存：消息本身。因此，为了优化关键路径，我们必须研究如何为消息分配内存并在堆栈中上下传递。
在高性能网络领域中的常识是，通过仔细平衡消息分配内存的成本和消息复制的成本（例如，对小，中和大消息的不同处理）来实现最佳性能。对于小消息，复制比分配内存要代价小。根本不分配新的存储器块，而是在需要时将消息复制到预分配的存储器是有意义的。另一方面，对于大消息，复制比内存分配代价大。将消息分配一次，并将指针传递到分配的块，而不是复制数据是有意义的。这种方法称为“零拷贝”。
ØMQ以透明的方式处理这两种情况。 ØMQ消息由不透明句柄表示。 非常小的消息的内容直接编码在句柄中。 因此，复制句柄实际上复制了消息数据。当消息较大时，它被分配在单独的缓冲区中，并且句柄仅包含指向缓冲区的指针。创建句柄的副本不会导致复制消息数据，这在消息是兆字节长时是有意义的（图3）。 应当注意，在后一种情况下，缓冲器被引用计数，使得其可以被多个句柄引用，而不需要复制数据。
图三：消息拷贝（或没有消息拷贝）
经验教训：在考虑性能时，不要假设有一个单一的最佳解决方案。可能发生的是，存在问题的多个子类（例如，小消息 vs. 大消息），每个都具有其自己的最佳算法。
Batching
已经提到，消息系统中的一定系统调用的数量可能导致性能瓶颈。其实，这个问题比那个更普遍。 遍历调用堆栈相关时会有不小的性能损失，因此，当创建高性能应用程序时，避免尽可能多的堆栈遍历是明智的。
考虑图4.要发送四个消息，你必须遍历整个网络栈四次（ØMQ，glibc，用户/内核空间边界，TCP实现，IP实现，以太网层，NIC本身和重新备份栈）。
图四：发送四个消息
但是，如果您决定将这些消息合并到单个批消息中，则只有一次遍历堆栈（图5）。对消息吞吐量的影响可能是非常显著的：高达两个数量级，特别是如果消息很小，并且其中几百个可以打包成一个批消息时。
图五：Batching messages
另一方面，批量化会对延迟产生负面影响。让我们举个例子，知名的Nagle算法，在TCP中实现。它将出站消息延迟一定量的时间，并将所有累积的数据合并到单个数据包中。显然，分组中的第一消息的端到端等待时间比最后一个的等待时间多得多。因此，对于需要获得一致的低延迟来关闭Nagle算法的应用程序来说，这是很常见的。甚至常常在堆栈的所有层次上关闭批量化（例如，NIC的中断合并功能）。但是没有批量化意味着大量遍历堆栈并导致低消息吞吐量。我们似乎陷入了权衡吞吐量和延迟的困境。
ØMQ尝试使用以下策略提供一致的低延迟和高吞吐量：当消息流稀疏并且不超过网络堆栈的带宽时，ØMQ关闭所有批量化以提高延迟。这里的权衡在某种程度上是会使CPU使用率变高（我们仍然需要经常遍历堆栈）。 然而，这在大多数情况下不被认为是问题。
当消息速率超过网络栈的带宽时，消息必须排队（存储在存储器中），直到栈准备好接受它们。排队意味着延迟将增长。如果消息在队列中花费了一秒钟，则端到端延迟将至少为1秒。 更糟糕的是，随着队列的大小增加，延迟将逐渐增加。如果队列的大小没有限制，则延迟可能会超过任何限制。
已经观察到，即使网络堆栈被调到尽可能低的延迟（Nagle的算法被关闭，NIC中断合并被关闭，等等），由于排队效应，延迟仍然可能是令人沮丧的，如上所述。
在这种情况下，大量开始批量化处理是有意义的。没有什么会丢失，因为延迟已经很高。另一方面，大量的批处理提高了吞吐量，并且可以清空未完成消息的队列 - 这反过来意味着等待时间将随着排队延迟的减少而逐渐降低。一旦队列中没有未完成的消息，则可以关闭批量化处理，以进一步改善延迟。
经验教训：为了在异步系统中获得最佳吞吐量和最佳响应时间，请关闭堆栈的最底层上的批量化算法并且在在最高层次进行批量化。只有当新数据的到达速度比可处理的数据快时才进行批量化处理。
Architecture Overview
到目前为止，我们专注于使ØMQ快速的通用原则。现在，让我们看看系统的实际架构（图6）。
图六：ØMQ architecture
用户使用所谓的“sockets”与ØMQ交互。 它们非常类似于TCP套接字，主要的区别是每个套接字可以处理与多个对等体的通信，有点像未绑定的UDP套接字。
套接字对象存在于用户线程中（参见下一节中的线程模型的讨论）。除此之外，ØMQ运行多个工作线程来处理通信的异步部分：从网络读取数据，排队消息，接受接入连接等。
在工作线程中存在各种对象。每个对象都由一个父对象拥有（所有权由图中的简单实线表示）。父对象可以在与子对象不同的线程中。大多数对象直接由套接字拥有; 然而，有几种情况下，对象由套接字拥有的对象所拥有。 我们得到的是一个对象树，每个套接字有一个这样的树。 这种树在关闭期间使用; 没有对象可以自己关闭，直到它关闭所有的子对象。 这样我们可以确保关机过程按预期工作; 例如，等待的出站消息被推送到网络优先于结束发送过程。
大致来说，有两种异步对象：在消息传递中不涉及的对象和另外一些对象。前者主要做连接管理。例如，TCP侦听器对象侦听传入的TCP连接，并为每个新连接创建引擎/会话对象。类似地，TCP连接器对象尝试连接到TCP对等体，并且当它成功时，它创建一个引擎/会话对象来管理连接。 当此类连接失败时，连接器对象尝试重新建立连接。
后者是正在处理数据传输本身的对象。 这些对象由两部分组成：会话对象负责与ØMQ套接字交互，引擎对象负责与网络通信。 只有一种会话对象，但是对于ØMQ支持的每个底层协议有不同的引擎类型。 因此，我们有TCP引擎，IPC（进程间通信）引擎，PGM引擎（可靠的多播协议，参见RFC 3208）等。引擎集是可扩展的 （在将来我们可以选择实现 WebSocket引擎或SCTP引擎）。
会话与套接字交换消息。 有两个方向传递消息，每个方向由管道对象处理。每个管道基本上是一个优化的无锁队列，用于在线程之间快速传递消息。
最后，有一个context对象（在前面的部分中讨论，但没有在图中显示），它保存全局状态，并且可以被所有的套接字和所有的异步对象访问。
Concurrency Model
ØMQ的要求之一是利用计算机的多核; 换句话说，可以根据可用CPU内核的数量线性扩展吞吐量。
这个想法的思想是为每个CPU核心启动一个工作线程（有两个线程共享同一个核心只会意味着很多上下文切换没有特别的优势）。每个内部ØMQ对象，比如说，一个TCP引擎，将绑定到一个特定的工作线程。 这反过来意味着不需要临界区，互斥体，信号量等。 此外，这些ØMQ对象不会在CPU核心之间迁移，从而避免高速缓存污染对性能的负面影响（图7）
图七：Multiple worker threads
这个设计使很多传统的多线程问题消失了。 然而，需要在许多对象之间共享工作线程，这反过来意味着需要某种协作多任务。 这意味着我们需要一个调度器; 对象需要是事件驱动的，而不是控制整个事件循环。 也就是说，我们必须处理任意事件序列，即使是非常罕见的事件，我们必须确保没有任何对象持有CPU太长时间; 等等
简而言之，整个系统必须完全异步。 没有对象可以做阻塞操作，因为它不仅会阻塞自身，而且会阻塞共享同一个工作线程的所有其他对象。 所有对象必须成为状态机，无论是显式还是隐式。 有数百或数千个状态机并行运行，你就必须处理它们之间的所有可能的交互，并且最重要的是关闭过程。
事实证明，以干净的方式关闭完全异步系统是一个非常复杂的任务。 试图关闭一千个移动部件，其中一些工作，一些空闲，一些在启动过程中，其中一些已经自行关闭，容易出现各种竞态条件，资源泄漏和类似情况。 关闭子系统绝对是ØMQ中最复杂的部分。 对Bug跟踪器的快速检查表明，大约30％-50％的报告的错误与以某种方式关闭相关。
获得的经验：在努力实现最佳性能和可扩展性时，请考虑actor模型; 它几乎是这种情况下唯一的方法。 但是，如果你不使用像Erlang或ØMQ这样的专用系统，你必须手工编写和调试大量的基础设施。 此外，从一开始，想想关闭系统的过程。 它将是代码库中最复杂的部分，如果你不清楚如何实现它，你应该可以重新考虑使用actor模型。
Lock-Free Algorithms
无锁算法最近一直流行起来。 它们是线程间通信的简单机制，它不依赖于内核提供的同步原语，例如互斥体或信号量; 相反，它们使用原子CPU操作（诸如原子compare-and-swap（CAS））来进行同步。 应当理解，它们不是字面上无锁的，而是在硬件级别的幕后进行锁定。
ØMQ在管道对象中使用无锁队列在用户的线程和ØMQ的工作线程之间传递消息。 ØMQ如何使用无锁队列有两个有趣的方面。
首先，每个队列只有一个写线程和一个读线程。 如果需要1对N通信，则创建多个队列（图8）。 考虑到这种方式，队列不必关心同步写入器（只有一个写入器）或读取器（只有一个读取器），它可以以额外的高效方式实现。
图八：Queues
第二，我们意识到虽然无锁算法比传统的基于互斥的算法更高效，但原子CPU操作仍然代价较高（尤其是在CPU核心之间存在争用时），并且对每个写入的消息和/或每个消息执行原子操作读的速度比我们能接受的要慢。
加快速度的方法是再次批量处理。 想象一下，你有10条消息要写入队列。 例如，当收到包含10条小消息的网络包时，可能会发生这种情况。 接收分组是原子事件; 所以你不会只得到一半。 这个原子事件导致需要向无锁队列写入10条消息。 对每条消息执行原子操作没有太多意义。 相反，可以在队列的“预写”部分中累积消息，该部分仅由写入程序线程访问，然后使用单个原子操作刷新它。
这同样适用于从队列读取。 想象上面的10个消息已经刷新到队列。 阅读器线程可以使用原子操作从队列中提取每个消息。 然而，它是超杀; 相反，它可以使用单个原子操作将所有未决消息移动到队列的“预读”部分。 之后，它可以逐个从“预读”缓冲区检索消息。 “预读”仅由读取器线程拥有和访问，因此在该阶段不需要任何同步。
图9左侧的箭头显示了如何通过修改单个指针可以将预写缓冲区刷新到队列。 右边的箭头显示了队列的整个内容如何可以通过不做任何事情而修改另一个指针来转移到预读。
图九：Lock-free queue
获得的教训：无锁算法很难发明，麻烦执行，几乎不可能调试。 如果可能，请使用现有的成熟算法，而不是发明自己的。 当需要最佳性能时，不要仅依赖无锁算法。 虽然它们速度快，但通过在它们之上进行智能批处理可以显着提高性能。
API
用户接口是任何产品的最重要的部分。 这是你的程序中唯一可以看到的外部世界。 在最终用户产品中，它是GUI或命令行界面。 在库中它是API。
在早期版本的ØMQ中，API基于AMQP的交换和队列模型。 （参见AMQP specification。）从历史的角度看，有趣的是看看2007年的白皮书（white paper from 2007），它试图权衡AMQP与无代理的消息模型。 我花了2009年年底重写它几乎从零开始使用BSD套接字API。 这是转折点; ØMQ从那时起就被快速采用。 虽然之前它是一个被一群消息专家使用的niche产品，后来它成为任何人的一个方便的常见工具。 在一年多的时间里，社区的规模增加了十倍，实现了约20种不同语言的绑定等。
用户接口定义产品的感知。 基本上没有改变功能 - 只是通过更改API - ØMQ从“企业消息传递系统”产品更改为“网络消息传递系统”产品。 换句话说，感觉从“大型银行的一个复杂的基础设施”改变为“嗨，这有助于我将我的10字节长的消息从应用程序A发送到应用程序B”。
获得的经验：了解您想要的项目是什么，并相应地设计用户接口。 不符合项目愿景的用户接口是100％要失败的。
迁移到BSD Sockets API的一个重要方面是，它不是一个革命性的新发明的API，而是一个现有的和知名的。 实际上，BSD套接字API是今天仍在使用的最古老的API之一; 它可追溯到1983年和4.2BSD Unix。 它被广泛稳定了使用几十年。
上述事实带来了很多优点。 首先，它是一个大家都知道的API，所以学习曲线非常短。 即使你从来没有听说过ØMQ，你可以在几分钟内构建你的第一个应用程序，因为你能够重用你的BSD套接字知识。
此外，使用广泛实现的API可以实现ØMQ与现有技术的集成。 例如，将ØMQ对象暴露为“套接字”或“文件描述符”允许在同一事件循环中处理TCP，UDP，管道，文件和ØMQ事件。 另一个例子：实验项目给Linux内核带来类似ØMQ的功能，实现起来很简单。 通过共享相同的概念框架，它可以重用许多已经到位的基础设施。
最重要的是，BSD套接字API已经存活了近三十年，尽管多次尝试更换它意味着在设计中有一些固有的合理的地方。 BSD套接字API设计者已经（无论是故意还是偶然） 做出了正确的设计决策。 通过采用这套API，我们可以自动共享这些设计决策，甚至可以不知道他们是什么，他们要解决什么问题。
经验教训：虽然代码重用已经从很久前得到重视并且模式重用在后来被加以考虑，但重要的是以更通用的方式考虑重用。 在设计产品时，请看看类似的产品。 检查哪些失败，哪些已成功; 从成功的项目中学习。 Don't succumb to Not Invented Here syndrome。 重用思想，API，概念框架，以及无论你觉得合适的东西。 通过这样做，可以做到允许用户重用他们现有的知识。 同时，可能会避免目前还不知道的技术陷阱。
Messaging Patterns
在任何消息系统中，最重要的设计问题是如何为用户提供一种方式来指定哪些消息被路由到哪些目的地。 有两种主要方法，我认为这种二分法是非常通用的，并且适用于基本上在软件领域遇到的任何问题。
一种方法是采用UNIX的“做一件事，并做好”的哲学。 这意味着，问题领域应该被人为地限制在一个小的并且易于理解的区域。 然后程序应该以正确并详尽的方式解决这个限制的问题。 消息传递领域中的这种方法的示例是MQTT。 它是一种用于向一组消费者分发消息的协议。 它不能用于任何其他用途（比如说RPC），但它很容易使用，并且用做消息分发很好。
另一种方法是关注通用性并提供强大且高度可配置的系统。 AMQP是这样的系统的示例。 它的队列和交换的模型为用户提供了几乎任何路由算法定义的方法。 当然，权衡，需要关心很多选项。
ØMQ选择前一个模型，因为它允许基本上任何人使用最终产品，而通用模型需要消息传递专家使用它。 为了演示这一点，让我们看看模型如何影响API的复杂性。 以下是在通用系统（AMQP）之上的RPC客户端的实现：
1 connect ("192.168.0.111") 2 exchange.declare (exchange="requests", type="direct", passive=false, 3 durable=true, no-wait=true, arguments={}) 4 exchange.declare (exchange="replies", type="direct", passive=false, 5 durable=true, no-wait=true, arguments={}) 6 reply-queue = queue.declare (queue="", passive=false, durable=false, 7 exclusive=true, auto-delete=true, no-wait=false, arguments={}) 8 queue.bind (queue=reply-queue, exchange="replies", 9 routing-key=reply-queue) 10 queue.consume (queue=reply-queue, consumer-tag="", no-local=false, 11 no-ack=false, exclusive=true, no-wait=true, arguments={}) 12 request = new-message ("Hello World!") 13 request.reply-to = reply-queue 14 request.correlation-id = generate-unique-id () 15 basic.publish (exchange="requests", routing-key="my-service", 16 mandatory=true, immediate=false) 17 reply = get-message ()
另一方面，ØMQ将消息传递分为所谓的“消息模式”。 模式的示例是“发布/订阅”，“请求/回复”或“并行化流水线”。 每个消息模式与其他模式完全正交，并且可以被认为是一个单独的工具。
以下是使用ØMQ的请求/回复模式重新实现上述应用程序。 注意如何将所有选项调整减少到选择正确的消息模式（“REQ”）的单一步骤：
1 s = socket (REQ) 2 s.connect ("tcp://192.168.0.111:5555") 3 s.send ("Hello World!") 4 reply = s.recv ()
到目前为止，我们认为具体的解决方案比通用解决方案更好。我们希望我们的解决方案尽可能具体。然而，同时，我们希望为我们的客户提供尽可能广泛的功能。我们如何才能解决这个明显的矛盾？
答案包括两个步骤：
- 定义堆栈的层以处理特定问题区域（传输，路由，呈现等）。
- 提供该层的多个实现。对于每个用例应该有一个单独的不相交的实现。
让我们来看看Internet栈中传输层的例子。它意味着在网络层（IP）的顶部上提供诸如传送数据流，应用流控制，提供可靠性等的服务。它通过定义多个不相交解决方案：TCP面向连接的可靠流传输，UDP无连接不可靠数据包传输，SCTP传输多个流，DCCP不可靠连接等。
注意每个实现是完全正交的：UDP端点不能说TCP端点。 SCTP端点也不能与DCCP端点通信。这意味着新的实现可以在任何时候添加到堆栈，而不会影响堆栈的现有部分。相反，失败的实现可以被忘记和丢弃而不损害作为整体的传输层的可行性。
相同的原则适用于由ØMQ定义的消息模式。消息模式在传输层（TCP和朋友）之上形成层（所谓的“可伸缩性层”）。单独的消息模式是该层的实现。它们是严格正交的 - 发布/订阅端点不能说请求/回复端点等。模式之间的严格分离意味着可以根据需要添加新模式，并且失败的新模式的实验赢得“不利于现有模式。
获得的经验：在解决复杂和多方面的问题时，可能会发现单一通用解决方案可能不是最好的解决方法。相反，我们可以将问题区域看作一个抽象层，并提供该层的多个实现，每个集中在一个特定的定义良好的用例。在这样做时，请仔细描述用例。确保范围，什么不在范围内。太明显地限制用例，应用程序可能会受到限制。然而，如果定义的问题太宽泛，产品可能变得太复杂，模糊，并使用户产生混淆。
Conclusion
随着我们的世界变得充满了许多通过互联网连接的小型计算机 - 移动电话，RFID阅读器，平板电脑和笔记本电脑，GPS设备等 - 分布式计算的问题不再是学术科学的领域，并且成为常见的日常问题 为每个开发者解决。 不幸的是，解决方案主要是具体领域的hacks。 本文总结了我们系统地构建大规模分布式系统的经验。 关注从软件架构的角度来看有趣的问题，希望开源社区的设计师和程序员会发现它有用。
MartinSústrik是消息传递中间件领域的专家。 他参与了AMQP标准的创建和参考实施，并参与了金融行业的各种消息传递项目。 他是ØMQ项目的创始人，目前正在致力于将消息传递技术与操作系统和Internet栈进行集成。 本文摘自并修改自《The Architecture of Open Source Applications: Volume II》。
原文链接：ZeroMQ: The Design of Messaging Middleware