发布/订阅

发布者与订阅者松耦合，甚至不需要知道它们的存在。由于主题才是关注的焦点，发布者和订阅者可以对系统拓扑结构保持一无所知。各自继续正常操作而无需顾及对方。在传统的紧耦合的客户端-服务器模式中，当服务器进程不运行时，客户端无法发送消息给服务器，服务器也无法在客户端不运行时接收消息。许多发布/订阅系统不但将发布者和订阅者从位置上解耦，还从时间上解耦他们。中间件分析师对这种发布/订阅使用的常用策略，是拆卸一个发布者来让订阅者处理完积压的工作（带宽限制的一种形式）。

通过并行操作，消息缓存，基于树或基于网络的路由等技术，发布/订阅提供了比传统的客户端–服务器更好的可扩展性。然而，在某些类型的紧耦合、高容量的企业环境中，随着系统规模上升到由上千台服务器组成的数据中心所共享的发布/订阅基础架构，现有的供应商系统经常失去这项好处；在这些高负载环境下，发布/订阅产品的扩展性是一个研究课题。

另一方面，在企业环境之外，发布/订阅范式已经证明了它的可扩展性远超过一个单一的数据中心，通过网络聚合协议如RSS和Atom提供互联网范围内分发的消息。在交互时，为了能够即便是用低档Web服务器也能将消息播出到(可能)数以百万计的独立用户节点，这些聚合协议接受更高的延迟和无保障交付。

发布/订阅系统必须仔细设计，才能提供特定的应用程序可能需要的更强大的系统性能，例如有保障的交付。

• 发布/订阅系统的中介(broker)可能设计为在指定时间发送消息，随后便停止尝试发送，无论是否已收到所有用户成功接收消息的确认回复。这样设计的发布/订阅系统不能保证消息能够传递到所有需要这种有保障交付的应用程序。要达成有保障交付，必须在发布/订阅架构之外强制执行这种发布者和订阅者之间在设计上更紧密的耦合（例如，通过要求订阅者宣布消息已接收）。

• 发布/订阅系统中的发布者会“假定”订阅者正在监听，而实际上可能没有。一个工厂可能会使用发布/订阅系统来允许设备发布问题和故障，订阅者将问题显示并记录。如果记录器失败（崩溃了），那么设备故障发布者不一定收到记录器失败的通知，发布/订阅系统的任何设备都不会显示和记录错误消息。应当指出的是，对于其它消息架构这也是一个设计上的挑战，例如客户端/服务器系统。在客户端/服务器系统中，当一个错误记录器失效，系统将收到迹象。但是，客户端/服务器系统要处理这个失效，就必须拥有一个在线的冗余日志服务器，或者动态生成回退日志服务器。这就增加了服务端和客户端以及整个客户端/服务器架构设计的复杂度。然而，发布/订阅系统中，在不影响任何其它设备的情况下，精确复制现有日志器的冗余日志记录订阅者可以添加到系统，来增加日志记录的可靠性。在发布/订阅系统中，有保障的错误消息日志功能可以逐步添加，随后实现设备故障信息记录的简单基本功能。

在有少量发布者和订阅节点的小型网络和低信息量时发布/订阅能够自如伸缩。然而，随着节点和消息量的增长，不稳定性随之增长，限制了发布/订阅网络的最大可扩展性。大规模时吞吐量不稳定的例子包括：

• 负载激增 - 订阅请求使网络流量饱和，随后进入低信息量（未充分利用网络带宽）
• 速度变慢 - 越来越多的应用程序使用该系统（即使它们是在不同的发布/订阅频道通信）消息量流入单个订阅者的速度缓慢

使用中介（服务器）的发布/订阅系统，同意中介发送消息给带内订阅者，会引发安全问题。中介可能被愚弄，从而将通知发送给错误的客户端，增大了针对客户端的服务请求被拒绝的可能性。中介本身可能超载，因为他们分配资源来跟踪创建的订阅。

即使不依赖中介的系统，订阅者也可能可以接收未被授权的数据。未经授权的发布者可能将不正确或损坏的消息引入到发布/订阅系统。对于广播或多播消息的系统，这是尤其真实的。加密（例如傳輸層安全性協定（SSL/TLS）），可以防止未经授权的访问，但不能防止损坏的消息被授权的发布者引入。除了发布/订阅架构，例如客户端/服务器系统，也经常碰到授权的消息发送者有恶意行为。