将 .net 远程处理替换为 WEB API、WCF、SignalR 或 Akka.net

Posted 2023-03-15

【中文标题】将 .net 远程处理替换为 WEB API、WCF、SignalR 或 Akka.net

【英文标题】：Replacing .net remoting to either WEB API, WCF, SignalR or Akka.net

【发布时间】：2018-03-01 09:17:47

【问题描述】：

我有一个通过 .net 远程处理与 widnows 服务通信的 Web 应用程序。这些应用程序位于同一台服务器上并且工作正常。 Web 应用程序有一个按钮，可触发使用 .net 远程处理在 Windows 服务中启动功能。 现在我们要将 Web 应用程序放在云上，而 Windows 服务将在客户端，两者之间的通信将由 Web API 进行。我们只需要相同的功能来触发 Windows 服务中的功能。你能建议我什么是最好的解决方案吗？我可以使用以下选项之一吗？

Web API（我已经在这两个应用程序之间使用）。 WCF（同时维护两个服务可能会更痛苦）。 SignalR（它是用于我的场景的选项吗？） Akka.net（我听说我的一位同事说这也是一种选择）。

请给我最好的解决方案，并提供一个例子。

谢谢。

【参考方案1】：

Web Api 是一个不错的选择。如果您需要在客户端实时更新数据（Windows 服务），您可以将 signalR 与 web api 一起使用。

【参考方案2】：

Akka.Remote 是一个简单的工具，您可以使用它来替换相同的功能，而无需自己编写序列化或连接管理位。它应该开箱即用。这是一个示例：https://github.com/akkadotnet/akka.net/tree/dev/src/examples/Chat

【讨论】：

您好 Aaronontheweb，我对 Akka 知之甚少，但我按照链接创建了一个运行良好的示例应用程序。还有几件事我需要澄清。 - 如果我在 Azure 上部署我的 Web API 并将客户端应用程序保留在客户端计算机上，这会正常工作吗？ - 一旦收到并处理了消息，我可以从客户那里得到确认吗？请建议。谢谢。

是的，您可以 - 您只需将回复发送回线路另一端的远程参与者。尽管对于客户端-服务器类型的应用程序 Akka.Remote 可能不是最佳选择，因为它旨在帮助形成对等网络，因此它需要在连接的两端打开一个入站端点。如果您将软件部署到客户的机器上，这可能会很棘手。