gRPC与微服务通信：从选型原理到生产落地实践

之前在某公司做电商中台，服务拆到三四十个之后，发现最难受的不是业务逻辑本身，而是服务之间那套 HTTP/1.1 + JSON 的调用方式：序列化慢、链路长、排查难，高峰期一个跨服务调用动辄几十毫秒，压测时 CPU 先顶不住。后来我们逐步把核心链路迁移到 gRPC 上，算是把服务之间通信这件“地基活”彻底重做了一遍。这篇文章想跟你完整聊聊 gRPC 与微服务怎么配合，从选型思路、核心原理到生产落地的完整实操，以及我在实际项目中踩过的坑。不管你是刚开始接触微服务，还是已经在用 REST 调库想换更高效的方案，应该都能从里面找到对应的参考。

1. 为什么选 gRPC：微服务通信的演进与选型

1.1 服务拆分之后，通信成了头号瓶颈

微服务的本质是把一个大系统拆成多个可独立部署的进程，进程之间必然要通信。拆得越细，通信占比越高。一个用户下单操作，从前端进来可能要经过 5 到 8 个服务，每次调用哪怕只多 5 毫秒，整个链路感知延迟就往 40 毫秒往上走了。更关键的是 CPU 开销：JSON 序列化和反序列化在大流量下非常吃 CPU，尤其是涉及大量嵌套结构时。

我见过一个真实案例：某团队把单体拆成 20 个服务后，系统整体 TPS 反而比单体时低了一半。排查到最后，发现 60% 的 CPU 都花在了 Jackson 序列化和 HTTP 连接管理上。这时候你才会意识到，微服务架构下，通信协议不是“选哪个顺手”的问题，而是直接决定系统上限的问题。

1.2 gRPC 的核心优势：不再是“换了个序列化方式”这么简单

先说结论：gRPC 不是一个简单的 RPC 框架，它是围绕 HTTP/2 和 Protocol Buffers 设计的一整套通信体系。和 REST 相比，它的优势不止是数据包变小，更关键的是连接层面的复用和流式能力：

• 高性能二进制序列化：Protobuf 编码后的数据体积大约是 JSON 的 1/3 到 1/5，序列化速度也有几倍的提升，而且这个过程几乎不产生额外 GC 压力。
• HTTP/2 多路复用：一条 TCP 连接上可以并发跑几十个请求，不再受 HTTP/1.1 队头阻塞的限制。对于微服务这种高并发短请求场景，效果非常明显。
• 强类型接口契约：proto 文件定义了接口和消息结构，服务端和客户端共用同一份契约，不会出现“字段名写错导致线上 bug”这种低级问题。
• 内置流式通信：支持服务端流、客户端流、双向流，这在实时推送、大数据传输、AI 推理流式返回等场景下是 REST 很难做到的。

我自己的感觉是，gRPC 真正解决的不只是“快”，而是把服务间通信从“自由发挥的文本协议”拉回到了“严格契约下的工程化协作”。这在团队规模大、服务数量多的情况下，价值比性能本身更大。

1.3 选型对比：gRPC、REST、Thrift、Dubbo

从这个表可以看出来，gRPC 在跨语言、流式、高性能这几个维度上优势明显，尤其适合中大型微服务架构。如果团队是纯 Java 技术栈、又依赖大量开源中间件，Dubbo 的生态确实更顺手；如果对外还要暴露 REST，通常也会搭配 grpc-gateway 来转一层。

2. gRPC 核心概念：Protocol Buffers、HTTP/2 与调用模型

2.1 Protocol Buffers：一份 IDL 就是一份契约

先用生活化类比解释一下：REST 接口的“契约”靠文档，字段是不是对的、类型是不是对的，都得人肉审。gRPC 的“契约”是 proto 文件，它是机器可读的，直接生成代码，字段名写错了连编译都过不了。

一个典型的 proto 长这样（文件名叫 order.proto）：

protobuf复制syntax = "proto3";

package order;

option go_package = "example.com/order/gen/orderpb";

service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);
  rpc GetOrderList(GetOrderListRequest) returns (stream OrderInfo);
}

message CreateOrderRequest {
  string user_id = 1;
  repeated OrderItem items = 2;
  double total_amount = 3;
}

message OrderItem {
  string sku_id = 1;
  int32 quantity = 2;
  double price = 3;
}

message OrderInfo {
  string order_id = 1;
  string status = 2;
  int64 created_at = 3;
}

message GetOrderListRequest {
  string user_id = 1;
  int32 page_size = 2;
  string page_token = 3;
}

message CreateOrderResponse {
  string order_id = 1;
}

这里有几个关键点：

• 字段后面的数字是字段编号，用来标识字段位置，不是默认值，一旦上线发布，编号就不能随意改，否则会影响兼容性。
• 字段类型里，int64 对应语言里的 64 位整数，repeated 表示数组，这些是跨语言通用的类型映射。
• 定义服务时用 rpc 关键字，后面可以接 stream 关键字标识是否流式接口。
• option go_package 是给 Go 生成代码用的路径；如果是 Java 或 Python，会自动生成对应语言的包名。

proto 文件建议单独放在一个仓库或者目录里，服务端和客户端都通过版本依赖引用它。我见过直接把 proto 复制到各项目里的做法，结果就是接口变更后，客户端和服务端的 proto 不一致，线上直接出现字段错位。这属于最基础但最容易犯的错误。

2.2 HTTP/2 多路复用：一条连接搞定所有请求

HTTP/1.1 时代，一个 TCP 连接同一时刻只能处理一个请求。为了提升性能，客户端只能开大量连接，连接多了又带来端口占用和内存开销。HTTP/2 把这一切改了：一条连接上有多个“流”（Stream），每个流里跑一个请求；流的调度由协议层完成，请求与请求之间不会互相阻塞。

gRPC 直接基于 HTTP/2，所以天然继承了这些特性：

• 多路复用：同一个连接上可以同时发几十个请求，等待响应的同时其它请求照样走。
• 头部压缩：HTTP/2 用 HPACK 压缩头部，gRPC 的请求头非常小，很多场景下头部的开销甚至比 protobuf 消息体还小。
• 二进制分帧层：协议本身既传文本也能传二进制，gRPC 直接把 protobuf 二进制消息打包进去。

这也是为什么微服务场景下，gRPC 在“短请求、高并发”场景下表现特别好——一条连接就扛住了原本几十条连接才能扛住的流量。

2.3 四种调用模式，按场景选型

gRPC 的调用模式不只是“你发一个、我回一个”，而是有四种：

以 Go 语言为例，服务端流接口的处理函数是这样的：

go复制func (s *OrderServiceImpl) GetOrderList(req *orderpb.GetOrderListRequest, stream orderpb.OrderService_GetOrderListServer) error {
    orders := s.loadOrders(req.UserId, req.PageSize)
    for _, o := range orders {
        if err := stream.Send(&orderpb.OrderInfo{
            OrderId:   o.OrderId,
            Status:    o.Status,
            CreatedAt: o.CreatedAt,
        }); err != nil {
            return err
        }
    }
    return nil
}

流式接口在处理大批量数据时，不必等全量数据组装完再返回，框架会把消息分批发送给客户端，客户端也能边收边处理。对内存的节省和首包延迟的改善，都是实打实的。

2.4 拦截器与 Metadata：做基础能力的挂载点

RPC 框架和普通 HTTP 框架一样，也有一套“中间件”机制，在 gRPC 里叫拦截器（Interceptor）。拦截器的用途非常广：鉴权、日志、链路追踪、熔断、限流，都可以在这里实现。

以 Go 为例，一元调用的服务端拦截器实现如下：

go复制func UnaryInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
    start := time.Now()
    // 从 metadata 提取调用来源，做鉴权或灰度
    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return nil, status.Error(codes.Unauthenticated, "missing metadata")
    }
    resp, err := handler(ctx, req)
    log.Printf("%s took %dms, err=%v", info.FullMethod, time.Since(start).Milliseconds(), err)
    return resp, err
}

Metadata 可以理解成 RPC 调用里的“请求头”，用来传 trace id、token、灰度标签这类非业务数据。拦截器读取 metadata 做统一的处理，业务代码不需要关心这些琐碎的事。

注意：gRPC 的 metadata 中 key 是小写不敏感的，推荐统一用小写命名，避免跨语言运行时出现解析问题。

3. 完整实操：用一个实例跑通 gRPC 微服务

3.1 环境准备

以 Go 语言为例，需要准备以下内容：

bash复制# 安装 protoc（不同系统安装方式不同，这里以 mac 为例）
brew install protobuf

# 安装 Go 插件
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

检查是否安装成功：

bash复制protoc --version
which protoc-gen-go && which protoc-gen-go-grpc

提示：protoc-gen-go 和 protoc-gen-go-grpc 是两个不同的插件，前者生成消息代码，后者生成 gRPC 服务代码，两个缺一不可。

这里要特别说明：生成代码的版本必须与框架版本兼容。如果 grpc-go 的版本是 1.6x，插件也是配套版本，混用高版本插件和低版本框架通常会遇到“包路径对不上”或“API 缺失”的编译错误。

3.2 用 protoc 生成代码

在你刚才创建的 order.proto 所在目录执行：

bash复制protoc --go_out=. --go_opt=paths=source_relative \
       --go-grpc_out=. --go-grpc_opt=paths=source_relative \
       order.proto

执行后会生成两个文件：

• order.pb.go：消息体（结构体）和序列化相关代码
• order_grpc.pb.go：客户端和服务端的接口定义

建议用 paths=source_relative 的方式生成，这样生成文件会直接出现在 proto 文件旁边，不会生成一层奇怪的目录嵌套。如果你有大量的 proto 文件需要管理，也可以直接用 Buf 这个工具来跑 lint、format 和生成。

3.3 服务端完整实现

假设我们要实现一个下单服务，服务端核心逻辑如下：

go复制package main

import (
    "context"
    "fmt"
    "log"
    "net"

    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"

    "example.com/order/gen/orderpb"
)

type OrderServiceImpl struct {
    orderpb.UnimplementedOrderServiceServer
}

// CreateOrder 实现创建订单接口
func (s *OrderServiceImpl) CreateOrder(ctx context.Context, req *orderpb.CreateOrderRequest) (*orderpb.CreateOrderResponse, error) {
    if req.UserId == "" {
        return nil, fmt.Errorf("user id is empty")
    }
    orderID := "ORD-" + req.UserId + "-0001"
    log.Printf("create order for user %s, amount=%.2f", req.UserId, req.TotalAmount)
    return &orderpb.CreateOrderResponse{OrderId: orderID}, nil
}

// 必须实现 GetOrderList，否则接口编译会失败（如果该接口被声明为必须方法）
func (s *OrderServiceImpl) GetOrderList(req *orderpb.GetOrderListRequest, stream orderpb.OrderService_GetOrderListServer) error {
    for _, o := range []*orderpb.OrderInfo{
        {OrderId: "ORD-001", Status: "CREATED"},
        {OrderId: "ORD-002", Status: "PAID"},
    } {
        if err := stream.Send(o); err != nil {
            return err
        }
    }
    return nil
}

func main() {
    lis, err := net.Listen("tcp", ":9090")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    s := grpc.NewServer(
        // 实际生产建议配置拦截器，见下文
    )
    orderpb.RegisterOrderServiceServer(s, &OrderServiceImpl{})
    // 反射服务，方便 grpcurl 调试
    reflection.Register(s)

    log.Println("gRPC server listening on :9090")
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

有几个细节必须注意：

• 生成的代码里包含一个 UnimplementedOrderServiceServer 结构体，你的实现必须内嵌它，这样才能保证将来增加新的 rpc 方法时，旧的服务端不会编译失败。
• 服务端必须注册到 grpc.NewServer() 的实例上，每个服务可以有多个 service 注册。
• 我在本地开发环境会开启 reflection.Register(s)，这样可以用 grpcurl 直接调试接口，不需要写客户端代码。

3.4 客户端实现

go复制package main

import (
    "context"
    "log"
    "time"

    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"

    "example.com/order/gen/orderpb"
)

func main() {
    // 本地开发先关闭 TLS
    conn, err := grpc.NewClient("127.0.0.1:9090",
        grpc.WithTransportCredentials(insecure.NewCredentials()),
    )
    if err != nil {
        log.Fatalf("failed to dial: %v", err)
    }
    defer conn.Close()

    client := orderpb.NewOrderServiceClient(conn)

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    resp, err := client.CreateOrder(ctx, &orderpb.CreateOrderRequest{
        UserId:      "user_1001",
        TotalAmount: 299.00,
        Items: []*orderpb.OrderItem{
            {SkuId: "sku_888", Quantity: 1, Price: 299.00},
        },
    })
    if err != nil {
        log.Fatalf("create order failed: %v", err)
    }
    log.Printf("order created: %s", resp.OrderId)
}

这里有个版本差异要提醒：较新版本的 gRPC 建议用 grpc.NewClient 而不是 grpc.Dial。如果用的是 grpc.Dial，会看到一个 deprecated 警告。grpc.Dial 在旧版里是同步连接，在新版里默认是 lazy connect 的，容易让人误以为连接已经建立。

注意：gRPC 客户端连接是长连接，不是每次调用新建连接。一个 conn 可以被多个 goroutine 安全共享，不要为每个请求都创建新连接。连接管理是有代价的，频繁开关连接对性能和资源都是浪费。

3.5 用 grpcurl 快速调试

没有现成客户端的时候，用 grpcurl 可以直接调接口，前提是服务端开启了 reflection。

bash复制# 查看服务列表
grpcurl -plaintext 127.0.0.1:9090 list

# 查看具体服务的方法
grpcurl -plaintext 127.0.0.1:9090 list order.OrderService

# 调用一元接口
grpcurl -plaintext -d '{"user_id": "user_1001", "total_amount": 299}' \
  127.0.0.1:9090 order.OrderService/CreateOrder

这个工具在本地联调和排错时非常好用，尤其在服务端收到报错但客户端日志打得不全的时候。

3.6 打通 REST 与 gRPC：grpc-gateway 的用法

现实中，很多微服务的调用方是前端浏览器或者外部系统，它们无法直接发 HTTP/2 二进制请求。这时候就需要一层网关，把 REST 请求转成 gRPC 请求。grpc-gateway 是官方推荐的方案。

在 proto 中加几个配置：

protobuf复制import "google/api/annotations.proto";

service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse) {
    option (google.api.http) = {
      post: "/v1/orders"
      body: "*"
    };
  }
}

生成时再带上 gateway 插件：

bash复制protoc --grpc-gateway_out=. --grpc-gateway_opt=paths=source_relative \
       order.proto

这样客户端既可以通过 POST /v1/orders 的 JSON 方式访问，也可以通过 gRPC 方式访问，后端逻辑完全不用改。对于需要对外暴露 API 的场景，这是一个非常实用的组合方案。

4. 微服务落地实践：服务发现、负载均衡与可观测性

4.1 服务注册与发现：动态感知实例变化

在容器化和 K8s 环境里，服务实例是随时变动的。如果客户端写死 IP 和端口，一旦实例重建就失联。gRPC 原生支持 grpc.NewClient 传入 resolver 地址，比如 dns:///myservice:9090 或 etcd:///myservice。

以 etcd 为例，大致流程是：

1. 服务端启动时把自身地址注册到 etcd，设置租约。
2. 客户端启动时，通过 etcd resolver 获取实例列表，并监听变更事件。
3. 后端实例发布新版本时，etcd 里的实例列表自动更新，客户端连接池自动剔除旧实例、接入新实例。

这里最需要注意的是优雅下线（drain）：服务端在收到终止信号后，不能立刻退出，要先把实例从注册中心摘掉、等待正在处理的请求完成，再真正退出进程。否则会出现“客户端连接旧实例、但旧实例已经不存在”的情况。

4.2 负载均衡模式：客户端负载均衡和代理模式

gRPC 的负载均衡可以在多个位置做：

• 客户端负载均衡：客户端内置 resolver 和 balancer，拿到后端实例列表后，按策略分发请求。常用策略有 round_robin（轮询）、pick_first（选第一个可用实例）。
• 中间代理负载均衡：客户端不感知后端实例，统一把请求发到一个网关（如 nginx、envoy），由网关负责转发。

我的建议是：在 K8s 环境里，如果服务数量少、连接数少，直接依赖 K8s Service 自带的负载均衡就够了；如果是大规模调用，客户端负载均衡配合轮询反而是更简单可靠的方案，因为它省掉了一层代理转发延迟，还能充分利用 HTTP/2 多路复用。

客户端启用轮询：

go复制conn, err := grpc.NewClient(
    "dns:///order-service:9090",
    grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

注意：round_robin 是基于“子连接”的轮询，不是基于“流”的轮询。一个连接对应一个后端实例，实例之间尽量均衡即可，做不到完全精确的按请求数均分。

4.3 超时、重试与熔断：分布式调用的“三件套”

微服务调用里最经典的连锁故障就是 A 调 B，B 调 C，C 超时了，B 和 C 都卡住，线程池/连接池被打满。gRPC 自带的超时机制是 context.WithTimeout，但更系统的做法需要三层控制：

• 超时（Timeout）：每个请求必须设置 Deadline。从调用方发起，到整个链路结束，总耗时必须是收敛的。
• 重试（Retry）：对幂等接口可以做有限重试，但重试必须有上限（比如最多 3 次），并且要配合指数退避（Exponential Backoff），否则雪崩时大家都在疯狂重试，后端直接被放大流量打垮。
• 熔断（Circuit Breaker）：当某个服务连续失败率达到阈值，直接把请求快速失败，不再发往后端，给后端一个喘息的机会。

gRPC 自带负载均衡和连接状态管理，但熔断不是内置能力。通常可以：

• 在拦截器里实现简单的熔断逻辑，比如用滑动窗口统计失败率；
• 或者引入现成的库，如 Go 生态里的 sony/gobreaker。

重置一个简单的拦截器熔断示例：

go复制breaker := gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name:        "order-service",
    MaxRequests: 3,
    Interval:    10 * time.Second,
    Timeout:     30 * time.Second,
    ReadyToTrip: func(counts gobreaker.Counts) bool {
        return counts.ConsecutiveFailures >= 5
    },
})

// 在调用前执行 breaker.Execute

4.4 链路追踪与 Metrics：分布式排查的“眼睛”

gRPC 有个大优势：通过 metadata 传递 trace 信息是天然的做法，配合 OpenTelemetry 的 grpc 插件，可以做到自动注入和提取 trace context。

在 Go 里接入 OpenTelemetry 大致步骤：

go复制import (
    "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
    "go.opentelemetry.io/otel/trace"
)

// 服务端
s := grpc.NewServer(
    grpc.UnaryInterceptor(otelgrpc.UnaryServerInterceptor()),
)

// 客户端
conn, err := grpc.NewClient("dns:///order-service:9090",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor()),
)

这样每个 RPC 调用都会自动生成 span，并把 trace id 写入 metadata。整套链路下来，配合 Jaeger 或 Zipkin，排查一次“请求从哪开始变慢”的体验，和没有链路追踪时完全是两个世界。

Metrics 方面，gRPC 官方提供了 grpc-go 的 metrics 包（或使用 Prometheus 客户端库暴露 grpc_server_handled_total、grpc_server_handling_seconds 等指标）。我一般会重点监控以下指标：

5. 生产调优：连接管理、参数配置与性能实测

5.1 连接参数：channel 调优的几个关键配置

生产环境里看到过不少默认配置不够用的情况。常用的调优点有这些：

服务端代码示例：

go复制s := grpc.NewServer(
    grpc.MaxRecvMsgSize(16 * 1024 * 1024), // 16MB
    grpc.KeepaliveParams(keepalive.ServerParameters{
        MaxConnectionIdle:     5 * time.Minute,
        MaxConnectionAge:      30 * time.Minute,
        MaxConnectionAgeGrace: 5 * time.Second,
    }),
)

Keepalive 参数特别值得说一下：默认的 gRPC 客户端 keepalive 间隔是 2 小时，这在大多数跨机房、跨云环境的场景下太长了。NAT 网关（比如 AWS 的 ELB、K8s 的 Service）经常会回收空闲连接，客户端的连接在长时间空闲后可能已经断开，但客户端感知不到。把 keepalive 缩短到 30 秒到 1 分钟，能有效降低“连接已经挂了但还在发请求”的概率。

5.2 连接池与超时重试的配置

在 gRPC 里，一个 conn 本身就是连接池（内部维护多个子连接）。所以不要在应用层再做一层连接池，避免重复开连接。

但有一个文档上很容易忽略的点：grpc.NewClient 默认是 lazy connect 的，即它不会在创建时立刻建立连接，而是等到有请求时再建立。在测试环境中，这可能导致你刚启动客户端就去调用服务，但连接还没就绪，出现 Unavailable。解决办法是调用前用 Connect() 显式等待连接，或者在构造时加上阻塞连接选项。

重试配置建议在服务端或客户端统一设置：

go复制conn, err := grpc.NewClient(
    "dns:///order-service:9090",
    grpc.WithDefaultServiceConfig(`{
        "methodConfig": [{
            "name": [{"service": "order.OrderService"}],
            "retryPolicy": {
                "MaxAttempts": 3,
                "InitialBackoff": "0.1s",
                "MaxBackoff": "1s",
                "BackoffMultiplier": 2.0,
                "RetryableStatusCodes": ["UNAVAILABLE", "RESOURCE_EXHAUSTED"]
            }
        }]
    }`),
)

注意：只有幂等接口才建议配置重试。如果接口不幂等，重试可能产生重复下单、重复扣款。在订单类系统里，我通常的做法是：非幂等接口直接不配置重试，而是在应用层做幂等控制之后才放开重试。

5.3 性能压测：从六倍差距看调优的价值

拿我们内部的压测数据举个例子（环境是 4C8G 的容器，Go 语言实现，服务端和客户端均在同一 VPC 内）：

这只是个参考数据，不同机器、不同接口复杂度差距很大，但量级的差距是真实的。一个主要原因是 JSON 序列化和解析消耗大量 CPU，另一个原因是 HTTP/1.1 的连接管理开销大。

压测的时候有个容易踩的坑：不要用单连接去压 gRPC。虽然 HTTP/2 多路复用了，但单连接下并发超过一定阈值，会在同一 TCP 连接里产生调度竞争。一般建议压测时开 4~8 条连接模拟不同客户端，压出来的数据才接近生产表现。

5.4 大消息传输的注意事项

gRPC 默认最大接收 4MB，如果你的接口要传图片或大数据流，一定要显式调大。但“调大上限”不等于“推荐传大包”。经验是：

• 单条消息超过 1MB 就要考虑有没有更好的方案，比如拆成分片或走对象存储。
• 大消息会占用内存和 GC，频繁发送大消息会导致服务端内存抖动。
• 流式接口是一点一点发送的，适合大数据量场景，但注意控制发送速率，不要一次性给 channel 塞太多消息。

6. 踩坑实录：常见问题与排查技巧

6.1 UNAVAILABLE：连接不可用的多种原因

报错形如 rpc error: code = Unavailable desc = connection error。常见原因：

我遇到最多的是 DNS 解析问题。dns:/// 解析是启动时做的，如果启动时 DNS 短暂不可用，整个客户端就起不来。解决方案是配合 etcd 或 consul 做服务发现，而不是依赖 DNS。

6.2 DEADLINE_EXCEEDED：超时不是玄学

这个错误一般分为两类：

• 客户端主动超时：context.WithTimeout 到期，请求还没完成。需要分析是网络延迟、后端慢还是队列堆积。
• 服务端主动超时：服务端处理器也设置了 deadline，处理超时直接返回。

排查时要注意：一旦设置了总链路超时，所有中间跳都会共享同一个 deadline。服务端处理慢，不代表客户端一定报错，因为客户端可能设置了 5 秒，但服务端内部一个 DB 查询花了 4 秒，结果客户端在 4.5 秒时收到响应，刚好赶上。这类问题的核心永远是先看耗时分布，再看全链路 trace。

6.3 流式调用中的背压问题

用双向流或服务端流时，如果发送速度大于接收速度，内存会持续增长。gRPC 底层有自己的流量控制机制，但应用层发送时也必须注意：

• 不要在一个 for 循环里无脑 Send，检查 SendMsg 的返回错误。
• 如果对端处理慢，Send 会阻塞，这是正常的背压信号，不要用大缓冲消掉它。
• 流式接口要设置合理的超时和 context 取消，避免长期占用的 goroutine 泄漏。

6.4 日志里查不到业务错误

gRPC 的错误默认返回给调用方，但框架本身不会在服务端打日志。很多团队上线后说“报错了但服务端日志里啥都没有”，原因是业务层没有统一拦截器打日志。强烈建议服务端给每个 RPC 增加基础访问日志拦截器，记录方法名、耗时、错误码、请求大小等，这对线上排错的意义极大。

go复制func LoggingUnaryInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
    start := time.Now()
    resp, err := handler(ctx, req)
    if err != nil {
        log.Printf("[took %dms] method=%s code=%s err=%v",
            time.Since(start).Milliseconds(), info.FullMethod, status.Code(err), err)
    }
    return resp, err
}

6.5 常见问题速查表

写在最后的经验

在我实际使用 gRPC 的过程里，最大的体会是：它的性能红利只有在正确使用的前提下才能发挥出来。刚才说的连接复用、拦截器、Keepalive、超时控制，这些都是上线前必须想清楚的事，否则线上会出现很多“怪问题”。另外一个值得养成的习惯是：任何跨语言、跨服务的接口，先写 proto，后写代码。proto 就是团队里的沟通语言，接口评审的时候直接评审 proto 就够了。最后分享一个实操小技巧：本地调试时开启 gRPC reflection，再配合 grpcurl，真的能省下大量写测试客户端的时间。等你的服务数量真的上了规模，回头再看这套架构，你会发现当时迁移到 gRPC 的决定是值得的。