既然已经看到了发布/订阅的行动,让我们来看看在窗帘后面,看看发生了什么。
如果你还没有见过的发布/订阅样本然而花一分钟穿过或开始使用NServiceBus创建一个新项目.
最主要的理解是这样的:用户让出版商知道他们感兴趣,和出版商商店的地址,这样就知道发送的消息。很简单,一旦你知道了它是如何运作的。
在我们开始之前……
对发布/订阅消息传递的一个常见的假设是,它涉及到物理一对多沟通。唯一的问题是,在物理层面pub / sub并不有趣。在发布时它变成有价值的逻辑事件从一个逻辑区域责任其他逻辑感兴趣。
NServiceBus的基础设施部分处理物流和一对多消息调度pub / sub许多寻找,但这些是相当透明的编程模型。让我们看看逻辑pub / sub和物理分布的叠加,一步一个脚印。
上面的图向我们展示了一个逻辑出版商P1,和两个逻辑订阅者SA和某人有很多物理节点(颜色的蓝色)和一些NServiceBus基础设施(橘色)。现在,我们将假设SA和某人已经订阅,每个指定经销商的离港公共端点。
当我们发布
当一个节点在逻辑出版商P1去发布一个消息,发生了什么:
当请求应用逻辑来发布消息,订阅数据库配置的NServiceBus基础设施联系,找到所有订阅者端点注册为给定的消息类型,和每一个分派一个物理信息。
单向消息用于调度物理消息以来,即使订阅者端点之一是离线或不可用,这并不使出版线程块。发送机器即将离任的消息存储在队列(可配置的时间),而消息传递基础结构的尝试将消息传递到目的地。
什么经销商
所有的经销商在这一点上是该消息转发它接收到另一个节点。
你可以把经销商的像一个负载均衡器它分发消息来许多其他机器。这种物理一对多通信需要扩展运行的机器数量对于一个给定的用户,但实际上并不需要任何pub / sub。每个用户都有自己的独立分销商和他们中的每一个决定,机它传递消息。
看到关于经销商的更多信息.
对任何出版商节点一样
不管哪个节点在出版商出版消息,会发生同样的过程。
这意味着你可以向外扩展发布节点的数量,通过使用数据库来存储订阅,而无需一个分销商。当使用通用NServiceBus主机进程你得到这个默认的生产状况。
下一个步骤
- 了解API和配置参与pub / sub.
- 看看如何配置分销商和更多地了解它的内部.
- 了解如何使用通用NServiceBus主进程.