来自端点的 Web 服务集成

Question

我需要将第三方 WebService 集成到基于消息传递的架构中。我们正在使用 NServiceBus。

在 NServiceBus 上的 PluralSight 课程中，建议在集成 WebService 时为此集成创建特定的 WebService 网关端点。

第 3 方 WebService 具有用于下拉通知和确认这些通知的 API 方法。此 WebService 的客户端需要定期（例如每 15 分钟）拉取通知，并在正确处理时确认这些通知中的每一个。

建议的流程如下：

1. NServiceBus WebService 网关端点会根据通知的类型拉取通知并将消息发送到另一个 NServiceBus 端点。例如：“新客户通知”意味着向另一个 NServiceBus 端点发送 NewCustomer 消息。 “客户续订”通知意味着发送 CustomerUpdated 消息等。
2. 一旦消息被传递到另一个端点，我们将不得不通过 WebService API 调用向第三方确认通知。这里的想法是将“AcknowledgeNotification”消息发送到相同的 NServiceBus 网关端点（自身），并由消息处理程序接收。

在此处查看图表：

我的问题是：

1. 将 AcknowledgeNotification 消息从端点发送到同一端点是否是一种设计味道。 （自己）
2. 我们希望在 Azure 中托管消息传递基础结构。关于如何托管端点的任何提示，当网关端点需要一个工作角色时，它会定期提取通知？是否可以将所有端点托管在一个 Azure 云服务中，或者将每个端点托管在自己的云服务中更好？

干杯

Answer 1

问题第 1 部分

我不认为这是代码异味。我自己已经做过好几次了。这是确保与依赖项的交互成功发生的可靠方法。

我会依靠事件驱动的致谢。这将允许您的软件中有更多的可扩展点。例如：CreateCustomer 命令将发布CustomerCreated 事件。 UpdateCustomer 命令将发布 CustomerUpdated 事件。

您可以让一个处理程序通用地处理这两个事件并提交确认AckHandler: IHandle<CustomerCreated>, IHandle<CustomerUpdate>。

但回顾一下您的实际问题，我不认为这是代码异味。

---

问题第 2 部分

（下次我建议一起创建一个单独的问题）

至于在 Azure 中托管，我可能倾向于将它们托管在 WebJob 中。 WebApp 只是一个托管平台，可以同时托管一个网站和一系列 WebJobs。它们价格便宜一些，控制较少，但非常容易扩展。

请记住，在您需要水平扩展之前，您可以通过调整每个主机的并发设置来找到它可以处理的正确线程数量（NSB =6 是 100线程）。

您可以在一开始就将它们全部托管。