在Rebus服务总线中，每个端点只有一个message transport queue。端点可以处理多个消息，并且系统中可能只有一个端点。
除了消息的吞吐量之外，在Rebus服务总线系统中使用多个端点的原因是什么？
答案 0 :(得分：1)
很棒的问题！ :)可能有很多原因导致您可能希望同时激活多个Rebus端点。
一个明显的原因是您可能希望在单独的进程中托管端点，以便您可以彼此独立地更新它们。但由于这个原因非常明显，我假设您正在考虑可能希望在同一进程中托管多个Rebus端点的原因。
我只想提几句（*）：
一个端点可能正在托管经历争用的数据，因此无法同时处理消息 - 此端点可能只有少量线程和低并行度，可能是1/1。
另一个端点可能正在进行基于流的数据处理（例如，将blob从一个地方加载到另一个地方，从Web服务下载数据等），这可以通过一个单独的线程以非常高的吞吐量和低资源需求来完成。高水平的并行性 - 例如1/20。
另一个端点可能正在进行大量的序列化/反序列化，这通常是CPU限制的，因此可能会受益于在具有许多工作线程和匹配并行性的多核盒上运行 - 例如10/10
如您所见，端点执行的任务类型可以调用与任务性质相匹配的配置。
可以指定一个端点来处理低优先级的背景资料，例如将数据移动到冷库，优化历史数据的存储等。
另一个端点可能正在处理低延迟是最重要的质量属性的消息。
如果这两个队列使用相同的队列，那么低优先级的后台资源有时会堵塞队列，阻碍了其他消息的低延迟处理。
我有很多次在同一个流程中托管多个Rebus端点，因为它在开发过程中很容易处理，同时保持端点分离，因为它们实现了不同的业务功能。
通过这种方式，以后很容易将它们分开，从而实现更高程度的分离和独立性。
（*）Udi Dahan使用“业务组件”和“自治组件”的概念，其中第一个是业务功能的实现，第二个是业务组件被分解成的，主要是出于技术原因。 / p>
我想你可以说我提到的前两个原因是“自主组件”原因的单独端点，而第三个原因是分离，因为事物属于不同的业务组件。
Udi对这些概念保持非常严格的观点，这与系统的物理组合完全正交，但我几乎总是在逻辑分离和物理分离之间达到相当高的收敛。