在 .NET Core 中应该如何处理 IPC？

Question

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

我正在考虑以下几点：

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

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

3. 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 传奇人物。

远程过程调用

对于较大的项目，您可以使用Visual ReCode自动将项目从 WCF 转换为 gRPC。我对这个项目的经验有限，但看起来很有前途，gRPC 绝对是未来......

服务热线

ServiceWire是一个非常出色的轻量级 IPC/RPC 库。跨平台，支持 TCP/IP 和命名管道通道。速度极快且易于使用 - 只需将 [Serializable] 添加到需要通过网络发送的所有类即可。我真的很喜欢这个框架。

唯一的缺点是：

• 不支持 SSL，但有自己的加密和自动压缩功能
• 没有 .NET Core 标准 DI 支持，但它的服务器实现使得这不是问题

cloudtoid 进程间（发布/订阅，不是 RPC）

Cloudtoid Interprocess是一个跨平台共享内存队列，用于进程之间的快速通信（进程间通信或IPC）。它使用共享内存映射文件在进程之间实现极快且高效的通信，并由 Microsoft 内部使用。

将其与CySharp MemoryPack混合进行序列化可以实现非常快的 IPC，但需要一些手动序列化/反序列化。