RabbitMQ 与无代理
RabbitMQ 团队一直与 Martin Sustrik 合作，提供将 RabbitMQ 和 ZeroMQ 结合使用的代码和文档。 为什么这是一个好主意？ 因为代理和无代理的方法是互补的。 随着代码库的发展，我们将发布更多相关信息。 这篇文章是入门性的，可以看作是对Ilya Grigorik 对 ZeroMQ 的精彩介绍以及InfoQ 对 Ilya 文章的总结的评论。
我喜欢 ZeroMQ，并且认为它很有用——更多内容将在下面介绍。 但我也看到了一些关于它的浮夸言论。 这可能会导致混淆。
那么什么是“无代理”模型呢？ 在 Ilya 和 InfoQ 的帖子的评论中，ZeroMQ 被比作 SCTP 和 JGroups。 这些都是重要的技术，为思考无代理消息传递模式提供了一个有用的起点。 让我们看看如果您将消息传递（如 SCTP）与发布/订阅组（如 JGroups）结合使用，以使用“无代理”对等方构建任意网络，您可能需要什么。
无代理网络中可能需要的一些东西
如果您设置了一个无代理消息传递网络，您可能需要三件事：发现、可用性和管理。
发现是指维护一个系统可以发送消息的对等方列表，以及谁可以加入此列表的问题。
可用性是指处理对等方不时消失的问题。 例如，如果您有 50 个订阅者，而其中只有 40 个可用，您是否应该为他们保留消息副本，直到他们重新出现？ 这可能意味着“很长一段时间”。 如果您确实保留了消息以及“谁看到了什么”的列表，那么在哪里最好执行此操作？
这也是在消息接收者响应缓慢时出现的问题。 引用ZeroMQ 的 Martin Sustrik 的话：“你永远无法区分‘网络错误’和‘未收到响应’。 TCP 也没有更好。 你必须接受这一点，或者坚持使用单个盒子。”
管理也是一个有趣的分析领域。 ZeroMQ 的模型将消息传递与套接字紧密结合。 这意味着，与 TCP 一样，任何通信网络都可以实现为提供某种消息传递能力。 但是，网络可能会非常复杂。 例如，除非你不在乎（而且你可能不在乎），否则管理“谁连接到谁，谁可以连接到谁”可能会变得复杂。 这种管理问题随着规模的扩大而变得更加困难。 JGroups 之类的模型通常会通过做出一个简化的假设来消除这个问题，即：组中的每个人都与其他所有人通信。 简单 :-)
我并不是说您总是需要这些东西。 ZeroMQ 的理念是专注于网络，这带来了重点。 但如果您确实需要它们，您可能最终会自己实现它们。 引入代理...
**代理如何帮助解决这些问题**
代理可以为发现、可用性和管理提供解决方案。 它们还可以形成可靠的网络，例如用于电子邮件传递和即时消息服务。
首先：什么是“代理”？ 它既是领导者，也是中间人。
代理是一个领导者。 在分布式计算中，管理、发现和可用性问题通常是通过在分布式组件集合中选举一个领导者来解决的。 在“消息传递”的世界中，这样的领导者通常被称为“代理”。 声明为了成为领导者，您需要成为代理，这使得确定谁是领导者比在“任何人都可以领导，但没人知道如何领导”的完全无代理系统中更容易。
代理也是一个中间人。 例如，通信方不必直接连接每个人，只需连接到代理（或多个代理）。 代理还可以用于解决“离线消费者”等可用性问题，通过提供持久性并代表无法自行执行此操作的系统进行管理恢复。
因此，代理通过做出合理的假设来**简化**网络设计。 当然，当这些假设不成立时，您可能不需要代理。
代理不是“中心化的”
关于代理的一个普遍的误解是它们是“中心化的”。 代理不一定是“中心化的”解决方案。 中间人可以是分散的。 您可以在单个网络中拥有多个代理，以提高吞吐量和可用性。 有时这些服务器网络被称为联盟。 请注意，单个代理不需要“高可用性”才能拥有冗余的服务器网络。
例如，电子邮件（SMTP）和 XMPP 网络就是这样工作的。 电子邮件和即时消息都是通过代理的模型，并且两者都以简单且冗余的方式使用多个代理。 例如，邮件传输代理为电子邮件提供传递和路由网络。 很难为它设计一个完全点对点的设计，而无需重新发明“特殊对等点”——也称为代理。
那么哪种模型最简单？
点对点模型并不**固有地**比代理模型更简单或更不简单。 如果您不需要发现、可用性、管理或中介，那么不使用它们可能更简单。 但如果您需要它们，那么不自己实现它们可能更简单。
服务器网络（代理）的冗余或分散程度不比客户端网络（对等点）高或低。 代理和无代理模型在可靠性和其他考虑因素（例如延迟）方面都有其优点和缺点。
这两种模型解决了不同的问题。
例如，RabbitMQ 和 ZeroMQ 是互补的。 从 RabbitMQ 的角度来看，ZeroMQ 是一个“智能客户端”，可以像队列一样使用其缓冲区。 在某些情况下这很有用。 从 ZeroMQ 的角度来看，RabbitMQ 是一个网络设备，提供了您不一定想自己实现的服务。
我们希望我们的客户和用户始终拥有最好的工具集，这就是为什么我们提供了Github 仓库供您试用。 再次感谢 Martin Sustrik 在此方面的工作。
请继续关注这一有趣的工作和讨论领域的更多信息。