在微服务架构中，服务之间的通信方式直接决定了系统的整体性能上限。ASP.NET Core 提供的 Web API 是最常见的 HTTP REST 方案，而 gRPC 作为基于 HTTP/2 和 Protobuf 的高性能 RPC 框架，近年在 .NET 生态中的地位越来越高。这两者在高并发场景下的差距到底有多大，差距又来自哪里，是很多团队在做技术选型时绕不开的问题。本文将从协议层、序列化层和连接层三个角度展开分析，并给出可复现的压测方法和代码。
一、性能差异的三大来源：协议、序列化与连接模型
gRPC 和 Web API 最核心的区别不在于代码写法，而在于底层数据传输方式的完全不同。理解了这三层差异，就能解释压测中出现的所有现象。
第一层是传输协议。传统 Web API 默认运行在 HTTP/1.1 上，客户端如果要发起大量并发请求，通常需要建立多条 TCP 连接，因为 HTTP/1.1 存在队头阻塞问题，同一个连接上同一时刻只能处理一个未完成的请求。浏览器一般允许同域名最多 6 个并发连接，服务端虽然可以配置更多，但每条连接都有内存和文件描述符的开销。gRPC 强制使用 HTTP/2，HTTP/2 在单条连接上通过二进制分帧实现了多路复用，成百上千个并发请求可以同时在一条 TCP 连接上交错传输，互不阻塞。
第二层是序列化方式。Web API 最常用 JSON 文本格式，序列化和反序列化需要做字符串解析，数据体积也大。Protobuf 是二进制格式，字段用编号标识而不是字段名，整型用变长编码（Varint）压缩，传输同样一份数据，Protobuf 的体积通常只有 JSON 的三分之一到五分之一，解析速度更是快出数倍。在每秒几万次调用的场景下，CPU 花在序列化上的时间会成为明显瓶颈。
第三层是客户端连接模型。gRPC 客户端使用 Channel 管理长连接，内置连接池和负载均衡策略，调用时省去了反复建连的开销。而 HttpClient 虽然也支持连接池复用，但在高频短请求下，DNS 解析、TLS 握手失败重试等问题更容易暴露。三者叠加，构成了两者性能差距的全部来源。
二、基准测试：压测环境搭建与数据对比
理论分析需要数据验证。下面用 .NET 搭建一个最简的对比环境：同一个服务里同时提供 REST 接口和 gRPC 接口，返回相同的 100 条订单数据，然后用 BenchmarkDotNet 或者 bombardier、ghz 这类压测工具打流量。
先定义 Proto 文件，这是 gRPC 的服务契约：
syntax = "proto3";
option csharp_namespace = "GrpcDemo";
package order;
service OrderService {
rpc GetOrders (OrderRequest) returns (OrderList);
}
message OrderRequest {
int32 count = 1;
}
message Order {
int64 id = 1;
string productName = 2;
double amount = 3;
}
message OrderList {
repeated Order items = 1;
}然后在 ASP.NET Core 项目中实现服务端逻辑，并在 Program.cs 中同时注册 gRPC 和 Web API：
using GrpcDemo;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
var app = builder.Build();
// gRPC 服务
app.MapGrpcService<OrderServiceImpl>();
// Web API 对照接口，返回同样的数据
app.MapGet("/api/orders/{count}", (int count) =>
{
var orders = Enumerable.Range(1, count).Select(i => new
{
Id = i,
ProductName = $"商品{i}",
Amount = i * 9.9
});
return Results.Json(orders);
});
app.Run();
public class OrderServiceImpl : OrderService.OrderServiceBase
{
public override Task<OrderList> GetOrders(OrderRequest request, ServerCallContext context)
{
var list = new OrderList();
for (int i = 1; i <= request.Count; i++)
{
list.Items.Add(new Order { Id = i, ProductName = $"商品{i}", Amount = i * 9.9 });
}
return Task.FromResult(list);
}
}在 8 核 16G 的测试机上，用 ghz 压 gRPC、用 bombardier 压 REST 接口，并发 500 连接持续 60 秒，典型的结果大致是：gRPC 的吞吐量在每秒 6 万到 9 万次请求，平均延迟 5 到 10 毫秒；Web API 吞吐量在每秒 2 万到 4 万次，平均延迟 15 到 30 毫秒。具体数值和机器配置、负载模型关系很大，但结论相对稳定：在中等负载实体、高并发调用下，gRPC 的吞吐量通常是 JSON Web API 的 2 到 4 倍，平均延迟低一半以上，GC 压力和内存分配也明显更小，因为 Protobuf 编码过程中产生的临时字符串远少于 JSON 序列化。
不过有一个容易被忽略的细节：如果 Web API 启用了 HTTP/2 且使用 System.Text.Json 的源生成模式（JsonSerializerContext），差距会缩小一些；反之如果 gRPC 传输的是大消息（比如超过 4MB 需要调整 MaxReceiveMessageSize），缓冲整个消息反而会带来额外内存压力。所以压测时务必让负载模型贴近真实业务，不要只测空接口。
三、选型建议：什么时候用 gRPC，什么时候留在 Web API
性能数据好看不等于应该无脑切换。gRPC 的强项是内部服务间通信：微服务内部调用、实时性要求高的推送场景（gRPC 双向流）、跨语言协作的多语言体系，这些场景下 Protobuf 的强类型契约还能带来编译期校验，避免手写模型导致两端不一致。
但 Web API 依然有不可替代的优势。对外暴露的开放接口、面向浏览器的前端调用、需要被第三方轻松集成的场景，REST 加 JSON 的通用性和可调试性是 gRPC 比不了的。浏览器原生不支持 HTTP/2 的 gRPC 协议，虽然可以用 gRPC-Web 网关过渡，但会引入额外组件和性能损耗。此外团队的学习成本、现有监控体系对 REST 的适配程度，也都是实际落地时必须考虑的因素。
一个务实的做法是混合使用：对外网关用 Web API，内部服务间通信用 gRPC，两者共享业务逻辑层。在 .NET 中同一个进程同时托管两种服务毫无压力，上面代码已经演示了这一点。另外要注意 gRPC 的几个生产配置：服务端建议显式配置 GrpcAspNetCoreServer 的消息大小上限和保持连接参数，客户端的 Channel 应该做成单例复用，每个请求创建 Channel 会拖垮性能；Docker 或 Nginx 后面部署时，务必确认代理层支持 HTTP/2 透传，否则 gRPC 会直接报错或退化为异常行为。
总结一下，高并发场景下 gRPC 凭借 HTTP/2 多路复用、Protobuf 二进制序列化和长连接 Channel，对传统 JSON Web API 有 2 到 4 倍的吞吐优势，是内部服务通信的优选方案。但 REST 在开放性、可读性和生态兼容上依然占据主导。技术选型的正确姿势是看通信的边界在哪里：边界内部追性能用 gRPC，边界外部追通用性用 Web API，两者并不冲突。
gRPC性能对比Web API高并发C#微服务通信修改时间：2026-09-08 04:08:31