.NET使用命名管道承载gRPC

Posted DotNet开发跳槽

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了.NET使用命名管道承载gRPC相关的知识,希望对你有一定的参考价值。

最近GRPC很火,感觉整RPC不用GRPC都快跟不上时髦了。

gRPC设计

gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统,自然而然就盯上了它,但是它真能够解决所有问题吗?不见得,先看看他的优点:

gRPC的主要优点:

  • 现代高性能轻量级 RPC 框架。

  • 协定优先 API 开发,默认使用协议缓冲区,允许与语言无关的实现。

  • 可用于多种语言的工具,以生成强类型服务器和客户端。

  • 支持客户端、服务器和双向流式处理调用。

  • 使用 Protobuf 二进制序列化减少对网络的使用。

对应的适用场景:

  • 微服务:gRPC 设计用于低延迟和高吞吐量通信。gRPC 对于效率至关重要的轻量级微服务非常有用。

  • 点对点实时通信:gRPC 对双向流式传输提供出色的支持。gRPC 服务可以实时推送消息而无需轮询。

  • 多语言环境:gRPC 工具支持所有常用的开发语言,因此,gRPC 是多语言环境的理想选择。

  • 网络受限环境:gRPC 消息使用 Protobuf(一种轻量级消息格式)进行序列化。gRPC 消息始终小于等效的 JSON 消息。

gRPC还是有缺点的:

  • 浏览器支持受限:绝大数浏览器不支持HTTP/2

  • 非人工可读取:proto文件规定的格式在通讯中会序列化成二进制数据,人工解析较为困难。

不适用的场景与替代:

  • 浏览器可访问的API:gRPC 在浏览器中未受到完全支持。 gRPC-Web 可以提供浏览器支持,但它具有局限性并引入了服务器代理。

  • 广播实时通信:gRPC 支持通过流式传输进行实时通信,但不存在将消息广播到注册连接的概念。例如,在聊天室方案中,应将新的聊天消息发送到聊天室中的所有客户端,这要求每个 gRPC 调用将新的聊天消息单独流式传输到客户端。SignalR 是适用于此方案的框架。SignalR 具有持久性连接的概念,并内置对广播消息的支持。

  • 进程间通信:进程必须托管 HTTP/2 服务器才能接受传入的 gRPC 调用。对于 Windows,进程间通信管道是一种快速、轻便的通信方法。

目标分析

我需要有一个能够实现远程调用的好办法,系统支持Windows就好,最好性能高一些(数据量大),程序小一点,但是我也不想直接处理二进制数据流(最好能有封装的框架)。

考虑进程通信常用的:

  • 信号/信号量:简单,能够承载的消息内容较少。

  • 消息队列:支持消息,功能较为强大。

  • 共享内存:性能最强,但只限于单机。

  • 管道:性能较强,但是只支持stream。

  • Socket:最灵活,但是需要有网卡。

首先排除信号/信号量,处理的信息量太小了;然后共享内存也排除,只能单机不符合我的要求;剩下的三个似乎都可以满足要求,可以在这个基础上建立RPC,而gRPC就是建立在socket(HTTP/2)上的,就像上面讲的,要自己集成一个HTTP/2服务器(比如Kestrel)才行,不够轻量化;剩下的两个Windows都有內建支持,可以考虑一下。

本着拿来主义的思想,我在github上找到一个grpc-dotnet-namedpipes,支持在命名管道上实现gRPC,相当于在stream上封装了一层,不用直接处理二进制数据流了。

用作者自己的话来说,这么做相较于普通的gRPC有几个优点:

  • 更优秀的访问控制;

  • 纯.NET库,不需要带ASP.NET Core或者超过3MB的非托管库依赖;

  • 启动时间更快

  • 2-3倍的数据吞吐量

  • 没有防火墙警告

  • 不需要网卡

实现

建立一个proto

  1. 创建一个.NET Library

  2. 添加一个proto文件,可以直接使用微软的简单例子