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

发布于 2024-10-04 17:13:15 字数 482 浏览 5 评论 0原文

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

假设我有 2 个服务:数据访问 (DA) 和处理引擎 (PE)。

PE 执行 2 个任务:

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

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

我问你们的问题是,你们过去做了什么来解决基于消息的架构的这些类型的问题。我在这里创造了大罪,并假设消息将以某种顺序到达,这与事实相去甚远。

I'm looking for an alternative design or maybe a workaround this issue I've encountered with MSMQ messaging. Right now I'm using NServiceBus (not the problem) for my service architecture. It works really well and I like it a lot. However, I'm having some trouble with services that I want to initialized at start up before processing the normal workload messages. Let me explain my situation.

Let's say I have 2 services, Data Access (DA), and a Processing Engine (PE).

The PE performs 2 tasks:

  1. Load some configuration information from the DA.
  2. Process incoming client requests.

The problem is that because of the configuration. I cannot guarantee after the service starts up that the first messages it receives are the configuration messages. I know that you can purge all the messages from the queue at start up but I don't want to do this because I need to process all the messages. Secondly, even if I purge all the messages in the queue there is still no guarantee that the configuration will load first, in fact due to the high volume of messages this service is processing it's highly unlikely to be the first message received.

My question to you guys is what have you done in the past to get around these types of issues with the message based architectures. I've created the cardinal sin here and assumed that the messages will arrive in some kind of order, which couldn't be further from the truth.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

删除→记忆 2024-10-11 17:13:15

您可以使用两个不同的队列。一是为了工作量。第二个用于配置(或元数据)。其他选项是使用优先级。您可以为配置消息设置更高的优先级,以便首先读取它们。

也就是说,我根本不理解你的架构。 DA服务如何知道PE已经重启。它需要知道这一点才能发送配置消息。

You can use two different queues. One for the workload. And the second for the configuration (or metadata). Other option is using priorities. You can set higher priority on configuration messages so they will be read first.

That said, I don't understand your architecture at all. How will the DA service know that the PE has restarted. It needs to know that in order to send configuration messages.

稀香 2024-10-11 17:13:15

您确实应该考虑在每个需要它的服务中加载配置。至于解决方法,您可以向另一个端点发送请求消息以进行配置,然后继续调用 Bus.HandleCurrentMessageLater() 直到收到相关回复。这不是最佳选择,因为非配置消息将在队列中累积,直到配置发生。

You should really consider loading the configuration in each service that requires it. As for workarounds, you could send a request message to the other endpoint for the configuration and then keep calling Bus.HandleCurrentMessageLater() until you get the correlated reply back. This would not be optimal as the non-configuration messages would build up in the queue until the configuration occurred.

陌路黄昏 2024-10-11 17:13:15

每个服务都应该对自己的数据负责。
因此您的处理引擎应该知道它需要知道才能正常工作的确切配置选项。
看来您正在混淆一些东西,并拥有一个使用 2 个 Windows 服务的服务,其中一个服务依赖于另一个服务。

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

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

each and every service should be responsible for his own data.
so your processing engine should know the exact configuration options it needs to know to work properly.
it seems that you are mixing up some things and have a service that uses 2 windows services where one service is dependent on another service.

usually your processing engine would have a direct database access for something that it operates on. if there are configuration settings that are configured from within another service your processing engine would store that configuration options and would offer interfaces to update that configuration options. so if your processing engine is online your client requests can be handled regardless if your database access process works or not. if the database access process comes online and detects configuration changes it would inform all dependent processes of the configuration changes.

i would recommend to reconsider your architecture.

我一向站在原地 2024-10-11 17:13:15

你看过经销商吗?
另请参阅 ICustomConfigurationSource,您可以使用它在 Windows 服务启动时(在开始处理消息之前)检索端点配置

Have you looked at the distributor?
Also look at ICustomConfigurationSource you can use it to retrieve endpoint config when windows service starts (before it starts processing messages)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文