跨集群的 MassTransit 请求和响应答案

【问题标题】：MassTransit Request and Response across a cluster跨集群的 MassTransit 请求和响应
【发布时间】：2016-03-05 07:22:08
【问题描述】：

最初我有一个 rabbitmq 节点，可以很好地处理请求/响应客户端交互。

我现在正在更改为集群并尝试运行相同的请求/响应操作。它爆炸得很壮观。

我已经设置了 2 台主机作为 rabbitmq 集群的一部分。我遇到了很多麻烦，所以我恢复使用公共交通sample code。

这似乎也有问题。我最终在我的请求服务上遇到了一个反复出现的异常：

--- End of stack trace from previous location where exception was thrown --
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(...)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNot
ification(...)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwai
ter.GetResult()
   at MassTransit.Pipeline.Filters.RescueReceiveContextFilter`1.<MassTransit-Pip
eline-IFilter<MassTransit-ReceiveContext>-Send>d__5.MoveNext()
Returning name for 45
Rescuing exception
MassTransit.EndpointNotFoundException: The endpoint address specified an unknown
 host: rabbitmq://erinome:5672/bus-ERINOME-Client.vshost-1pooyygnzw6bmox5bdjwjoy
mnw?durable=false&autodelete=true&prefetch=4
   at MassTransit.RabbitMqTransport.RabbitMqSendTransportProvider.GetSendTranspo
rt(Uri address)
   at MassTransit.RabbitMqTransport.RabbitMqSendEndpointProvider.<GetSendEndpoin
t>d__5.MoveNext()

我正在以最简单的配置从同一主机运行客户端和请求服务，以观察问题。

客户端的一些示例配置：

key="RabbitMQHost" value="rabbitmq://erinome"
key="ServiceAddress" value="rabbitmq://erinome/request_service"

以及请求服务的配置：

key="RabbitMQHost" value="rabbitmq://localhost"
key="ServiceQueueName" value="request_service"

我的问题可能是缺乏集群知识，并且未找到端点异常指向某些消息路由问题。任何帮助表示赞赏。

【问题讨论】：

所以服务使用的是本地 RabbitMQ 服务器（localhost）？在这种情况下，您似乎需要确保 erinome 主机名解析为同一本地主机。
如果我将所有内容更改为使用本地主机，那么一切都很好，客户端和服务器可以很好地通信，即使它们连接到集群的不同主机。
如果我更改为使用主机名而不是 localhost，则会出现通信问题。所有主机名都可以在 hosts 文件中解析。上下文看起来有一个包含“localhost”的响应地址，即使它应该被发送到远程主机。主机 herse 对主机 erinome DEBUG [17] (null) 的请求的响应日志 - SEND:rabbitmq://**localhost**:5672/bus-ERINOME-program-1pooyygnzw6bmco7bdjwp4rcf7?durable=false&autodelete=true

标签： c# rabbitmq cluster-computing masstransit

【解决方案1】：

如果您使用的是集群，您通常会尝试在出现节点故障的情况下确保消息队列的高可用性。在这种情况下，节点应该是独立的机器，实际上并没有运行服务——因为这些服务可能会随着节点本身而关闭。

还进行了集群，以便可以在可用节点之间复制队列 - 一种高可用性形式 - 确保服务能够在该节点发生故障时从故障节点恢复消息。

有大量关于集群 RabbitMQ 的文章，包括 RabbitMQ 官方站点和其他几个使用各种故障机制测试 RabbitMQ 集群稳定性的站点（这里想到了 Jespen）。

使用集群和分布式节点时，使用解析到集群中的活动或主节点的集群 DNS 名称非常重要 - 确保消息正确传递到网络上的集群和消费者。

最好的情况是集群中有几个节点，故障转移负载平衡器保持所有消费者连接到节点 1 直到它崩溃，然后将流量故障转移到节点 2。如果节点 1 恢复服务，它可以手动重新加入集群并将流量移回节点 2。您也可以拥有三个节点，但增加节点数会增加复制时间，因此请记住这一点。

在大多数情况下，localhost 不是您的朋友，因此不推荐。此外，如果您不复制队列，您最终可能只会在单个节点上存在消息，这将需要存在连接到可能发送消息的每个节点的消费者服务。在生产中非常混乱且难以管理。

【讨论】：