使用命名管道承载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文件，能够直接使用微软的简单例子

syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

3. 添加nuget包：Google.Protobuf,Grpc.Core,Grpc.Tools
4. 单击proto文件，在属性对话框，选择生成操做为Protobuf Compiler

创建Client

新建一个Console程序，添加上面的项目引用，输入如下代码：

var server = new NamedPipeServer("MY_PIPE_NAME");
Greeter.BindService(server.ServiceBinder, new GreeterService());
server.Start();

添加GrpcDotNetNamedPipes的nuget依赖：

Install-Package GrpcDotNetNamedPipes

创建Server

再新建一个Console程序，添加上面的项目引用，也添加那个nuget依赖和一些别的依赖，输入如下代码：

var channel = new NamedPipeChannel(".", "MY_PIPE_NAME");
var client = new Greeter.GreeterClient(channel);

var response = await client.SayHelloAsync(
	new HelloRequest { Name = "World" });

Console.WriteLine(response.Message);

而后运行就能看见熟悉的Hello World了，用起来和gRPC的标准实现没太大区别。

总结

完整代码见gRPC_Demo。

这种方式也有它的局限性，首先是Windows的命名管道与Linux上面的实现是不一样的，因此并不能实现直接跨平台通信；而后就是这个对于其余语言的开发的gRPC也不是彻底兼容的，须要其余语言开发的程序也作命名管道的适配才行，换言之，它不是通用标准。因此，对于通常的gRPC应用，仍是更推荐使用标准实现。

参考

• .NET Core 上的 gRPC 的简介
• 比较 gRPC 服务和 HTTP API
• 关于IPC性能的提问
• Linux上各类IPC性能比较