在.NET Core API 微服務中使用 gRPC：從通信模式到場景選型

一、gRPC 基礎：為什么它適合微服務？

二、gRPC 的四種通信模式及.NET Core 實現

1. 一元 RPC（Unary RPC）：最基礎的請求 - 響應模式

2. 服務器流式 RPC（Server Streaming RPC）：服務端批量推送數據

3. 客戶端流式 RPC（Client Streaming RPC）：客戶端批量提交數據

4. 雙向流式 RPC（Bidirectional Streaming RPC）：實時雙向交互

三、gRPC 在微服務中的核心使用場景

四、gRPC vs RESTful API：優劣勢對比

五、總結：如何在微服務中選擇？

在微服務架構中，服務間通信的效率、可靠性和靈活性直接影響系統整體性能。gRPC 作為一種高性能的遠程過程調用（RPC）框架，基于 HTTP/2 協議和 Protocol Buffers（Protobuf）序列化機制，已成為.NET Core 微服務間通信的熱門選擇。本文將詳細解析 gRPC 的四種通信模式、適用場景，并與 RESTful API 進行對比，幫助你在微服務架構中合理選型。

一、gRPC 基礎：為什么它適合微服務？

gRPC 是由 Google 開發的開源 RPC 框架，其核心優勢源于兩大技術基石：

HTTP/2 協議：支持多路復用、二進制幀傳輸、服務器推送等特性，解決了 HTTP/1.1 的連接阻塞問題。

Protocol Buffers：一種強類型二進制序列化格式，相比 JSON/XML，序列化后體積更小、解析速度更快，且自帶接口定義能力。

在.NET Core 中，gRPC 通過Grpc.AspNetCore包提供原生支持，可與ASP.NET Core 生態無縫集成，尤其適合微服務間的高頻、低延遲通信場景。

二、gRPC 的四種通信模式及.NET Core 實現

gRPC 基于 “服務定義” 和 “消息類型” 構建通信契約，通過.proto文件定義接口，再生成客戶端和服務端代碼。其四種通信模式覆蓋了幾乎所有微服務交互場景：

1. 一元 RPC（Unary RPC）：最基礎的請求 - 響應模式

定義：客戶端發送一個請求，服務端返回一個響應，類似傳統的 HTTP 接口調用。

流程：

客戶端調用生成的方法，發送請求消息。
服務端接收請求并處理。
服務端返回響應消息，一次交互結束。

代碼示例：

.proto文件定義：

syntax = "proto3";
service UserService {// 一元RPC：根據ID查詢用戶rpc GetUserById (UserIdRequest) returns (UserResponse);
}message UserIdRequest {int32 user_id = 1;
}message UserResponse {int32 id = 1;string name = 2;string email = 3;
}

服務端實現（.NET Core）：

public class UserService : UserService.UserServiceBase
{public override Task<UserResponse> GetUserById(UserIdRequest request, ServerCallContext context){// 模擬查詢數據庫var user = new UserResponse { Id = request.UserId, Name = "張三", Email = "zhangsan@example.com" };return Task.FromResult(user);}
}

客戶端調用：

var channel = GrpcChannel.ForAddress("https://localhost:5001");?
var client = new UserService.UserServiceClient(channel);?
var response = await client.GetUserByIdAsync(new UserIdRequest { UserId = 1 });?
Console.WriteLine($"用戶名稱：{response.Name}");

適用場景：簡單的查詢或命令操作，如 “根據 ID 查詢資源”“提交表單數據” 等單次交互場景。

2. 服務器流式 RPC（Server Streaming RPC）：服務端批量推送數據

定義：客戶端發送一個請求，服務端返回一個持續的數據流（多個響應），直到服務端主動結束流。

流程：

客戶端發送請求。
服務端接收后，通過流多次返回響應（如分頁數據、實時日志）。
服務端關閉流，客戶端接收完成。

代碼示例：

.proto文件定義：

service OrderService {// 服務器流式RPC：獲取訂單歷史（分頁推送）rpc GetOrderHistory (OrderHistoryRequest) returns (stream OrderResponse);
}message OrderHistoryRequest {int32 user_id = 1;
}message OrderResponse {int32 order_id = 1;string product = 2;double amount = 3;
}

服務端實現：

public class OrderService : OrderService.OrderServiceBase
{public override async Task GetOrderHistory(OrderHistoryRequest request, IServerStreamWriter<OrderResponse> responseStream, ServerCallContext context){// 模擬分批返回數據var orders = new List<OrderResponse>{new() { OrderId = 1, Product = "手機", Amount = 5999 },new() { OrderId = 2, Product = "電腦", Amount = 8999 },new() { OrderId = 3, Product = "耳機", Amount = 999 }};foreach (var order in orders){await responseStream.WriteAsync(order);await Task.Delay(500); // 模擬延遲}}
}

客戶端調用：

var client = new OrderService.OrderServiceClient(channel);
using var call = client.GetOrderHistory(new OrderHistoryRequest { UserId = 1 });
await foreach (var order in call.ResponseStream.ReadAllAsync())
{Console.WriteLine($"訂單ID：{order.OrderId}，商品：{order.Product}");
}

適用場景：需要服務端持續返回數據的場景，如 “分頁查詢大量數據”“實時日志推送”“股票價格更新” 等。

3. 客戶端流式 RPC（Client Streaming RPC）：客戶端批量提交數據

定義：客戶端通過流多次發送請求，服務端在接收完所有請求后返回一個響應。

流程：

客戶端通過流多次發送數據（如分批上傳文件）。
服務端接收所有數據后處理。
服務端返回一個最終響應。

代碼示例：

.proto文件定義：

service FileService {// 客戶端流式RPC：上傳文件（分片）rpc UploadFile (stream FileChunkRequest) returns (FileUploadResponse);
}message FileChunkRequest {bytes chunk_data = 1;string file_name = 2;bool is_last_chunk = 3;
}message FileUploadResponse {bool success = 1;string file_path = 2;
}

服務端實現：

public class FileService : FileService.FileServiceBase
{public override async Task<FileUploadResponse> UploadFile(IAsyncStreamReader<FileChunkRequest> requestStream, ServerCallContext context){var filePath = Path.Combine("uploads", Guid.NewGuid().ToString());using var fs = new FileStream(filePath, FileMode.Create);while (await requestStream.MoveNextAsync()){var chunk = requestStream.Current;await fs.WriteAsync(chunk.ChunkData.ToArray());if (chunk.IsLastChunk) break;}return new FileUploadResponse { Success = true, FilePath = filePath };}
}

客戶端調用：

var client = new FileService.FileServiceClient(channel);
using var call = client.UploadFile();// 模擬分片上傳
var chunks = new List<FileChunkRequest>
{new() { ChunkData = ByteString.CopyFromUtf8("第一部分數據"), FileName = "test.txt", IsLastChunk = false },new() { ChunkData = ByteString.CopyFromUtf8("第二部分數據"), FileName = "test.txt", IsLastChunk = true }
};foreach (var chunk in chunks)
{await call.RequestStream.WriteAsync(chunk);
}
await call.RequestStream.CompleteAsync();var response = await call.ResponseAsync;
Console.WriteLine($"上傳結果：{response.Success}，路徑：{response.FilePath}");

適用場景：客戶端需要批量提交數據的場景，如 “大文件分片上傳”“批量數據導入”“傳感器批量上報數據” 等。

4. 雙向流式 RPC（Bidirectional Streaming RPC）：實時雙向交互

定義：客戶端和服務端通過各自的流雙向發送數據，雙方可獨立發送 / 接收，無需等待對方響應，類似 “即時通訊”。

流程：

客戶端和服務端建立流連接。
客戶端可隨時發送數據，服務端也可隨時返回數據。
任意一方關閉流，交互結束。

代碼示例：

.proto文件定義：

service ChatService {// 雙向流式RPC：實時聊天rpc Chat (stream ChatMessageRequest) returns (stream ChatMessageResponse);
}message ChatMessageRequest {string user = 1;string message = 2;
}message ChatMessageResponse {string timestamp = 1;string user = 2;string message = 3;
}

服務端實現：

public class ChatService : ChatService.ChatServiceBase
{public override async Task Chat(IAsyncStreamReader<ChatMessageRequest> requestStream, IServerStreamWriter<ChatMessageResponse> responseStream, ServerCallContext context){// 并行處理：一邊讀客戶端消息，一邊寫響應var readTask = Task.Run(async () =>{while (await requestStream.MoveNextAsync()){var request = requestStream.Current;// 廣播消息（簡化處理，實際需維護連接池）await responseStream.WriteAsync(new ChatMessageResponse{Timestamp = DateTime.Now.ToString("HH:mm:ss"),User = request.User,Message = request.Message});}});await readTask;}
}

客戶端調用：

var client = new ChatService.ChatServiceClient(channel);
using var call = client.Chat();// 發送消息的任務
var sendTask = Task.Run(async () =>
{while (true){Console.Write("輸入消息（退出請輸入q）：");var msg = Console.ReadLine();if (msg == "q") break;await call.RequestStream.WriteAsync(new ChatMessageRequest{User = "客戶端A",Message = msg});}await call.RequestStream.CompleteAsync();
});// 接收消息的任務
var receiveTask = Task.Run(async () =>
{await foreach (var response in call.ResponseStream.ReadAllAsync()){Console.WriteLine($"[{response.Timestamp}] {response.User}：{response.Message}");}
});await Task.WhenAll(sendTask, receiveTask);

適用場景：需要實時雙向交互的場景，如 “即時通訊”“多人協作編輯”“實時游戲對戰” 等。

三、gRPC 在微服務中的核心使用場景

結合上述四種模式，gRPC 在微服務中的典型應用場景包括：

高頻內部服務調用：微服務間的同步通信（如訂單服務調用支付服務），利用 gRPC 的高性能降低延遲。
實時數據推送：如物流系統的位置實時更新（服務器流式）、監控系統的指標實時上報（客戶端流式）。
大數據傳輸：通過流式傳輸避免單次請求數據量過大導致的超時（如數據備份、日志同步）。
雙向實時交互：如客服系統的實時對話、協作工具的實時狀態同步。

四、gRPC vs RESTful API：優劣勢對比

維度	gRPC	RESTful API
性能	極高：HTTP/2 多路復用 + 二進制協議，吞吐量是 REST 的 5-10 倍。	中等：HTTP/1.1 文本協議（JSON/XML），解析耗時。
契約定義	強類型：通過.proto文件嚴格定義接口，支持自動生成代碼，編譯期校驗。	弱類型：依賴文檔（如 Swagger），需手動保證客戶端與服務端一致。
通信模式	支持四種模式（一元、服務端流、客戶端流、雙向流），靈活應對復雜場景。	僅支持請求 - 響應模式（擴展需 WebSocket 等）。
兼容性	較差：二進制協議不適合瀏覽器直接調用，需通過網關轉換。	極好：基于 HTTP/1.1 文本協議，瀏覽器、Postman 等工具直接支持。
學習成本	較高：需學習 Protobuf 語法、gRPC 概念及工具鏈。	較低：基于 HTTP 標準，開發者熟悉度高。
生態工具	正在完善：.NET Core 集成良好，但調試工具（如瀏覽器 DevTools）支持有限。	成熟：Swagger、Postman 等工具生態豐富。
適用場景	微服務內部通信、實時交互、高性能需求場景。	面向用戶的 API（BFF 層）、簡單的跨系統交互。