gRPC入門與實操(.NET篇)

来源:https://www.cnblogs.com/newton/archive/2023/01/10/17033789.html
-Advertisement-
Play Games

為什麼選擇 gRPC 歷史 長久以來，我們在前後端交互時使用WebApi + JSON方式，後端服務之間調用同樣如此（或者更久遠之前的WCF + XML方式）。WebApi + JSON 是優選的，很重要的一點是它們兩者都是平臺無關的三方標準，且足夠語義化，便於程式員使用，在異構（前後端、多語言後端 ...


為什麼選擇 gRPC

歷史

長久以來，我們在前後端交互時使用WebApi + JSON方式，後端服務之間調用同樣如此（或者更久遠之前的WCF + XML方式）。WebApi + JSON 是優選的，很重要的一點是它們兩者都是平臺無關的三方標準，且足夠語義化，便於程式員使用，在異構（前後端、多語言後端）交互場景下是不二選擇。然而，在後端服務體系改進特別是後來微服務興起後，我們發現，前後端交互理所當然認可的 WebApi + JSON 在後端體系內顯得有點不太合適：

  1. JSON 字元編碼方式使得傳輸數據量較大，而後端一般並不需要直接操作 JSON，都會將 JSON 轉為平臺專有類型後再處理；既然需要轉換，為什麼不選擇一個數據量更小，轉換更方便的格式呢？
  2. 調用雙方要事先約定數據結構和調用介面，稍有變動就要手動更新相關代碼（Model 類和方法簽名）；是否可以將約定固化為文檔，服務提供者維護該文檔，調用方根據該文檔可以方便地生成自己需要的代碼，在文檔變化時代碼也可以自動更新？
  3. [之前] WebApi 基於的 Http[1.1] 協議已經誕生 20 多年，其定義的交互模式在今日已經捉襟見肘；業界需要一個更有效率的協議。

高效傳輸-Http2.0

我們先來說第 3 個問題，其實很多大廠內部早已開始著手處理，並誕生了一些應用廣泛的框架，如阿裡開源的Dubbo，直接拋棄了 Http 改為基於 Tcp 實現，效率得到明顯提升，不過 Dubbo 依賴 Java 環境，無法跨平臺使用，不在我們考慮範圍。

另一個大廠 Google，內部也在長期使用自研的Stubby框架，與 Dubbo 不同的是，Studdy 是跨平臺的，但是 Google 認為 Studdy 不基於任何標準，而且與其內部基礎設施緊密耦合，並不適合公開發佈。

同時 Google 也在對 Http1.1 協議進行增強，該項目是 2012 年提出的 SPDY 方案，其優化了 Http 協議層，新增的功能包括數據流的多路復用、請求優先順序以及HTTP報頭壓縮。Google 表示，引入 SPDY 協議後，在實驗室測試中頁面載入速度比原先快 64%。巨大的提升讓大家開始從正面看待和解決老版本 Http 協議的問題，這也直接加速了 Http2.0 的誕生。實際上，Http2.0 是以 SPDY 為原型進行討論和標準化的，當然也做了更多的改進和調整。

隨著 Http2.0 的出現和普及，許多與 Stubby 相同的功能已經出現在公共標準中，包括 Stubby 未提供的其他功能。很明顯，是時候重做 Stubby 以利用這種標準化，並將其適用範圍擴展到分散式計算的最後一英里，支持移動設備(如安卓)、物聯網(IOT)、和瀏覽器連接到後端服務。

2015 年 3 月，Google決定在公開場合構建下一版 Stubby，以便與業界分享經驗，併進行相關合作，也就是本文的主角gRPC。

高效編碼-protobuf

回頭來看第 1 個問題，解決起來相對比較簡單，無非是將傻瓜式字元編碼轉為更有效的二進位編碼（比如數字 10000 JSON 編碼後是 5 個位元組，按整型編碼就是 4 個位元組），同時加上些事先約定的編碼演算法使得最終結果更緊湊。常見的平臺無關的編碼格式有MessagePack和protobuf等，我們以 protobuf 為例。

protobuf 採用 varint 和 處理負數的 ZigZag 兩種編碼方式使得數值欄位占用空間大大減少；同時它約定了欄位類型和標識，採用 TLV 方式，將欄位名映射為小範圍結果集中的一項（比如對於不超過 256 個欄位的數據體來說，不管欄位名本身的長度多少，每個欄位名都只要 1 個位元組就能標識），同時移除了分隔符，並且可以過濾空欄位（若欄位沒有被賦值，那麼該欄位不會出現在序列化結果中）。

高效編程-代碼生成工具

第 2 個問題呢，其實需要的就是[每個平臺]一套代碼生成工具。生成的代碼需要覆蓋類的定義、對象的序列化/反序列化、服務介面的暴露和遠程調用等等必要的模板代碼，如此，開發人員只需要負責介面文檔的維護和業務代碼的實現（很自然的面向介面編程：））。此時，採用 protobuf 的gRPC自然而然的映入眼帘，因為對於目前所有主要的編程語言和平臺，都有 gRPC 工具和庫，包括 .NET、Java、Python、Go、C++、Node.js、Swift、Dart、Ruby 以及 PHP。可以說，這些工具和庫的提供，使得 gRPC 可以跨多種語言和平臺一致地工作，成為一個全面的 RPC 解決方案。

gRPC 在 .NET 中的使用

ASP.NET Core 3.0 開始，支持gRPC作為 .NET 平臺中的“一等公民”。

服務端

在 VS 中新建ASP.NET Core gRPC 服務，會發現在項目文件中自動引入了Microsoft.NET.Sdk.Web類庫，很明顯，gRPC 服務仍然是 Web 服務，畢竟它走的是 Http 協議。同時還引入了Grpc.AspNetCore類庫，該類庫引用了幾個子類庫需要瞭解下：

  • Google.Protobuf：包含 protobuf 預定義 message 類型在 C# 中的實現；
  • Grpc.Tools：上面講到的代碼生成工具，編譯時使用，運行時不需要，因此依賴項標記為PrivateAssets="All"；
  • Grpc.AspNetCore.Server：服務端專用；
  • Grpc.Net.ClientFactory：客戶端專用，如果只是提供服務的話，那麼該類庫可以移除。

定義介面文件：

syntax = "proto3";

// 指定自動生成的類所在的命名空間，如果不指定則以下麵的 package 為命名空間，這主要便於本項目內部的模塊劃分
option csharp_namespace = "Demo.Grpc";

// 對外提供服務的命名空間
package TestDemo;

// 服務
service Greeter {
  // 介面
  rpc SayHello (HelloRequest) returns (HelloReply);
}

// 不太好的一點是就算只有一個基礎類型欄位，也要新建一個 message 進行包裝
message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

然後把它包含到項目文件中：

<ItemGroup>
  <Protobuf Include="Protos\greeter.proto" GrpcServices="Server" />
</ItemGroup>

編譯一下，Grpc.Tools 將幫我們生成 GreeterBase 類及兩個模型類:

public abstract partial class GreeterBase
{
    public virtual Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        throw new RpcException(new Status(StatusCode.Unimplemented, ""));
    }
}

public class HelloRequest
{
    public string Name { get; set; }
}

public class HelloReply
{
    public string Message { get; set; }
}

這裡的 SayHello 是個空實現，我們新建一個實現類並填充業務邏輯，比如：

public class GreeterService : GreeterBase
{
    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply { Message = $"Hello {request.Name}" });
    }
}

最後將服務添加到路由管道，對外暴露：

using Demo.Grpc.Services;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddGrpc();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.MapGrpcService<GreeterService>();

app.Run();

protobuf-net.Grpc

如果覺得寫 .proto 文件太彆扭，希望可以按傳統方式寫介面，那麼社區項目protobuf-net.Grpc值得嘗試，使用它可以它通過特性批註的 .NET 類型來定義應用的 gRPC 服務和消息。

首先我們不需要再引用 Grpc.AspNetCore，而是改為引用 protobuf-net.Grpc 庫。同樣也不需要寫 .proto 文件，而是直接寫介面類：

using ProtoBuf.Grpc;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Threading.Tasks;

namespace Demo.Grpc;

[DataContract]
public class HelloReply
{
    [DataMember(Order = 1)]
    public string Message { get; set; }
}

[DataContract]
public class HelloRequest
{
    [DataMember(Order = 1)]
    public string Name { get; set; }
}

[ServiceContract(Name = "TestDemo.GreeterService")]
public interface IGreeterService
{
    [OperationContract]
    Task<HelloReply> SayHelloAsync(HelloRequest request, CallContext context = default);
}

註意其中特性的修飾。

寫完實現類後，在 Program.cs 中註冊即可，此處不再贅述。

使用 protobuf-net.Grpc，我們不需要寫 .proto 文件，但是調用方特別是其它平臺的調用方，需要 .proto 文件來生成相應的客戶端，難道我們還要另外再寫一份嗎？別急，我們可以引入protobuf-net.Grpc.AspNetCore.Reflection，它引用的protobuf-net.Grpc.Reflection提供了根據 C# 介面生成 .proto 文件的方法；同時使用它還便於客戶端測試，同Grpc.AspNetCore.Server.Reflection的作用一樣，下文會講到。

異常處理

.Net 為 gRPC 提供了攔截器機制，可新建一個攔截器統一處理業務異常，比如：

public class GrpcGlobalExceptionInterceptor : Interceptor
{
    private readonly ILogger<GrpcGlobalExceptionInterceptor> _logger;

    public GrpcGlobalExceptionInterceptor(ILogger<GrpcGlobalExceptionInterceptor> logger)
    {
        _logger = logger;
    }

    public override async Task<TResponse> UnaryServerHandler<TRequest, TResponse>(
        TRequest request,
        ServerCallContext context,
        UnaryServerMethod<TRequest, TResponse> continuation)
    {
        try
        {
            return await continuation(request, context);
        }
        catch (Exception ex)
        {
            _logger.LogError(new EventId(ex.HResult), ex, ex.Message);
            
            // do something

            // then you can choose throw the exception again
            throw ex;
        }
    }
}

上述代碼在處理完異常後重新拋出，旨在讓客戶端接收處理該異常，然而，實際上客戶端是無法接收到該異常信息的，除非服務端拋出的是RpcException；同時，為使客戶端得到正確的 HttpStatusCode（預設是 200，即使客戶端得到是 RpcException），需要顯式給HttpContext.Response.StatusCode賦值，如下：

// ...

catch(Exception ex)
{
    var httpContext = context.GetHttpContext();
    httpContext.Response.StatusCode = StatusCodes.Status400BadRequest;
             
    // 註意，RpcException 的 StatusCode 和 Http 的 StatusCode 不是一一對應的
    throw new RpcException(new Status(StatusCode.XXX, "some messages"));
}

// ...

我們可以在構造 RpcException 對象時傳遞Metadata，用於攜帶額外的數據到客戶端，如果需要傳遞複雜對象，那麼要先按約定序列化成位元組數組。

攔截器邏輯完成後，需要在服務註入時設置如下：

builder.Services.AddGrpc(options =>
{
    options.Interceptors.Add<GrpcGlobalExceptionInterceptor>();
});

測試

服務端完成後，如果要藉助Postman或者gRPCurl測試，那麼它們其實就是調用服務的客戶端，要讓它們事先知道服務約定信息，有兩種方法：

  1. 給它們提供 .proto 文件，這個很好理解，關於服務的所有信息就定義在 .proto 文件中；
  2. 服務端暴露一個可以獲取服務信息的介面。

如果要用方法 2，那麼要先引入Grpc.AspNetCore.Server.Reflection類庫，然後在 Program.cs 中註冊介面：

// ...
builder.Services.AddGrpcReflection();

var app = builder.Build();

// ...

IWebHostEnvironment env = app.Environment;

if (env.IsDevelopment())
{
    app.MapGrpcReflectionService();
}

客戶端

客戶端不需要 Grpc.AspNetCore.Server，所以我們直接引用 Google.Protobuf、Grpc.Tools、Grpc.Net.ClientFactory。

將服務端提供的 .proto 文件添加到項目中，併在項目文件中包含：

<ItemGroup>  
  <Protobuf Include="Protos\greeter.proto" GrpcServices="Client" />
</ItemGroup>

註意，如果只需要服務端提供的部分介面，那麼 .proto 文件中只保留必要的介面即可，真正做到按需索取：）。

我們還可以更改 .proto 文件中 message 的欄位名（只要不改動欄位類型和順序），不會影響服務的調用。這也直接反映了 protobuf 不是按欄位名而是事先定義的欄位標識編碼的。

由此，假如我們有多個 .proto 文件，使用到了相同結構的 message，無所謂欄位名是否相同，我們都可以將這些 message 抽離為單獨的一個 .proto 文件，然後其它的 .proto 文件使用import "Protos/xxx.proto";引入它。

編譯一下，然後在 Program.cs 中註冊服務客戶端：

// .proto 文件中的 package
using TestDemo;

// 這裡註入的服務是 Transient 模式
builder.Services.AddGrpcClient<Greeter.GreeterClient>(o =>
{
    o.Address = new Uri("https://localhost:5001");
});

如此，其它地方就可以愉快地使用客戶端調用遠程服務了。

同服務端一樣，我們可以給客戶端配置統一的攔截器。如果服務端返回上文提到的 RpcException，客戶端得到後是直接拋出的（就像是本地異常），我們可以新建一個專門的異常攔截器處理 RpcException 異常。

builder.Services
    .AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    })
    .AddInterceptor<ExceptionInterceptor>();  // 預設創建一次，併在 GreeterClient 實例之間共用
    //.AddInterceptor<ExceptionInterceptor>(InterceptorScope.Client); // 每個 GreeterClient 實例擁有自己的攔截器

具體的異常處理邏輯就不舉例了。提一下，通過 RpcException.Trailers 可以獲取異常的 metadata 數據。

另外，對於異常處理來說，如果項目是普通的 ASP.NET Core Web 服務，那麼使用原先的 ActionFilterAttribute、IExceptionFilter等攔截器也是一樣的，因為既然運行時出現了異常，這兩者肯定也能捕獲到。

進階知識

本文未涉及的 .NET-gRPC 的進階知識諸如單元測試、服務調用中止、負載均衡、健康監控等，以後有機會再與大家分享。其實這方面微軟官方文檔已經講解得相當全面了，但也難以覆蓋在實操過程中遇到的所有問題，所以有此文以饗讀者，還望不吝指教。

參考資料

HTTP 2.0的前世今生
.NET性能優化-是時候換個序列化協議了
MessagePack簡析
Varint編碼
Protobuf 標量數據類型


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 【Python爬蟲實戰項目】Python爬蟲批量下載相親網站數據並保存本地（附源碼）
    前言 今天給大家介紹的是Python爬蟲批量下載相親網站圖片數據，在這裡給需要的小伙伴們代碼，並且給出一點小心得。 首先是爬取之前應該儘可能偽裝成瀏覽器而不被識別出來是爬蟲，基本的是加請求頭，但是這樣的純文本數據爬取的人會很多，所以我們需要考慮更換代理IP和隨機更換請求頭的方式來對相親網站圖片數據進 ...
  • MybatisPlus實戰技術分享合集 代碼生成器 多表連接查詢 分組查詢 一口氣幹完
    一、MybatisPlusMax簡介 MybatisPlusMax是MybatisPlus的增強包，秉承只拓展不修改的理念，對MybatisPlus做增強。 正如MybatisPlus是對MyBatis的增強，MybatisPlusMax是對MybatisPlus的增強，拓展理念一脈相承。 Myba ...
  • 13種Shell邏輯與算術，能寫出5種算你贏！
    相較於最初的 Bourne shell，現代 bash 版本的最大改進之一體現在算術方面。早期的 shell 版本沒有內建的算術功能，哪怕是給變數加1，也得調用單獨的程式來完成。 1、算術方法一： $(( )) 只要都是整數運算，就可以在 $(( )) 的算術表達式內使用所有的標準運算符。還有一個額 ...
  • RocketMQ消息短暫而又精彩的一生
    大家好，我是三友~~ 這篇文章我準備來聊一聊RocketMQ消息的一生。 不知你是否跟我一樣，在使用RocketMQ的時候也有很多的疑惑： 消息是如何發送的，隊列是如何選擇的？消息是如何存儲的，是如何保證讀寫的高性能？RocketMQ是如何實現消息的快速查找的？RocketMQ是如何實現高可用的？消 ...
  • JavaFx 頁面和控制項設置快捷鍵
    原文：JavaFx 頁面和控制項設置快捷鍵 - Stars-One的雜貨小窩 之前說過一篇window系統全局快捷鍵的設置，本期主要是講解JavaFx應用程式的快捷鍵設置，還是有所區別的 這裡主要是Tornadofx為例進行講解，以Kotlin語言為例，由於比較簡單，就不貼截圖了，下麵例子都是自己測試 ...
  • 學習筆記——Mybatis中獲取主鍵自增數據；獲取資料庫受影響行數;Mybatis中參數傳遞問題
    2023-01-10 一、Mybatis中獲取主鍵自增數據 要獲取自增數據時，需要在映射文件中的“<insert>”中添加兩個屬性，例如獲取自增的id ①EmployeeMapper.xml中的<mapper>標簽內部 <insert id="insertEmployee" useGenerated ...
  • 一次JVM GC長暫停的排查過程
    在高併發下，Java程式的GC問題屬於很典型的一類問題，帶來的影響往往會被進一步放大。不管是「GC頻率過快」還是「GC耗時太長」，由於GC期間都存在Stop The World問題，因此很容易導致服務超時，引發性能問題。 ...
  • 日誌瘦身騷操作：從 5G 優化到 1G，牛逼！!
    作者：明明如月學長 鏈接：https://juejin.cn/post/7117046503616544804 一、背景 在日常開發中，通常為了方便調試、方便查問題，會列印很多 INFO 級別的日誌。 隨著訪問量越來越大，一不小心，某個日誌文件一天的 size 就大於了某個閾值（如 5G），於是，收 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類