发布/订阅 Publish/subscribe
在NServiceBus 的单向（one-way）通信模式中，消息的发送者往往无法知道接收者的详细信息。实现这个额外的“松耦合”的代价是：订阅者Subscriber 需要显式的选择接入，从而来接受特定消息。如下图所示：
（1） 订阅Subscription
订阅者需要知道那个服务终端（Endpoint）负责特定的消息。这些信息通常放在契约Contract中，用于指定一个订阅者应该把请求发给哪个终端。作为“订阅消息”的一部分，订阅者传递了它的“返回地址return address”，用于告诉服务发布者它希望接受消息的终端。
记住，服务发布者终端会记住（存储到DB）对每个事件消息感兴趣的每个订阅终端的地址。这种方式允许多台发布服务终端同时工作，而不用管哪台服务终端是否受到了订阅的消息。举个例子：
【例子】PA,PB,PC三台事件服务发布者机器，使用一个数据库DB1，那么如果之前是PA收到了某个订阅者subscriber1的订阅请求，并且存入数据库DB1，那么当事件E1发生时，PA主机负载繁忙，这时候，PB或者PC都可以发布该事件消息。
订阅者没必要自己去订阅事件服务。通过使用“返回地址”的方式，一个中心化的配置站点将发送多个订阅消息到每一个事件发行者，这些消息中包含了“哪个订阅者终端”订阅了“哪个事件消息”。
另一方面，为了让多个 物理上的 订阅者主机（PhysicalSubscriber）共同解决同一种事件，我们可以让这多个订阅者主机在逻辑上抽象为单个逻辑订阅者（Logical Subscriber）。这种方式还能让均衡负载变为可能，并且不需要在发布者上或者订阅者的代码逻辑中去协调控制。实现了这种方案，这些订阅者主机（物理上）只需要在订阅信息中设置相同的“返回地址”，即逻辑订阅者终端分配器的地址。
【注】普通情况下，我们均衡负载是在服务器上进行控制：读取各个客户端的状态，挑选一个最小负载的客户端，把任务发过去。或者是在客户端程序中去控制。
（2） 发布事件
如下图所示为发布的情况。
发布一个事件消息意味着要把该事件消息通知到每一个订阅了该事件的终端主机。
发布的消息一般指事件，或者已经发生的事情。比如：订单取消，产品下架，快递延迟等。有时候，引发事件的原因正是处理了前面一条Command消息，比如取消订单。取消订单是Command，取消订单的执行结果有成功和失败，处理完毕后这将引发一个订单取消事件，里面记录了事件以及最终的结果。发布者不需要把事件发布当作是处理Command消息的一部分（虽然这样做很简单）。为什么？因为我们知道，Command消息的数量是很多的，如果在短时间内，对每个command都发布事件的话，那么在订阅者终端来说，会大大加重其接受负载。我们给出的方法是，发布者根据特定频率来检查在该时间段内发送的所有改变，把这些改变打包成一个单一的事件消息，发送给订阅者。频率间隔的大小要根据业务不同来选择，比如对于金融数据，那么最好设置为10ms，对于电子商务消费来说的话，1分钟也是可以接受的。
【例子】如发布者服务器终端在1s内接受到了来自Command请求者C1的1万条请求，分别对某个订单进行修改和取消，重新预定，那么这1s内，订阅者也会受到这1万条事件消息。这样不可行。正确的做法是，1s之后，服务器进行变更总结，把这些Command执行完毕后的最终改变打包为一个事件消息，告诉订阅者。
另一个定时发布消息的好处是，处理某个Command消息的主机不一定是发布时间消息的主机，这样，主机的负载就可以被更好的均衡。