为什么在 Rebus 系统中使用多个端点？

Question

在 Rebus 服务总线中，每个端点有一个 message transport queue。一个端点可以处理多个消息，并且系统中可能只有一个端点。

除了消息的吞吐量，还有什么理由在 Rebus 服务总线系统中使用多个端点？

Answer 1

很好的问题！ :) 您可能希望同时激活多个 Rebus 端点的原因有很多。

一个明显的原因是您可能希望将端点托管在单独的进程中，以便您可以独立地更新它们。但由于这个原因非常明显，我假设您正在考虑可能希望在同一进程中托管多个 Rebus 端点的原因。

我只提几个（*）：

并发要求

一个端点可能正在托管经历争用的数据，因此无法从能够同时处理消息中受益 - 该端点可能只有几个线程和低并行度，可能是 1/1。

另一个端点可能正在执行基于流的数据处理（例如，将 Blob 从一个地方加载到另一个地方，从 Web 服务下载数据等），这可以通过一个单线程以非常高的吞吐量和低资源需求来完成，并且高水平的并行性 - 例如1/20。

另一个端点可能正在进行大量序列化/反序列化，这通常受 CPU 限制，因此可能受益于在具有许多工作线程和匹配并行性的多核机器上运行 - 例如10 月 10 日。

如您所见，端点执行的任务类型可能需要与任务性质相匹配的配置。

SLA

可能会指定一个端点来处理低优先级的背景内容，例如将数据移至冷库，优化历史数据的存储等。

另一个端点可能正在处理低延迟是最重要的质量属性的消息。

如果这两个使用同一个队列，低优先级的后台内容有时会阻塞队列，阻碍其他消息的低延迟处理。

逻辑分离

我曾多次在同一个流程中托管多个 Rebus 端点，因为这在开发过程中很容易处理，同时保持端点分开，因为它们实现不同的业务功能。

这种方式很容易在一段时间后将它们从物理上分开，从而实现更高程度的分离和独立。

---

(*) Udi Dahan 使用“业务组件”和“自治组件”的概念，其中第一个是业务能力的实现，第二个是业务组件被分解成的内容，主要是出于技术原因。

我想你可以说我提到的前两个原因是“自治组件”原因的独立端点，而第三个原因是分离，因为事物属于不同的业务组件。

Udi 对这些概念持相当严格的看法，这些概念与系统的物理组成方式完全正交，但我几乎总是最终得出逻辑分离和物理分离之间相当高的收敛性。