来自端点的 Web 服务集成
Webservice integration from endpoint
我需要将第三方 WebService 集成到基于消息传递的体系结构中。我们正在使用 NServiceBus。
在 NServiceBus 上的 PluralSight 课程中，建议在集成 WebService 时为该集成创建特定的 WebService 网关端点。
第 3 方 WebService 有 API 方法用于下拉通知和确认这些通知。此 WebService 的客户端需要定期（例如每 15 分钟）拉取通知并在正确处理后确认这些通知中的每一个。
建议的流程如下：
- NServiceBus WebService 网关端点将根据通知类型提取通知并将消息发送到另一个 NServiceBus 端点。例如："new customer notification" 表示将 NewCustomer 消息发送到另一个 NServiceBus 端点。 "customer renewed" 通知意味着发送 CustomerUpdated 消息等。
- 一旦消息被传递到另一个端点，我们将不得不通过 WebService API 调用向第 3 方确认通知。这里的想法是将 "AcknowledgeNotification" 消息发送到同一个 NServiceBus 网关端点（自身），并让消息处理程序接收它。
参见此处的图表：
我的问题是：
- 将 AcknowledgeNotification 消息从一个端点发送到同一端点是一种设计风格吗？ (自己)
- 我们想在 Azure 中托管消息传递基础结构。关于如何托管端点的任何提示，当网关端点需要工作者角色时，它会定期拉取通知？是否可以在一个 Azure 云服务中托管所有端点，还是将每个端点托管在它自己的云服务中更好？
干杯
问题第 1 部分
我不认为这是代码味道。我自己做过几次。这是确保与依赖项的交互成功发生的可靠方法。
我会依靠事件驱动的致谢。这将允许在您的软件中有更多的可扩展点。例如：CreateCustomer 命令将发布 CustomerCreated 事件。 UpdateCustomer 命令将发布 CustomerUpdated 事件。
您可以让一个处理程序通用地处理这两个事件并提交确认 AckHandler: IHandle<CustomerCreated>, IHandle<CustomerUpdate>。
但回顾一下您的实际问题，我不认为这是代码味道。
问题第 2 部分
（下次我建议一起创建一个单独的问题）
至于在 Azure 中托管，我可能倾向于将它们托管在 WebJob 中。 WebApp 只是一个托管平台，可以托管一个 WebSite 和一系列 WebJobs。它们更便宜一些，控制更少，但扩展故事超级简单。
请记住，在需要水平扩展之前，您可以通过调整每个主机的并发设置来垂直扩展，以找到它可以处理的正确线程数（NSB < 5 是最多 20 个线程；NSB >=6是 100 个线程）。
您可以一开始就将它们全部托管。
我需要将第三方 WebService 集成到基于消息传递的体系结构中。我们正在使用 NServiceBus。
在 NServiceBus 上的 PluralSight 课程中，建议在集成 WebService 时为该集成创建特定的 WebService 网关端点。
第 3 方 WebService 有 API 方法用于下拉通知和确认这些通知。此 WebService 的客户端需要定期（例如每 15 分钟）拉取通知并在正确处理后确认这些通知中的每一个。
建议的流程如下：
- NServiceBus WebService 网关端点将根据通知类型提取通知并将消息发送到另一个 NServiceBus 端点。例如："new customer notification" 表示将 NewCustomer 消息发送到另一个 NServiceBus 端点。 "customer renewed" 通知意味着发送 CustomerUpdated 消息等。
- 一旦消息被传递到另一个端点，我们将不得不通过 WebService API 调用向第 3 方确认通知。这里的想法是将 "AcknowledgeNotification" 消息发送到同一个 NServiceBus 网关端点（自身），并让消息处理程序接收它。
参见此处的图表：
我的问题是：
- 将 AcknowledgeNotification 消息从一个端点发送到同一端点是一种设计风格吗？ (自己)
- 我们想在 Azure 中托管消息传递基础结构。关于如何托管端点的任何提示，当网关端点需要工作者角色时，它会定期拉取通知？是否可以在一个 Azure 云服务中托管所有端点，还是将每个端点托管在它自己的云服务中更好？
干杯
问题第 1 部分
我不认为这是代码味道。我自己做过几次。这是确保与依赖项的交互成功发生的可靠方法。
我会依靠事件驱动的致谢。这将允许在您的软件中有更多的可扩展点。例如：CreateCustomer 命令将发布 CustomerCreated 事件。 UpdateCustomer 命令将发布 CustomerUpdated 事件。
您可以让一个处理程序通用地处理这两个事件并提交确认 AckHandler: IHandle<CustomerCreated>, IHandle<CustomerUpdate>。
但回顾一下您的实际问题，我不认为这是代码味道。
问题第 2 部分
（下次我建议一起创建一个单独的问题）
至于在 Azure 中托管，我可能倾向于将它们托管在 WebJob 中。 WebApp 只是一个托管平台，可以托管一个 WebSite 和一系列 WebJobs。它们更便宜一些，控制更少，但扩展故事超级简单。
请记住，在需要水平扩展之前，您可以通过调整每个主机的并发设置来垂直扩展，以找到它可以处理的正确线程数（NSB < 5 是最多 20 个线程；NSB >=6是 100 个线程）。
您可以一开始就将它们全部托管。