具有 NServiceBus 的横向扩展订阅者的横向扩展发布
我正在尝试使用 EDA 和 NServiceBus 解耦两个应用程序。目前，我有一名销售 MT 和一名库存 MT。每当通过销售 MT 请求销售时，在批准之前，销售 MT 都会调用库存 MT 以确保有可用库存。我想更改其工作方式，以便销售 MT 自动批准它，并发布异步“SaleCreated”事件，然后库存 MT 和计费 MT 将订阅该事件。如果有任何缺货商品，库存 MT 可以在离线流程中标记销售。
我的问题是，我有 10 个销售 MT 实例、5 个库存 MT 实例和 3 个计费 MT 实例。所有 3 个应用程序在位于 10/5/3 服务器前面的负载均衡器顶部都有自己的虚拟 IP。所以基本上我有 1 个虚拟出版物（SaleCreated 事件）和 2 个虚拟订阅（库存和计费订阅者）。理想情况下，由销售 MT 处理的销售应创建一条 SaleCreated 事件消息，发送至 1 个且仅 1 个库存 MT 以及 1 个且仅 1 个计费 MT。我真的很困惑这是如何工作的，因为我还没有在 NServiceBus 网站上看到这种情况的示例。另外，我不想将每个订阅的所有消息都发送到单个分发者，因为这会导致一台机器成为瓶颈。
有什么办法可以做到这一点吗？
I am trying to de-couple two applications using EDA and NServiceBus. Currently, I have a Sales MT and an Inventory MT. Whenever a sale is requested through the Sales MT, before it is approved the Sales MT will call the Inventory MT to make sure there is available stock. I want to change the way this works, so that the Sales MT just automatically approves it, and publishes an async "SaleCreated" event, which the Inventory MT and the Billing MT will then subscribe to. The Inventory MT can then flag the Sale in an offline process if there are any out-of-stock items.
My problem is that I have 10 instances of my Sales MT, 5 instances of my Inventory MT, and 3 instances of my Billing MT. All 3 applications have their own Virtual IP on top of a LoadBalancer that sits in front of the 10/5/3 servers. So basically I have 1 virtual publication (SaleCreated events) and 2 virtual subscriptions (Inventory and Billing subscribers). Ideally, a Sale that gets processed by the Sales MT, should create a SaleCreated event message to be sent to 1 and only 1 Inventory MT, and 1 and only one Billing MT. I am really confused how this will work, since I haven't seen examples of this scenario on the NServiceBus site. Also, I don't want to have all messages sent to a single distributor for each subscription, as that will cause one machine to be a bottleneck.
Is there any way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在发布方面，您可以使用数据库订阅存储选项（在生产配置文件中找到），以便所有发布实例看到相同的订阅者列表。在订阅方面，您可以使用分发器来分发传入的事件负载，以便每条消息仅分派到单个实例。请注意，您将为每个订阅者使用一个分发器，因此没有真正的瓶颈，并且分发器不执行任何实际工作，因此不必担心。
On the publishing side, you'd use the DB subscription storage option (found in the production profile) so that all publishing instances see the same list of subscribers. On the subscribing side, you'd use a distributor to distribute the load of events coming in so that each message is dispatch to only a single instance. Note that you'd use one distributor for each subscriber, so no real bottleneck, and the distributor doesn't do any actual work so it's not much of a concern.