gRPC 服务间通信实战：从定义到调用

摘要: 微服务拆好了，服务之间怎么"说话"？本文以 CampusHub 校园活动平台为例，从 Proto 多服务定义、单连接多客户端初始化、跨服务调用与错误处理，到链路追踪和熔断降级，完整展示 go-zero 中 gRPC 服务间通信的工程实践。所有代码均来自生产项目，拿来即用。

标签: gRPC, go-zero, 微服务, Protocol Buffers, 服务间通信, 实战

分类: 后端开发

---

引言

在上一篇文章中，我们搭建了 CampusHub 的微服务骨架——User、Activity、Chat 三个服务各司其职。但架构图画得再漂亮，服务之间不能通信就是一盘散沙。

来看一个真实场景：用户报名活动时，Activity RPC 需要调用 User RPC 做信用校验和实名认证。这涉及跨服务调用、错误传播、链路追踪等一系列问题。

通过本文，你将学会

• ✅ 在一个 Proto 文件中定义多个 gRPC Service
• ✅ 用单连接初始化多个 RPC 客户端（节省资源）
• ✅ 实现跨服务调用与业务错误传播
• ✅ 通过拦截器实现 Trace ID 全链路传播
• ✅ 配置令牌桶限流 + SRE 熔断保护高并发场景

---

问题分析

服务间通信看似只是"调个接口"，实际要解决四个核心挑战：

挑战	说明
📋 契约定义	多个服务如何共享接口定义？Proto 文件怎么组织？
❌ 错误传播	User RPC 返回"信用分不足"，Activity RPC 怎么原样传给客户端？
🔍 可观测性	一个请求跨三个服务，怎么串起来排查问题？
🛡️ 容错	User RPC 挂了，Activity 的报名接口要不要跟着挂？

常见错误做法

❌ 每个 Service 一个 Proto 文件 → 文件爆炸，维护成本高
❌ 裸 error 返回 → 客户端拿到 rpc error: code = Unknown，完全不知道哪里出了问题
❌ 每个 Service 独立建连 → 同一个 User RPC 建了 4 条连接，资源浪费
❌ 无超时无熔断 → 下游服务卡住 30 秒，上游跟着一起卡

正确做法

✅ 多 Service 单 Proto → 同一模块的服务定义在一个文件，goctl 一键生成
✅ BizError 拦截器 → 业务错误码在 gRPC Status 中透传，客户端精确解析
✅ 单连接多客户端 → 共享一个 gRPC 连接，初始化多个 Service 客户端
✅ Etcd 服务发现 + 超时 + 熔断 → 生产级容错配置

---

解决方案

整体方案围绕"活动报名"这个核心场景展开。当用户点击报名按钮，请求会经过以下完整链路：

架构决策

决策点	方案	理由
连接模式	单连接多服务	User RPC 有 CreditService、VerifyService、TagService 等，共享一个 gRPC 连接即可
错误处理	BizError → gRPC Status → BizError	服务端拦截器统一转换，客户端 FromError() 统一解析
链路追踪	Client/Server 拦截器传播 trace_id	通过 gRPC metadata 透传，无侵入
服务发现	Etcd + NonBlock	启动时不阻塞，运行时自动发现
容错	令牌桶限流 + SRE 熔断	限流挡住突发流量，熔断保护下游故障不扩散

---

完整实现

📌 示例 1（基础）：Proto 定义 + 客户端初始化

Proto 多服务定义

CampusHub 的 User 模块在一个 user.proto 中定义了多个 Service，每个 Service 职责清晰：

// 📁 app/user/rpc/user.proto
syntax = "proto3";
package user;
option go_package = "./pb";

// ========== CreditService 信用分服务 ==========
// 调用方: Activity服务、User API、MQ Consumer
service CreditService {
    // 校验是否允许报名
    // 业务规则: score < 60 禁止, 60-69 限频, >= 70 正常
    rpc CanParticipate(CanParticipateReq) returns (CanParticipateResp);
    // 校验是否允许发布活动（需 score >= 90）
    rpc CanPublish(CanPublishReq) returns (CanPublishResp);
    // 获取用户信用信息
    rpc GetCreditInfo(GetCreditInfoReq) returns (GetCreditInfoResp);
    // 变更信用分（签到+2、爽约-10 等）
    rpc UpdateScore(UpdateScoreReq) returns (UpdateScoreResp);
}

// ========== VerifyService 学生认证服务 ==========
// 调用方: User API、Activity服务
service VerifyService {
    // 查询用户是否已完成学生认证
    rpc IsVerified(IsVerifiedReq) returns (IsVerifiedResp);
    // 提交学生认证申请（触发 OCR 识别）
    rpc ApplyStudentVerify(ApplyStudentVerifyReq) returns (ApplyStudentVerifyResp);
    // 用户确认/修改认证信息
    rpc ConfirmStudentVerify(ConfirmStudentVerifyReq) returns (ConfirmStudentVerifyResp);
}

// ========== TagService 标签服务 ==========
service TagService {
    rpc GetAllTags(GetAllTagsReq) returns (GetAllTagsResp);
    rpc GetTagsByIds(GetTagsByIdsReq) returns (GetTagsByIdsResp);
}

// ========== UserBasicService 用户基础服务 ==========
service UserBasicService {
    rpc GetUserInfo(GetUserInfoReq) returns (GetUserInfoResponse);
    rpc GetGroupUser(GetGroupUserReq) returns (GetGroupUserResponse);
}

💡 设计要点：一个模块的所有 Service 放在同一个 Proto 文件中。goctl 会为每个 Service 生成独立的 client 包，调用方按需引入即可。

生成代码的命令：

cd app/user/rpc
goctl rpc protoc user.proto \
    --go_out=./pb \
    --go-grpc_out=./pb \
    --zrpc_out=. \
    -style go_zero

执行后会生成如下目录结构：

app/user/rpc/client/
├── creditservice/       # CreditService 客户端
│   └── credit_service.go
├── verifyservice/       # VerifyService 客户端
│   └── verify_service.go
├── tagservice/          # TagService 客户端
│   └── tag_service.go
└── userbasicservice/    # UserBasicService 客户端
    └── user_basic_service.go

单连接多服务客户端初始化

关键技巧：一个 zrpc.MustNewClient 连接，初始化多个 Service 客户端。

// 📁 app/activity/rpc/internal/svc/service_context.go

type ServiceContext struct {
    Config config.Config

    // ... 数据存储、Model 层等字段省略

    // RPC 客户端（调用其他微服务）
    CreditRpc     creditservice.CreditService       // 信用分服务
    VerifyService verifyservice.VerifyService       // 学生认证服务
    TagRpc        tagservice.TagService             // 标签服务
    UserBasicRpc  userbasicservice.UserBasicService // 用户基础服务
}

func NewServiceContext(c config.Config) *ServiceContext {
    // ... 数据库、Redis 初始化省略

    // 🔑 核心：所有 User 服务共用同一个 gRPC 连接
    userRpcClient := zrpc.MustNewClient(c.UserRpc)

    // 基于同一连接创建不同 Service 的客户端
    creditRpc := creditservice.NewCreditService(userRpcClient)
    verifyRpc := verifyservice.NewVerifyService(userRpcClient)
    tagRpc := tagservice.NewTagService(userRpcClient)
    userBasicRpc := userbasicservice.NewUserBasicService(userRpcClient)

    return &ServiceContext{
        // ...
        CreditRpc:     creditRpc,
        VerifyService: verifyRpc,
        TagRpc:        tagRpc,
        UserBasicRpc:  userBasicRpc,
    }
}

对应的 YAML 配置只需要一份 UserRpc 连接配置：

# 📁 app/activity/rpc/etc/activity-rpc.yaml

# RPC 客户端配置 —— 通过 Etcd 发现 User RPC
UserRpc:
  Etcd:
    Hosts:
      - 192.168.10.4:2379
    Key: user.rpc
  NonBlock: true    # 启动时不阻塞，异步连接
  Timeout: 3000     # 超时 3 秒

💡 为什么用单连接？ gRPC 基于 HTTP/2，天然支持多路复用。一个 TCP 连接可以并发处理多个 RPC 调用，无需为每个 Service 单独建连。4 个 Service 共享 1 个连接，资源利用率提升 4 倍。

---

📌 示例 2（完整）：跨服务调用 + 错误处理

报名逻辑：信用校验 + 实名校验

这是 CampusHub 中最核心的跨服务调用场景。Activity RPC 在处理报名请求时，需要依次调用 User RPC 的两个服务：

// 📁 app/activity/rpc/internal/logic/register_activity_logic.go

func (l *RegisterActivityLogic) RegisterActivity(
    in *activity.RegisterActivityRequest,
) (resp *activity.RegisterActivityResponse, err error) {
    userID := in.GetUserId()
    activityID := in.GetActivityId()

    // ==================== 第一步：限流检查 ====================
    // 令牌桶限流，防止突发流量打垮下游服务
    if l.svcCtx.RegistrationLimiter != nil &&
        !l.svcCtx.RegistrationLimiter.AllowCtx(l.ctx) {
        return &activity.RegisterActivityResponse{
            Result: "fail",
            Reason: "请求过于频繁，请稍后再试",
        }, nil
    }

    // ==================== 活动校验（本地查询）====================
    activityData, err := l.svcCtx.ActivityModel.FindByID(l.ctx, uint64(activityID))
    if err != nil { /* 错误处理省略 */ }

    // ==================== 信用校验（跨服务调用 User RPC）====================
    // 调用 CreditService.CanParticipate 检查用户信用分
    creditResp, err := l.svcCtx.CreditRpc.CanParticipate(l.ctx,
        &creditservice.CanParticipateReq{
            UserId: userID,
        })
    if err != nil {
        // RPC 调用失败（网络超时、服务不可用等）
        l.Errorf("信誉校验失败: userId=%d, err=%v", userID, err)
        return &activity.RegisterActivityResponse{
            Result: "fail",
            Reason: "信誉校验失败，请稍后重试",
        }, nil
    }
    // 信用分不足，拒绝报名并记录失败原因
    if !creditResp.GetAllowed() {
        return &activity.RegisterActivityResponse{
            Result: "fail",
            Reason: creditResp.GetReason(), // "信用分过低(<60)，账户已被限制报名"
        }, nil
    }

    // ==================== 实名校验（跨服务调用 User RPC）====================
    // 仅当活动要求学生认证时才校验
    if activityData.RequireStudentVerify {
        verifyResp, err := l.svcCtx.VerifyService.IsVerified(l.ctx,
            &verifyservice.IsVerifiedReq{
                UserId: userID,
            })
        if err != nil {
            l.Errorf("实名校验失败: userId=%d, err=%v", userID, err)
            return &activity.RegisterActivityResponse{
                Result: "fail",
                Reason: "实名校验失败，请稍后重试",
            }, nil
        }
        if !verifyResp.GetIsVerified() {
            return &activity.RegisterActivityResponse{
                Result: "fail",
                Reason: "请先完成学生认证",
            }, nil
        }
    }

    // ==================== 后续：熔断保护 + 写入报名记录 ====================
    // ... 见示例 3
}

💡 调用模式总结：每次跨服务调用都遵循 调用 → 检查 error → 检查业务结果 三步走。error 代表基础设施故障（网络、超时），业务结果（如 allowed=false）代表正常的业务拒绝。

错误处理链：BizError → gRPC Status → BizError

跨服务调用最头疼的问题是：User RPC 抛出的业务错误，怎么原样传递给客户端？

CampusHub 的解决方案是一条完整的错误处理链：

第一步：服务端拦截器 —— 将 BizError 转换为 gRPC Status

// 📁 common/interceptor/rpcserver/error_interceptor.go

func ErrorInterceptor(ctx context.Context, req interface{},
    info *grpc.UnaryServerInfo, handler grpc.UnaryHandler,
) (resp interface{}, err error) {
    // 执行业务逻辑
    resp, err = handler(ctx, req)
    if err != nil {
        // 获取原始错误（支持 errors.Wrap 包装）
        causeErr := errors.Cause(err)

        if bizErr, ok := causeErr.(*errorx.BizError); ok {
            // ✅ 业务错误：转换为 gRPC Status，保留业务错误码
            logx.WithContext(ctx).Errorf(
                "【RPC-SRV-ERR】method=%s, code=%d, msg=%s",
                info.FullMethod, bizErr.Code, bizErr.Message)
            return nil, status.Error(codes.Code(bizErr.Code), bizErr.Message)
        }

        // ❌ 非业务错误（DB、网络等）：返回通用错误，不暴露内部细节
        logx.WithContext(ctx).Errorf(
            "【RPC-SRV-ERR】method=%s, err=%+v", info.FullMethod, err)
        return nil, status.Error(codes.Code(errorx.CodeInternalError), "内部服务器错误")
    }
    return resp, nil
}

第二步：客户端解析 —— 从 gRPC Status 还原 BizError

// 📁 common/errorx/error.go

// FromError 从 error 转换为 BizError
// 支持: *BizError 直接返回 | gRPC Status 解析业务码 | 其他错误返回内部错误
func FromError(err error) *BizError {
    if err == nil {
        return nil
    }
    causeErr := errors.Cause(err)

    // 1. 本地 BizError，直接返回
    if bizErr, ok := causeErr.(*BizError); ok {
        return bizErr
    }

    // 2. gRPC Status（从 RPC 返回的错误）
    if gstatus, ok := status.FromError(causeErr); ok {
        grpcCode := int(gstatus.Code())
        message := gstatus.Message()

        // 如果 gRPC code 是业务错误码，还原为 BizError
        if IsValidCode(grpcCode) {
            return &BizError{Code: grpcCode, Message: message}
        }
    }

    // 3. 兜底：返回内部错误，不暴露细节
    return &BizError{Code: CodeInternalError, Message: "内部服务器错误"}
}

💡 设计精髓：业务错误码复用 gRPC Status 的 code 字段传输，无需额外的序列化协议。服务端 ErrorInterceptor 和客户端 FromError 形成对称的编解码对，任何服务都可以透明地传播业务错误。

---

📌 示例 3（优化）：链路追踪 + 熔断降级

Trace ID 全链路传播

一个报名请求跨越 API → Activity RPC → User RPC 三个服务，出了问题怎么排查？答案是 Trace ID。

CampusHub 通过一对拦截器实现 Trace ID 的自动传播：

// 📁 common/interceptor/traceid.go

// ClientTraceIDInterceptor 客户端拦截器
// 在发起 RPC 调用时，自动将 trace_id 从 context 注入 gRPC metadata
func ClientTraceIDInterceptor() grpc.UnaryClientInterceptor {
    return func(ctx context.Context, method string, req, reply interface{},
        cc *grpc.ClientConn, invoker grpc.UnaryInvoker,
        opts ...grpc.CallOption) error {

        // 从 context 中提取 trace_id
        traceID := ctxdata.GetTraceIDFromCtx(ctx)
        if traceID != "" {
            // 通过 gRPC metadata 传递给服务端
            ctx = metadata.AppendToOutgoingContext(ctx, "trace_id", traceID)
        }
        return invoker(ctx, method, req, reply, cc, opts...)
    }
}

// ServerTraceIDInterceptor 服务端拦截器
// 在收到 RPC 请求时，自动从 gRPC metadata 提取 trace_id 注入 context
func ServerTraceIDInterceptor() grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{},
        info *grpc.UnaryServerInfo, handler grpc.UnaryHandler,
    ) (interface{}, error) {

        // 从 metadata 中提取 trace_id
        if md, ok := metadata.FromIncomingContext(ctx); ok {
            if traceIDs := md.Get("trace_id"); len(traceIDs) > 0 {
                ctx = ctxdata.WithTraceID(ctx, traceIDs[0])
            }
        }
        return handler(ctx, req)
    }
}

注册方式：

// 客户端：发起调用时自动携带 trace_id
userRpc := zrpc.MustNewClient(c.UserRpc,
    zrpc.WithUnaryClientInterceptor(interceptor.ClientTraceIDInterceptor()))

// 服务端：接收请求时自动提取 trace_id
server.AddUnaryInterceptors(interceptor.ServerTraceIDInterceptor())

同时，CampusHub 还配置了 Jaeger 链路追踪，在 YAML 中一行搞定：

# 📁 app/activity/rpc/etc/activity-rpc.yaml

# 链路追踪 —— 接入 Jaeger
Telemetry:
  Name: activity-rpc
  Endpoint: http://192.168.10.4:14268/api/traces
  Sampler: 1.0       # 采样率 100%（生产环境建议 0.1）
  Batcher: jaeger

SRE 熔断器保护写入操作

报名的写入操作（创建记录 + 生成票券）是最容易出问题的环节。CampusHub 使用自研的 SRE 熔断器保护这一关键路径：

// 📁 app/activity/rpc/internal/logic/register_activity_logic.go

// ==================== 第二步：熔断保护 ====================
// 将报名写入操作包装在熔断器中
registerFn := func() error {
    registered, err := l.registerWithConsistency(activityID, userID, genTicketPayload)
    if err != nil {
        return err
    }
    alreadyRegistered = registered
    return nil
}

if l.svcCtx.RegistrationBreaker != nil {
    err = l.svcCtx.RegistrationBreaker.DoWithFallbackAcceptable(
        registerFn,
        // 熔断触发时的降级处理
        func(err error) error {
            return breaker.ErrServiceUnavailable
        },
        // 判断哪些错误是"可接受的"（不计入熔断统计）
        func(err error) bool {
            if err == nil {
                return true
            }
            // 名额已满是正常业务结果，不应触发熔断
            return errors.Is(err, model.ErrActivityQuotaFull)
        },
    )
} else {
    err = registerFn()
}

熔断器的核心实现基于 SRE 算法——在滑动窗口内统计错误率，超过阈值则自动熔断：

// 📁 common/breakerx/sre_breaker.go

type SREConfig struct {
    Name      string        // 熔断器名称
    Requests  int           // 统计窗口最小请求数
    ErrorRate float64       // 错误率阈值（0.5 = 50%）
    Timeout   time.Duration // 熔断持续时间
}

func (b *sreBreaker) record(success bool) {
    if success {
        b.window.Add(0) // 成功：错误值为 0
    } else {
        b.window.Add(1) // 失败：错误值为 1
    }
    errors, total := b.history()
    // 请求数不足，不做判断
    if total < b.requests {
        return
    }
    // 错误率超过阈值，触发熔断
    if float64(errors)/float64(total) >= b.errorRate {
        b.mu.Lock()
        b.openUntil = time.Now().Add(b.timeout)
        b.mu.Unlock()
    }
}

限流和熔断的初始化在 ServiceContext 中完成：

// 📁 app/activity/rpc/internal/svc/service_context.go

// 令牌桶限流器（基于 Redis，支持分布式）
registrationLimiter := limit.NewTokenLimiter(
    c.RegistrationLimit.Rate,   // 每秒允许 100 个请求
    c.RegistrationLimit.Burst,  // 突发容量 200
    rds,                        // Redis 客户端
    "activity:registration:limiter",
)

// SRE 熔断器
registrationBreaker := breakerx.NewSREBreaker(breakerx.SREConfig{
    Name:      c.RegistrationBreaker.Name,      // "activity-registration"
    Requests:  c.RegistrationBreaker.Requests,   // 最少 100 个请求才统计
    ErrorRate: c.RegistrationBreaker.ErrorRate,   // 错误率 50% 触发熔断
    Timeout:   time.Duration(c.RegistrationBreaker.Timeout) * time.Second, // 熔断 60 秒
})

容错决策的完整流程：

---

运行结果

✅ 成功场景

用户报名成功时，日志链路清晰可追踪：

[Activity API] trace_id=abc123 | POST /activity/register | userId=10001
[Activity RPC] trace_id=abc123 | 限流检查通过
[Activity RPC] trace_id=abc123 | → CreditService.CanParticipate(userId=10001)
[User RPC]     trace_id=abc123 | CanParticipate: score=85, level=2, allowed=true
[Activity RPC] trace_id=abc123 | ← 信用校验通过, score=85
[Activity RPC] trace_id=abc123 | → VerifyService.IsVerified(userId=10001)
[User RPC]     trace_id=abc123 | IsVerified: verified=true, school=清华大学
[Activity RPC] trace_id=abc123 | ← 实名校验通过
[Activity RPC] trace_id=abc123 | 报名写入成功, ticketCode=TK3F8A2B9C1D
[Activity API] trace_id=abc123 | 200 OK | result=success

❌ 失败场景：信用分不足

[Activity RPC] trace_id=def456 | → CreditService.CanParticipate(userId=10002)
[User RPC]     trace_id=def456 | CanParticipate: score=55, level=0, allowed=false
[Activity RPC] trace_id=def456 | ← 信用校验拒绝: 信用分过低(<60)，账户已被限制报名
[Activity API] trace_id=def456 | 200 OK | result=fail, reason=信用分过低

🔥 熔断触发场景

[Activity RPC] 熔断器统计: 最近100次请求中52次失败, 错误率=52% > 阈值50%
[Activity RPC] ⚡ 熔断器打开! 持续60秒, 后续请求直接降级
[Activity RPC] trace_id=ghi789 | 熔断器拦截, 返回: 服务暂时不可用
... 60秒后 ...
[Activity RPC] 熔断器关闭, 恢复正常处理

---

优化建议

🚀 性能优化

• 连接复用：已实现单连接多服务模式，gRPC HTTP/2 多路复用天然支持高并发
• NonBlock 模式：NonBlock: true 让服务启动不依赖下游就绪，提升启动速度
• 批量调用：如果需要同时校验信用和实名，可以用 errgroup 并发调用，减少串行等待

🛡️ 可靠性优化

• SRE 熔断：已实现基于滑动窗口的错误率统计，自动熔断保护
• 令牌桶限流：基于 Redis 的分布式限流，支持多实例共享配额
• 优雅降级：熔断触发时返回友好提示，而非直接报错；名额已满等业务错误不计入熔断统计

🔍 可观测性优化

• Trace ID 传播：Client/Server 拦截器自动传播，支持 Unary 和 Stream 两种模式
• 结构化日志：所有 RPC 错误通过 logx.WithContext(ctx) 记录，自动关联 trace_id
• Jaeger 集成：Telemetry 配置一行接入，支持采样率调节（生产建议 Sampler: 0.1）

---

常见问题

Q1: 为什么把多个 Service 放在一个 Proto 文件里？

A: 同一模块的 Service 共享消息定义（如 CanParticipateReq 和 IsVerifiedReq 都需要 user_id），放在一个文件中避免跨文件引用。goctl 会为每个 Service 生成独立的 client 包，调用方按需引入，不会产生耦合。

Q2: gRPC 错误码和 HTTP 状态码是什么关系？

A: gRPC 有自己的错误码体系（codes.OK、codes.NotFound 等），与 HTTP 状态码是独立的。CampusHub 的做法是将业务错误码（如 2201 = 认证记录不存在）放在 gRPC Status 的 code 字段中传输，API 层再通过 FromError() 解析后转换为 HTTP 响应。

Q3: Etcd 服务发现和直连模式怎么切换？

A: 只需修改 YAML 配置。Etcd 模式用于生产环境：

UserRpc:
  Etcd:
    Hosts: ["192.168.10.4:2379"]
    Key: user.rpc

直连模式用于本地开发：

UserRpc:
  Endpoints:
    - 127.0.0.1:9001

Q4: 跨服务调用超时了怎么办？

A: 三层防护：

1. 连接级超时：Timeout: 3000（3 秒），超时自动断开
2. 熔断保护：连续超时会触发熔断，后续请求直接降级
3. Context 传播：上游的 deadline 会通过 gRPC 自动传播到下游，避免下游无限等待

Q5: 本地调试跨服务调用怎么搞？

A: 两种方式：

1. 直连模式：把 UserRpc 配置改为 Endpoints: ["127.0.0.1:9001"]，直接连本地服务
2. Mock 模式：goctl 生成的 client 是 interface，可以在测试中注入 mock 实现

Q6: 单连接会不会成为性能瓶颈？

A: 不会。gRPC 基于 HTTP/2，单连接支持数千个并发 stream。CampusHub 的 4 个 Service 共享一个连接，在压测中 QPS 达到 5000+ 时连接利用率仍不到 30%。如果确实需要更高吞吐，可以配置连接池（go-zero 支持 MaxConn 参数）。

---

总结

✅ 本文学习成果

通过本文，我们完整实践了 go-zero 中 gRPC 服务间通信的核心技术：

• ✅ Proto 多服务定义：一个文件定义 CreditService、VerifyService、TagService 等多个服务
• ✅ 单连接多客户端：zrpc.MustNewClient 一次建连，初始化 4 个 Service 客户端
• ✅ 跨服务调用：Activity RPC 调用 User RPC 做信用校验和实名认证
• ✅ 错误处理链：BizError → gRPC Status → BizError，业务错误码全链路透传
• ✅ 链路追踪：Client/Server 拦截器自动传播 trace_id，接入 Jaeger
• ✅ 容错保护：令牌桶限流 + SRE 熔断，保护高并发场景下的服务稳定性

📖 下一篇预告

第三篇：WebSocket 实时通信实现

📚 延伸阅读

• gRPC 官方文档 - Go Quick Start
• go-zero 官方文档 - RPC 服务
• Protocol Buffers Language Guide
• Google SRE - 处理过载