有一種Windows服務需要與ASP.NET進行通信（採用雙工方式）。將Windows服務轉換爲WCF服務並組織雙向通信安全嗎？與ASP.NET的WCF服務通信安全嗎
我很擔心服務試圖進行通信但ASP.NET進程正在重新加載並且消息丟失的場景。雖然在開發過程中不大可能，但我猜這很可能與許多客戶一起製作。
我傾向於一種解決方案，包括某種形式的持久性：
無論是Windows服務和ASP.NET寫數據到SQL Server，並通過SqlDependency
他們交換得到通知通過RabbitMq發送消息
下面是關於兩個獨立系統（進程，服務器等）n的一般情況的一些想法EED可靠地進行通信：
Transaction模型，其中發送方發起通信，並等待確認從接收方傳送作爲標記消息之前。在傳輸失敗/超時的情況下，發件人有責任保留郵件並稍後重試。例如，Webhook體系結構依賴於此模型。
發佈/訂閱模式，通過大量的分佈式系統的，雙方當事人依靠第三方消息代理（消息隊列/服務總線機制），如RabbitMQ的使用。在此體系結構中，發件人只負責確保郵件已成功排隊。確保郵件傳遞給收件人的責任在郵件代理上。在這種情況下，您需要確保消息代理滿足您的可靠性需求，例如：是否僅在內存中？還是它也堅持磁盤，並且不僅能夠從一個過程回收中恢復，而且還能夠從電源/系統回收中恢復。
而且像你說的，你可以建立自己的消息基礎設施太：發送寫入本地或雲數據庫或雲隊列/服務總線，以及接收器投票和消耗的消息。
所以，有一些準則：
如果你需要向外擴展（多臺服務器），他們需要這些消息不知何故合作，然後讓你的數據庫或雲上的初始投資隊列解決方案（例如Azure SQL或Azure隊列）。否則，如果您的服務只需要在一臺服務器內通信，那麼您可以使用數據庫方法或使用滿足您的持久性/可靠性要求的隊列服務。 RabbitMQ對於這種情況似乎是一個可靠的解決方案。