ASP之间的通信.. NET前端和Windows Service后端
本文关键字：Windows Service 后端 前端 NET 之间 通信 ASP | 更新日期: 2023-09-27 18:16:34
我目前正在评估将web UI添加到作为Windows服务安装和运行的。net 4.5应用程序的选项。
基本思想是服务应用程序全天候运行，从网络设备收集各种数据，并将其保存在本地数据存储中(本质上，它监视这些设备)
web UI界面用于数据显示和分析目的，并发送命令&发送到后端(即服务层)的控制消息，后者依次将这些命令转发给网络设备。
与"经典"多层web应用程序的最大区别在于，即使没有用户通过web UI与之交互，服务部分也必须运行(因此其想法是将其作为Windows服务运行)。
我目前不知道如何将这个web部分(请求/响应模式，短时间运行)与服务部分(在网络上轮询，长时间运行，24/7)混合。
我的想法到目前为止:
-
将IIS核心(或任何其他web服务器)嵌入到服务应用程序中:可能会工作，但嵌入式web服务器将不知道同一台机器上的任何现有IIS配置，这使得集成和配置不简单(例如端口，身份验证，SSL等)
-
部署ASP。. NET应用程序和一个单独的服务应用程序:。NET应用程序将充当服务的facade，并且需要一种适当且可靠的方式来与服务应用程序通信(双向IPC?)。
目前感觉好像2是最好的选择。
如果有，有什么IPC建议吗?
谢谢!
最简单的(可能也是最糟糕的)方法是将你所有的逻辑嵌入到IIS中，并禁用你的应用程序关闭功能(这样IIS应用程序就会像windows服务一样运行)
我目前不知道如何将这个web部分(请求/响应模式，短时间运行)与服务部分(在网络上轮询，长时间运行，24/7)混合。
你不应该。关于第二种情况，我建议尽可能地分离你的服务应用程序和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。
我建议使用消息队列模型(ZeroMQ, MSMQ, RabbitMQ等)，这是异步IPC的优势。另一方面，可以使用数据库本身进行IPC:例如，将消息推送到某些表(或使用NoSQL的集合)并由win服务应用程序读取它们。这是消息队列的替代方案，但在大多数情况下比它更糟糕。