c# - .NET Core 中应该如何处理 IPC？

Question

在过去的 .NET Framework 项目中，我们的主应用程序作为 Windows 服务运行，我们使用 WCF NetNamedPipeBinding 与 WPF 前端应用程序进行通信。由于 WCF 不会成为 .NET Core 的一部分，我应该如何处理进程间通信？新应用程序(工作服务)需要处理典型的 RPC 并将数据推送到另一个进程。

我正在考虑以下几点:

命名管道。这会起作用，但这些实际上是 API 中的流。处理流和建立协议(protocol)似乎很痛苦。

gRPC，但这将涉及将许多数据模型转换为不可取的 protobuf。

SignalR，但这将涉及在我的服务中托管一个 ASP.NET Core 应用程序。似乎是矫枉过正。

任何见解或替代方案将不胜感激!

Answer 1

我会考虑三个最近的省力选择:
消息管道(新)
"MessagePipe 是一个用于 .NET 和 Unity 的高性能内存/分布式消息传递管道。它支持所有使用 Pub/Sub 的情况、CQRS 的中介模式、Prism 的 EventAggregator(V-VM 解耦)、IPC(进程间)通信)-RPC等

- Dependency-injection first
- Filter pipeline
- better event
- sync/async
- keyed/keyless
- buffered/bufferless
- singleton/scoped
- broadcast/response(+many)
- in-memory/interprocess/distributed

MessagePipe 比标准 C# 事件快，比 Prism 的 EventAggregator 快 78 倍。”
没试过，但是这个作者是.NET 传奇。
gRPC:
对于较大的项目，您可以使用 Visual ReCode自动将您的项目从 WCF 转换为 gRPC。我对这个项目的经验有限，但看起来很有希望，gRPC 绝对是 future ......
服务线:
ServiceWire是一个轻量级的 IPC/RPC 库。跨平台，支持 TCP/IP 和命名管道 channel 。非常快速且易于使用 - 只需将 [Serializable] 添加到需要通过网络发送的所有类。我真的很喜欢这个框架。
唯一的缺点是:

不支持 SSL，但有自己的加密和自动压缩

没有 .NET Core 标准 DI 支持，但它的服务器实现使其成为非问题