当通过 WCF 长时间运行的服务是后端时，在哪里托管 SignalR

Question

我敢肯定这是一个令人困惑的标题。

我有一个长期运行的 Windows 服务来处理世界上发生的事情。该服务是我系统其余部分的规范事实来源。现在我想在上面添加一个 Web 界面，以便客户可以看到实际发生的情况。起初，这只是一个带有一些 Web API 内容的 MVC5 应用程序。然后我打算使用 SignalR 2.0 和 Ember.js 让这个应用程序更具交互性和“实时性”。

客户端使用 WCF 通过命名管道与 Windows 服务进行通信。客户端（例如 Web 应用程序）可以请求例如 IEventService 的实例，将获得 WCF 代理客户端，并可以通过此接口读取有关事件的信息。很简单。

但是，Web 应用程序基本上只存在于它响应用户请求的意义上。据我了解，这不是长期存在的 WCF 客户端代理引发事件的最佳环境，因此我想知道如何托管我的 SignalR 东西。请记住，用户会登录到 MVC5 站点，但通过 SignalR 的魔力，他们将继续与服务交互，而不必向网站发出进一步的请求。

在我看来，有两种选择：

1) 将 SignalR 内容托管为 Web 应用程序的一部分。找到一种方法让它在有活动客户端时保持“长时间运行”，以便它可以通过将信息传递给连接的 Web 用户来对 WCF 客户端代理上的事件做出反应。

2) 将 SignalR 内容作为我的 Windows 服务的一部分进行托管。这已经长期运行，但我对 OWIN 以及这对我的项目意味着什么知之甚少。此外，我认为 SignalR 客户端必须连接到与提供 Web 应用程序的端口不同的端口。

关于哪个方向是正确的前进方向有什么建议吗？请记住，在极端情况下，Web 用户会在早上上班时登录，并且在退出之前的整个工作日内只有信号器流量来回（即没有 Web 请求）。我需要他们一直跟上实时事件。

有接受者吗？ :)

Answer 1

将自托管作为 Windows 服务的一部分的好处是，您可以将对客户端的调用直接与现有代码和事件集成。如果您单独托管 SignalR 服务器，您的服务和 SignalR 服务器之间会有另一层通信。

如果您已经决定为此使用 WCF 命名管道，那么无论您是自托管还是在 IIS 中托管（只要它在同一台机器上），都可能不会有什么不同。 SignalR 服务器本身总是“长时间运行”的，因为只要客户端连接，它就会接收更新。它不需要用户手动请求。

在任何情况下，您都可能需要一个 Web 服务器来提供 HTML、脚本和图像。 在我看来，让客户连接一天都不成问题。