最近GRPC很火，感覺整RPC不用GRPC都快跟不上時髦了。 gRPC設計 gRPC是一種與語言無關的高性能遠程過程調用 (RPC) 框架。剛好需要使用一個的RPC應用系統，自然而然就盯上了它，但是它真能夠解決所有問題嗎？不見得，先看看他的優點： gRPC的主要優點： 現代高性能輕量級 RPC 框架 ...
最近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
- 創建一個.NET Library
- 添加一個proto文件，可以直接使用微軟的簡單例子
syntax = "proto3";
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
- 添加nuget包：
Google.Protobuf,Grpc.Core,Grpc.Tools - 單擊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應用，還是更推薦使用標準實現。
