时间戳

首页 > 解决方案 > .NET Core 中应该如何处理 IPC？

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

问题描述

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

我正在考虑以下几点：

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

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

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

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

标签： c#asp.net-core.net-core

解决方案

我会考虑三个最近的省力选择：

消息管道（新）

" 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 绝对是未来......

服务线：

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

唯一的缺点是：

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

推荐阅读