ASP.NET Core中的gRPC是什么？如何创建服务？

畫卷琴夢

发布时间：2025-09-05 09:55:02

154人浏览过

来源于php中文网

原创

答案：ASP.NET Core中gRPC服务通过定义.proto文件、实现服务类并注册到应用管道来创建，其相比RESTful API在性能、类型安全和流式传输方面优势明显，适用于微服务、多语言环境和实时场景，开发中需注意调试复杂性、.proto配置、流式处理及拦截器使用，身份验证可通过元数据结合ASP.NET Core认证机制实现。

asp.net core中的grpc是什么？如何创建服务？

ASP.NET Core中的gRPC是一个高性能、跨语言的远程过程调用（RPC）框架。它基于HTTP/2协议，并使用Protocol Buffers作为接口定义语言，使得服务间通信更加高效和类型安全。要在ASP.NET Core中创建gRPC服务，主要步骤包括定义

.proto

文件来描述服务接口和数据结构，然后实现这些接口，并在ASP.NET Core应用程序中将其注册。

解决方案

在ASP.NET Core中创建gRPC服务，通常遵循以下步骤：

创建gRPC项目： 你可以使用.NET CLI创建一个新的gRPC服务项目。这会生成一个包含基本结构和示例
```
helloworld.proto
```
文件的项目。
```
dotnet new grpc -n MyGrpcService
cd MyGrpcService
```

定义Protocol Buffers文件（.proto）： 在项目的

Protos

文件夹下，创建一个或修改现有的

.proto

文件来定义你的服务接口和消息类型。例如，我们可以在

greet.proto

中添加一个获取服务器时间的服务。

syntax = "proto3"; // 指定Proto3语法
option csharp_namespace = "MyGrpcService"; // 定义C#命名空间，方便生成代码

package greet; // 定义包名

// 定义一个名为Greeter的服务
service Greeter {
  // 定义一个RPC方法SayHello，接收HelloRequest，返回HelloReply
  rpc SayHello (HelloRequest) returns (HelloReply);
  // 定义一个新方法GetServerTime，接收空消息，返回时间消息
  rpc GetServerTime (Empty) returns (TimeReply);
}

// 定义请求消息
message HelloRequest {
  string name = 1; // 字段名和字段编号
}

// 定义响应消息
message HelloReply {
  string message = 1;
}

// 定义一个空消息，用于不需要参数的请求
message Empty {}

// 定义时间响应消息
message TimeReply {
  string time = 1;
}

确保你的

.csproj

文件中正确引用了

Grpc.AspNetCore

包，并且

Protobuf

项指向了你的

.proto

文件，通常是这样：

GrpcServices="Server"

告诉MSBuild为服务器端生成代码。

实现gRPC服务： 创建一个C#类，继承自Protocol Buffers编译器为你生成的抽象基类（例如

Greeter.GreeterBase

），并实现其中定义的方法。在

Services

文件夹下创建

GreeterService.cs

文件：

using Grpc.Core;
using Microsoft.Extensions.Logging;
using System;
using System.Threading.Tasks;

namespace MyGrpcService.Services
{
    public class GreeterService : Greeter.GreeterBase // 继承自生成的基类
    {
        private readonly ILogger _logger;

        public GreeterService(ILogger logger)
        {
            _logger = logger;
        }

        // 实现SayHello方法
        public override Task SayHello(HelloRequest request, ServerCallContext context)
        {
            _logger.LogInformation($"Received SayHello request for: {request.Name}");
            return Task.FromResult(new HelloReply
            {
                Message = "Hello " + request.Name + " from ASP.NET Core gRPC!"
            });
        }

        // 实现GetServerTime方法
        public override Task GetServerTime(Empty request, ServerCallContext context)
        {
            _logger.LogInformation("Received GetServerTime request.");
            return Task.FromResult(new TimeReply
            {
                Time = DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss.fff UTC")
            });
        }
    }
}

注册gRPC服务： 在ASP.NET Core应用程序的

Program.cs

（或旧版项目的

Startup.cs

）中，配置gRPC服务并将其映射到请求管道。

using MyGrpcService.Services; // 引入你的服务命名空间

var builder = WebApplication.CreateBuilder(args);

// 添加gRPC服务到依赖注入容器
builder.Services.AddGrpc();

var app = builder.Build();

// 配置HTTP请求管道...

// 将你的gRPC服务映射到请求处理管道
app.MapGrpcService();

// 为根路径提供一个提示，因为gRPC客户端不能直接通过浏览器访问
app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");

app.Run();

完成这些步骤后，你的ASP.NET Core gRPC服务就创建并运行起来了。你可以使用gRPC客户端（如

Grpc.Net.Client

或各种语言的gRPC客户端库）来调用这些服务。

gRPC与RESTful API相比，有哪些核心优势和适用场景？

当谈到服务间通信时，gRPC和RESTful API常常被拿来比较，它们各有千秋，但gRPC在某些特定场景下确实展现出更强的竞争力。从我的经验来看，gRPC最显著的优势在于性能、强类型和流式传输能力。

首先是性能。gRPC基于HTTP/2协议，这意味着它能利用多路复用、头部压缩等特性，减少网络开销。更重要的是，它使用Protocol Buffers（ProtoBuf）作为数据序列化格式。ProtoBuf是一种二进制格式，相比RESTful API常用的JSON或XML，它的数据包更小，序列化和反序列化的速度也更快。这对于微服务架构中大量、频繁的服务间调用尤其关键，能显著降低延迟和提高吞吐量。我记得有一次我们团队在处理一个高并发的内部数据同步服务时，从JSON切换到ProtoBuf后，服务响应时间直接削减了一半，那感觉就像给系统打了一剂强心针。

其次是强类型。ProtoBuf通过

.proto

文件明确定义了服务接口和消息结构。这些定义在编译时会生成特定语言的代码，这意味着你在开发阶段就能获得类型检查和自动补全，大大减少了运行时因数据格式不匹配而导致的错误。这和RESTful API那种松散的、通常只依赖文档的契约形成了鲜明对比。在大型团队协作或多语言环境下，这种强类型契约能有效避免“接口扯皮”的尴尬局面，提升开发效率和代码质量。

再者是流式传输能力。gRPC支持四种调用模式：一元（Unary）、服务器流（Server Streaming）、客户端流（Client Streaming）和双向流（Bidirectional Streaming）。RESTful API虽然也能通过长轮询或WebSocket实现一些流式功能，但gRPC将其作为原生特性集成，并且更为高效和灵活。这使得它非常适合需要实时数据推送（如股票行情、聊天应用）、大数据传输或IoT设备通信等场景。比如，如果你需要从服务器持续获取日志更新，一个服务器流的gRPC调用远比反复请求REST API要优雅和高效得多。

良精Wap企业网站管理系统 1.2

什么是企业WAP网站，企业3G网站企业WAP网站一般是指展示企业形象，介绍企业产品的WAP手机网站或者3G手机网站，让客户可以通过手机就能了解一个企业的大体情况和产品内容，从而更广泛的宣传企业，赢得更多的客户关注度！一般企业WAP网站包括：公司介绍，产品介绍，企业新闻动态，服务范围介绍，留言板，企业招聘信息等内容，如果有特殊要求，我们也会按照客户的要求定做。企业为何要建设手机WAP网站，3

下载

那么，gRPC的适用场景就呼之欲出了：

微服务架构中的内部通信： 当服务之间需要高频、低延迟、高吞吐量的通信时，gRPC是理想选择。
多语言异构环境： ProtoBuf的跨语言特性使得不同技术栈的服务可以无缝集成。
实时应用： 需要实时数据流或双向通信的场景，如实时监控、游戏后端、聊天服务。
资源受限设备： ProtoBuf的紧凑性使其在带宽和计算资源有限的IoT设备上表现优异。

当然，RESTful API依然有其不可替代的地位，特别是对于对外公开的API、Web浏览器直接访问的场景，以及简单的CRUD操作，它的易用性、可读性和与Web生态的紧密结合是gRPC短期内无法完全取代的。但对于那些对性能、类型安全和流式传输有严格要求的内部系统，gRPC无疑是更强大的“精兵”。

ASP.NET Core gRPC服务开发中，有哪些常见的挑战和陷阱？

在ASP.NET Core中开发gRPC服务，虽然带来了诸多优势，但新手上路也确实会遇到一些小麻烦，甚至一些老手也可能不小心踩坑。我个人就经历过不少这样的“抓狂时刻”，总结起来，主要有以下几个常见的挑战和陷阱：

1. 调试复杂性： 这是很多从RESTful API转向gRPC的开发者最先感受到的不适。RESTful API可以直接在浏览器中访问、通过Postman等工具轻松调试，响应也是直观的JSON。但gRPC不一样，它基于HTTP/2和二进制的Protocol Buffers，你不能直接在浏览器里输入URL看到响应。这导致初学者往往不知道如何验证服务是否正常工作。

陷阱： 试图用浏览器访问gRPC端口，结果只看到一个简单的提示信息，以为服务没启动或配置有问题。
解决方案： 你需要专门的gRPC客户端工具，比如
```
gRPCurl
```
（命令行工具）、BloomRPC或Postman的新版本（支持gRPC）。或者，自己编写一个简单的gRPC客户端来测试。我个人偏爱
```
gRPCurl
```
，在命令行里就能快速验证接口，非常方便。

2. Protocol Buffers的学习曲线和配置：

.proto

文件的语法虽然不复杂，但对于初次接触的开发者来说，还是需要一些时间来熟悉。字段编号、消息嵌套、枚举、

oneof

等概念，都需要理解。更麻烦的是，如果

.csproj

文件中的

Protobuf

项配置不正确，比如

GrpcServices

属性设置错误（应该是

Server

而不是

Client

或

Both

），或者路径不对，那么C#代码就不会被正确生成，编译时你可能会看到一堆“找不到类型”的错误，却不知道根源在哪里。

陷阱：
```
.csproj
```
配置错误导致代码生成失败，或者忘记在
```
Program.cs
```
中调用
```
builder.Services.AddGrpc()
```
和
```
app.MapGrpcService()
```
。
解决方案： 仔细检查
```
.csproj
```
文件，确保
```
Protobuf
```
项的配置正确无误。对于初学者，从
```
dotnet new grpc
```
模板开始是一个好习惯，它会帮你设置好大部分基础配置。

3. 流式传输的状态管理和错误处理： gRPC的流式传输功能强大，但也带来了新的复杂性。特别是双向流，客户端和服务器可以独立发送消息，这要求开发者对流的生命周期、状态管理和并发处理有更深入的理解。如果处理不当，很容易出现竞态条件、资源泄露或死锁。同时，gRPC的错误处理也与HTTP状态码有所不同，它通过

RpcException

和

Status

对象来传递错误信息。

陷阱： 在流式服务中没有正确处理流的关闭、取消或异常，导致连接一直占用资源。或者错误地使用
```
throw new Exception()
```
而不是
```
throw new RpcException(new Status(...))
```
，导致客户端无法解析错误信息。
解决方案： 对于流式服务，要特别注意
```
ServerCallContext
```
的
```
CancellationToken
```
，及时响应取消请求。错误处理时，始终使用
```
RpcException
```
，并确保
```
Status.StatusCode
```
和
```
Status.Detail
```
提供足够的信息供客户端判断。

4. 拦截器（Interceptor）的理解和使用： ASP.NET Core gRPC提供了拦截器机制，可以在请求到达服务方法之前或之后执行逻辑，这对于实现认证、授权、日志记录、错误处理等横切关注点非常有用。但如何正确编写和注册拦截器，以及如何在拦截器中访问和修改

ServerCallContext

中的元数据，是需要花时间掌握的。

陷阱： 拦截器链的顺序问题，或者在拦截器中没有正确调用
```
continuation
```
委托，导致请求无法继续处理。
解决方案： 从简单的日志拦截器开始，逐步理解其工作原理。注意拦截器是按照注册顺序执行的，因此认证拦截器通常放在前面。

这些挑战虽然存在，但一旦你掌握了gRPC的核心概念和工具链，你会发现它在构建高性能、可靠的分布式系统方面是多么强大和高效。

如何在ASP.NET Core中为gRPC服务添加身份验证和授权？

在ASP.NET Core中为gRPC服务添加身份验证（Authentication）和授权（Authorization），其核心思路是利用ASP.NET Core自身强大的安全机制，并结合gRPC的拦截器（Interceptor）来桥接两者。gRPC本身没有内置的身份验证协议，但它允许你在请求的元数据（Metadata）中传递认证凭据，这为我们集成现有认证方案提供了便利。

核心思想：