我目前正在评估将Web UI添加到作为Windows服务安装并运行的.NET 4.5应用程序的选项。
基本思想是服务应用程序全天候运行并从网络设备收集各种数据并将它们保存在本地数据存储中（实际上，它监视这些设备）
Web UI界面用于数据呈现和分析目的，并发送命令＆amp;控制到后端（即服务层）的消息，后端又将这些命令发送到网络设备。
“经典”多层Web应用程序的最大区别在于，即使没有用户通过Web UI与其进行交互，服务部分也必须运行（因此我们的想法是将其作为Windows服务运行） ）。
我目前不知道如何将此Web部件（请求/响应模式，短期运行）与服务部分混合（在网络上轮询，长时间运行，全天候）。
到目前为止我的想法：
将IIS Core（或任何其他Web服务器）嵌入到服务应用程序中可能会有效但嵌入式Web服务器不会知道同一台机器上的任何现有IIS配置集成和配置不是直截了当的（例如端口，身份验证，SSL等）
在IIS和单独的服务应用程序上部署ASP.NET应用程序： ASP.NET应用程序只是作为服务的外观，需要一种正确可靠的方式与服务应用程序通信（双向IPC？）。
目前感觉好像2是最好的选择。
如果有，是否有任何IPC建议？
谢谢！
答案 0 :(得分：0)
最简单（也可能是最差）的方法是将所有逻辑嵌入到IIS中并禁用应用程序的关闭（这样IIS应用程序就像Windows服务一样运行）。
我目前不知道如何将此Web部件（请求/响应模式，短期运行）与服务部分混合（在网络上轮询，长时间运行，全天候）。
你不应该。关于第二种情况，我建议尽可能地将您的服务应用和web ui应用解耦。这样可以最大限度地减少依赖关系和IPC（从而提高可伸缩性和稳定性）。
在这种情况下，Windows服务可以实现其最小角色：collecting various data from network devices and persists them in a local data store（唯一需要24/7的功能）。 IIS应用程序可以实现所有与UI相关的功能（数据表示和分析角色）和用户命令。这样您就不需要将所有演示文稿功能委派给Windows服务应用程序。 IPC仅用于sending command & control messages to the backend (i.e. the service layer) which in turn fowards these commands to the network devices。
我建议使用异步IPC的消息队列模型（ZeroMQ，MSMQ，RabbitMQ等）及其优点。另一方面，可以将数据库本身用于IPC：例如将消息推送到某个表（如果使用NoSQL，则为集合），并通过win服务应用程序读取它们。这是消息队列的替代方案，但在大多数情况下比它更糟糕。