我需要通过 ASP.NET 与一个 Windows 服务进行通信（以双工方式）。将 Windows 服务变成 WCF 服务并组织双向通信是否安全？
我担心服务正在尝试通信但 ASP.NET 进程正在重新加载并且消息丢失的情况。虽然在开发过程中不太可能，但我想在有很多客户的生产环境中很有可能。
我倾向于一种涉及某种持久性的解决方案：
Windows 服务和 ASP.NET 都将数据写入 SQL Server 并通过SqlDependency 获得通知
他们通过 RabbitMq 交换消息
【问题讨论】：
以下是关于两个独立系统（进程、服务器等）需要可靠通信的一般情况的一些想法：
事务模型，发送方发起通信并等待接收方的确认，然后再将消息标记为已送达。在传输失败/超时的情况下，发送者有责任保留消息并稍后重试。例如，Webhook 架构依赖于这个模型。
发布/订阅模型，被很多分布式系统使用，其中双方都依赖第三方消息代理（消息队列/服务总线机制），例如 RabbitMQ。在此架构中，发送方仅负责确保消息已成功排队。确保消息传递给接收者的责任在于消息代理。在这种情况下，您需要确保您的消息代理满足您的可靠性需求，例如：它是否仅在内存中？或者它是否也保留在磁盘上，并且不仅能够从进程回收中恢复，还能够从电源/系统回收中恢复。
正如您所说，您也可以构建自己的消息传递基础架构：发送方写入本地或云数据库或云队列/服务总线，接收方轮询并使用消息。
所以，一些指导方针：
如果您需要向外扩展（拥有多台服务器）并且他们需要以某种方式协作处理这些消息，那么请在数据库或云队列解决方案（例如 Azure SQL 或 Azure 队列）上进行初始投资.
否则，如果您的服务只需要在一台服务器内进行通信，那么您可以使用数据库方法或使用满足您的持久性/可靠性要求的队列服务。对于这种情况，RabbitMQ 似乎是一个强大的解决方案。
【讨论】：