NServicebus时间敏感拍卖实现

我们正在使用NServicebus设计一个系统，该系统必须解决一个拍卖场景：我们希望向一组能够对某个项目进行竞标的公司发送一条消息。在我们收到所有的出价后，我们希望将该项目发送给出价最高的投标人

我们最初认为这种场景非常适合NServicebus：Pub/sub用于发送消息（例如BidOnItem或ItemAvailable），消息处理程序为每个感兴趣的公司订阅该消息，以及存储我们收到的不同出价的传奇故事，我们完成了

在正常的拍卖中，我们可以设定一个5分钟的暂停时间，然后根据我们收到的最高价格决定谁能得到该物品。我们没有那种奢侈。我们遇到的问题是，我们的特定场景有一个棘手的、不可协商的业务需求：拍卖对时间非常敏感。秒很重要。我们想做的是，一旦所有公司都做出回应，就决定由谁获得该商品。通常这将在几秒钟内发生。我们想确定所有订阅者响应的第二个问题。显然，我们还将实现一个超时，但这将是一个例外，而不是规则。如果我们想确定是否每个人都回复了，我们需要一个类似于订阅BidOnItem消息的所有端点上所有处理程序的列表。NServicebus API似乎没有提供此信息

我们还必须实现一些未来的需求，这些需求以数据充实和批准/拒绝决策为中心，如果知道发布/子频道上的所有处理程序是否都已响应，这将大大有助于我们实现这些需求。我知道这散发着请求/回复的味道，这是NServicebus不鼓励的，因为它会导致耦合，但这一要求对于许多在核心总线基础设施之外很难实现的流程来说是基本的。从这个意义上讲，它感觉很像NServicebus提供的Saga.ReplyToOriginator

---

解决这个问题的“N服务总线方式”是什么？

在这些拍卖场景中，发布/订阅通常不是一种方式。如果您的传奇故事会对您的投标人进行定期测试/回复，该怎么办

S:OnActionCreated（带有投标人名单，或者你可以在某处找到他们） 事件中的每位投标人。投标人 -总线发送（请求来自（投标人）） 设置超时（X）

S:OnBidResponse 标书.添加（响应.投标人，响应.标书）

if（bids.Count（）=Data.TotalBidders） 完成导入（）

S:准时

---

CompleteAuction（）

这看起来像是我们考虑的“变通方法”之一。示例中的RequestBidFrom方法将返回RequestBidFromCompanyX、RequestBidFromCompanyY等的实例和处理程序，以匹配这些类（可选地分布在多个端点上）是否正确？这取决于请求的不同程度。我可能会使用相同的消息，让“集成”端点负责不同投标人之间的映射。然后，该集成端点可以决定使用不同的消息来更好地扩展、监控等，该集成端点也可以是保存活动投标人列表的端点。请记住，在消息传递中，一个请求可能导致多个响应。我知道你要去哪里。这感觉就像我们在建造一些酒吧/酒吧可以免费提供给我们的东西。我们想听到的是，为什么发布/订阅不是我们要走的路：是因为当前NServicebus API的局限性，还是因为它本身不是一个好模式？如果是，为什么？发布/订阅的一个关键原则是，发布者不应该知道其订阅者。可能是0或数百万，出版商不应该在意。考虑到您的要求：“如果我们想确定是否每个人都回复了”，这就是pub/sub在这里不好的原因。这个要求意味着您必须知道谁应该回答==reg/response。这有用吗？