gRPC入門與實操(.NET篇)

萊布尼茨發表於2023-01-10
RPC

為什麼選擇 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 標量資料型別

相關文章