NServiceBus设计帮助（使用消息初始化服务实例）

Question

我正在寻找替代设计或者解决这个问题，我在MSMQ消息传递中遇到过这个问题。现在我正在为我的服务架构使用NServiceBus（不是问题）。它运作得很好，我非常喜欢它。但是，在处理正常工作负载消息之前，我想要在启动时初始化的服务遇到一些问题。让我解释一下我的情况。

假设我有2项服务，数据访问（DA）和处理引擎（PE）。

PE执行2项任务：

1. 从DA加载一些配置信息。
2. 处理传入的客户端请求。

问题在于因为配置问题。在服务启动后，我无法保证它收到的第一条消息是配置消息。我知道您可以在启动时清除队列中的所有消息，但我不想这样做，因为我需要处理所有消息。其次，即使我清除队列中的所有消息，仍然无法保证配置将首先加载，实际上由于此服务处理的消息量很大，因此它很可能不是第一个收到的消息。

我向你们提出的问题是你过去做过什么来解决基于消息的架构这些类型的问题。我在这里创造了一个主要的罪恶，并假设这些信息会以某种顺序到达，这不可能是事实。

Answer 1

您可以使用两个不同的队列。一个用于工作量。第二个是配置（或元数据）。其他选择是使用优先级。您可以在配置消息上设置更高的优先级，以便首先读取它们。

那就是说，我根本不了解你的架构。 DA服务如何知道PE已重新启动。它需要知道为了发送配置消息。

Answer 2

您应该考虑在需要它的每个服务中加载配置。至于变通方法，您可以向另一个端点发送请求消息以进行配置，然后继续调用Bus.HandleCurrentMessageLater（），直到获得相关的回复。这不是最佳的，因为在配置发生之前，非配置消息会在队列中累积。

Answer 3

每个服务都应该对自己的数据负责。 因此，您的处理引擎应该知道正常工作所需的确切配置选项。 看起来你混合了一些东西并且有一个使用2个服务的服务，其中一个服务依赖于另一个服务。

通常，您的处理引擎会对其操作的内容进行直接数据库访问。如果存在从另一个服务中配置的配置设置，则处理引擎将存储该配置选项，并提供更新该配置选项的接口。因此，如果您的处理引擎处于联机状态，则无论数据库访问过程是否有效，都可以处理客户端请求。如果数据库访问进程联机并检测到配置更改，它将通知所有相关进程配置更改。

我建议重新考虑你的架构。

Answer 4

你看过经销商了吗？ 另请查看ICustomConfigurationSource，您可以在Windows服务启动时（在开始处理消息之前）使用它来检索端点配置