1057 lines
43 KiB
Markdown
1057 lines
43 KiB
Markdown
---
|
||
tags:
|
||
- 后端
|
||
- Go
|
||
- gRPC
|
||
- 测试
|
||
- 自我考察
|
||
create time: 2026-05-07
|
||
update time: 2026-05-07
|
||
status: reviewed
|
||
---
|
||
|
||
# gRPC 自测题
|
||
|
||
## 概述
|
||
|
||
本文档是一份 gRPC 知识的自测题库，覆盖从底层协议到生产实践的全链路知识点。包含选择题、填空题、代码补全和主观题四种题型，附带详细参考答案与解析，适合用于自我评估或团队内部考核。
|
||
|
||
## 正文
|
||
|
||
### 使用说明
|
||
|
||
本试卷覆盖 **hzh/MS/06-gRPC** 知识索引中 **协议与架构 → Proto设计 → RPC模式 → 拦截器 → 错误处理 → 连接管理 → 最佳实践** 全链路知识点。共四部分：选择题、填空题、代码补全、主观题。
|
||
|
||
**建议用时：** 50 分钟 | **及格线：** 70 / 100
|
||
|
||
做完后对照下方「参考答案」自评，错的地方回到对应笔记重新理解。
|
||
|
||
---
|
||
|
||
## 一、选择题（每题 4 分，共 40 分）
|
||
|
||
> 每题只有一个正确答案。
|
||
|
||
### Q1.【gRPC 性能优势的根本原因】
|
||
|
||
以下哪一项是 gRPC 在高频微服务调用场景下比 HTTP/1.1 REST **性能优势最大**的特性？
|
||
|
||
A. Protocol Buffers 的二进制序列化比 JSON 快
|
||
B. HTTP/2 多路复用——一个 TCP 连接上并行多个 Stream
|
||
C. gRPC 自动维护连接池，不用手动管理
|
||
D. HPACK 头部压缩减小了传输体积
|
||
|
||
> [!tip]- Q1 答案
|
||
> **B — HTTP/2 多路复用**
|
||
>
|
||
> **解析：**
|
||
> Protocol Buffers 确实比 JSON 快、连接复用也确实减少了握手开销，但真正的分水岭在于 **HTTP/2 多路复用**。
|
||
>
|
||
> HTTP/1.1 开 10 个并行请求需要 10 条 TCP 连接 → 握手开销大、端口耗尽。一条 HTTP/2 连接就能承载几百个并发 RPC，这就是 gRPC 在高频内部调用的性能优势来源。
|
||
>
|
||
> **为什么不是其他选项：**
|
||
> - ❌ A：序列化速度差通常在微秒级，而建立 TCP 连接的 RTT 在毫秒级——网络开销远大于序列化开销
|
||
> - ❌ C：连接复用是结果不是根源，HTTP/1.1 也可以用 Keep-Alive + 连接池实现
|
||
> - ❌ D：头部压缩对频繁传相同 header 的场景有帮助，但不是核心差异
|
||
>
|
||
> 💡 **关键洞察：** 如果 gRPC 跑在只有单次请求的单连接上，它相比 REST 的优势会大打折扣。真正发挥优势的是"大量并发短请求"的微服务场景。
|
||
|
||
---
|
||
|
||
### Q2.【Proto3 版本兼容性】
|
||
|
||
你的 Service B 更新了 `.proto` 文件，将 `GetUserRequest` 中的 `field_number = 5` 从 `string email` 删除了，但没有修改任何编号。旧版客户端收到新版服务端响应时，会发生什么？
|
||
|
||
A. 反序列化失败，因为字段消失了
|
||
B. 旧客户端忽略未知编号的字段，正常处理其他字段
|
||
C. 旧客户端 panic，因为收到了无法识别的字段类型
|
||
D. 旧客户端把该字段当作空字符串处理
|
||
|
||
> [!tip]- Q2 答案
|
||
> **B — 未知编号的字段会被忽略**
|
||
>
|
||
> **解析：**
|
||
> Protocol Buffers 的二进制编码规则天然保证了向前兼容。每个字段在 wire format 中编码为 `(field_number << 3) | wire_type`，解码器只认识自己定义过的编号，遇到不认识的直接跳过（skipped as unknown field）。
|
||
>
|
||
> ```
|
||
> 新版服务端写入 → wire: (5 << 3) | TYPE_LENGTH_DELIMITED + "alice@example.com"
|
||
> ↓
|
||
> 旧版客户端解码 → 不认识 field_number=5 → 跳过 → 继续解码其他字段 ✅
|
||
> ```
|
||
>
|
||
> **注意反向兼容：** 如果新客户端收到旧服务端的响应，同样也会忽略新增字段的缺失（用默认值），这也是安全的。
|
||
>
|
||
> 💡 **铁律：** "新增字段安全，删除字段也安全（前提是保留编号不重用）"——只要你不重编已使用的编号，双向都是兼容的。
|
||
|
||
---
|
||
|
||
### Q3.【Oneof vs 普通字段】
|
||
|
||
关于 `oneof` 的使用，以下说法**正确**的是：
|
||
|
||
A. `oneof` 可以修饰 `repeated` 类型的字段，方便存储一组互斥值
|
||
B. Proto3 中 `oneof` 所有变体共享同一个零值 `NONE(0)`，所以反序列化时无法区分哪个变体被设置过
|
||
C. Proto3 会为 oneof 自动生成 IsXXX() setter 方法以支持精确的状态判断
|
||
D. oneof 中的成员编号必须跨不同 oneof 组全局唯一
|
||
|
||
> [!tip]- Q3 答案
|
||
> **B — oneof 零值为 NONE(0)，无法区分未设置状态**
|
||
>
|
||
> **解析：**
|
||
> `oneof` 的核心语义是"同一时刻最多一个有值"，它是 Proto3 表达可选联合类型的方式。
|
||
>
|
||
> **逐项分析：**
|
||
> - ❌ A：`oneof` **不能**加 `repeated` 修饰符，因为 multiple 值和 oneof 互斥语义矛盾
|
||
> - ✅ B：正确。Proto3 没有 Optional 概念，当 all fields 都等于其默认值时，你无法知道用户到底传了 `"none"` 还是没传
|
||
> - ❌ C：Proto3 **不会**为 oneof 自动生成任何 `IsXXX()` 方法。这正是 Proto3 oneof 的核心痛点——你无法通过 API 判断哪个变体被设置过（因为当所有值都等于默认值时，语义上就是不可区分的）。如果需要区分"未设置"和"设置为空值"，必须使用 Well-Known Types 包装器。
|
||
> - ❌ D：**错误**。Protobuf 规范只要求字段编号在同一个 oneof **内部**唯一，不同 oneof 之间可以重用编号（proto 的二进制编码只看 `(field_number, wire_type)`，不同 oneof 之间不会产生冲突）
|
||
>
|
||
> **如果需要精确表达"可选"**，推荐使用 Well-Known Types 中的 `StringValue` 包装：
|
||
> ```proto
|
||
> google.protobuf.StringValue optional_field = 1; // nil = 未传, "" = 传了空串
|
||
> ```
|
||
>
|
||
> 💡 **工程选择：** oneof 适合"多选一"的业务建模（如支付方式选一种），StringValue 适合"可能有也可能没有"的补充字段。两者不冲突，可以同时出现在一个 message 里。
|
||
|
||
---
|
||
|
||
### Q4.【RPC 模式选型】
|
||
|
||
你需要实现一个实时聊天功能：双方持续互发消息，服务器需要对每条消息做内容审核后再转发给另一方。最适合的 gRPC 模式是：
|
||
|
||
A. Unary —— 每发一条消息建立一个 RPC 调用
|
||
B. Server Streaming —— 客户端发送消息，服务端流式返回审核结果
|
||
C. Client Streaming —— 客户端批量发送，服务端最后返回批量审核结果
|
||
D. Bidirectional Streaming —— 双方同时独立发送和接收消息流
|
||
|
||
> [!tip]- Q4 答案
|
||
> **D — 双向流式是实时聊天场景的最佳选择**
|
||
>
|
||
> **解析：**
|
||
> 聊天的核心特征是：**双方随时都可以发消息**（全双工），且消息到达即推送（低延迟），不需要等对方发完再统一处理。
|
||
>
|
||
> ```mermaid
|
||
> sequenceDiagram
|
||
> participant A as 用户A
|
||
> participant G as gRPC Bridge
|
||
> participant B as 用户B
|
||
> A->>G: ChatMsg("Hello")
|
||
> G->>B: ChatMsg("Hello")
|
||
> B->>G: ChatMsg("Hi!")
|
||
> G->>A: ChatMsg("Hi!")
|
||
> Note over A,B: 各自独立发送，实时接收
|
||
> ```
|
||
>
|
||
> **为什么不适合其他模式：**
|
||
> - ❌ A：每条消息一次 RPC → 巨大的 HTTP/2 Stream 开销，连接数爆炸
|
||
> - ❌ B：Server Streaming 是单向推（客户端→服务端 1:N），聊天是双向交互
|
||
> - ❌ C：Client Streaming 是 N→1，先攒一批再说——聊天不能等有 N 条才处理第一条
|
||
>
|
||
> 💡 **对比 WebSocket：** gRPC 双向流提供了强类型 Proto 契约、自动生成客户端代码、内置认证重试；WebSocket 更灵活（任意 payload、浏览器原生支持），但缺乏类型约束。内部系统推荐 gRPC，面向公众浏览器端推荐 WebSocket。
|
||
|
||
---
|
||
|
||
### Q5.【服务端流式关闭陷阱】
|
||
|
||
关于服务端流式 RPC（Server Streaming），以下说法**最准确**的是：
|
||
|
||
A. 如果服务端 Send 循环中发生异常没有 return，客户端 Recv() 会一直阻塞直到连接断开
|
||
B. 服务端只需要在 for 循环结束后正常退出函数即可，不需要显式 return nil
|
||
C. 如果服务端 Send 循环中没有任何 return，Stream 不会结束，客户端会永久阻塞在 Recv()
|
||
D. gRPC 框架会自动检测并关闭超时的 Stream，不需要开发者关心
|
||
|
||
> [!tip]- Q5 答案
|
||
> **C — 服务端必须确保所有路径都会退出循环或返回错误**
|
||
>
|
||
> **解析：**
|
||
> 服务端流式的生命周期完全由服务端控制。如果服务端没有在任何路径上返回（无论是 `nil` 还是 `error`），Stream 就永远不会结束，客户端将永远阻塞在 `Recv()`。
|
||
>
|
||
> **常见陷阱场景：**
|
||
> ```go
|
||
> func (s *orderServer) ListOrders(req *pb.ListOrdersRequest, stream pb.OrderService_ListOrdersServer) error {
|
||
> orders := s.store.ListAll()
|
||
> for _, o := range orders {
|
||
> stream.Send(o) // ❌ 没有检查 error，也没有 return
|
||
> }
|
||
> return nil // ✅ 但至少这里有 return，不会永久阻塞
|
||
> }
|
||
> ```
|
||
>
|
||
> ```go
|
||
> func buggyList(stream pb.OrderService_ListOrdersServer) error {
|
||
> for {
|
||
> order := getNextOrder()
|
||
> if order == nil {
|
||
> break // break 只是跳出循环，下面必须有 return！
|
||
> }
|
||
> stream.Send(order)
|
||
> }
|
||
> // ⚠️ 这里如果不写 return nil，编译器可能会放过但你应该养成习惯
|
||
> }
|
||
> ```
|
||
>
|
||
> **黄金法则：** "要么在循环内遇到错误 `return err`，要么在循环结束 `return nil`"——两条路径都必须明确存在。
|
||
>
|
||
> 💡 **扩展：** 如果是客户端流式，客户端也需要主动调用 `CloseSend()` 来告诉服务端"我不再发数据了"，否则服务端 `Recv()` 也会永远等待。
|
||
|
||
---
|
||
|
||
### Q6.【拦截器注册陷阱】
|
||
|
||
Go 语言中 gRPC 服务端拦截器注册的常见陷阱是：
|
||
|
||
A. `grpc.UnaryInterceptor()` 每次调用会追加而非覆盖，导致重复执行
|
||
B. `grpc.UnaryInterceptor()` 会覆盖而非追加，多次注册只有最后一次生效
|
||
C. Stream Interceptor 不能与 Unary Interceptor 同时注册
|
||
D. 拦截器只在第一次调用时生效，后续调用被缓存忽略了
|
||
|
||
> [!tip]- Q6 答案
|
||
> **B — 多次注册会覆盖，需要用链式包装函数串联**
|
||
>
|
||
> **解析：**
|
||
> Go 的 `grpc.NewServer(grpc.UnaryInterceptor(f))` 只接受一个拦截器。如果多次调用 `grpc.WithUnaryInterceptor()` 或使用 `NewServer` 多次指定拦截器，后面的会**覆盖**前面的。
|
||
>
|
||
> ```go
|
||
> // ❌ 错误做法——后面覆盖了前面，LoggingInterceptor 永远不会被执行
|
||
> server := grpc.NewServer(
|
||
> grpc.UnaryInterceptor(LoggingInterceptor()),
|
||
> grpc.UnaryInterceptor(AuthInterceptor()), // ← 这个覆盖上一个
|
||
> )
|
||
>
|
||
> // ✅ 正确做法——手动链式串联
|
||
> server := grpc.NewServer(
|
||
> grpc.UnaryInterceptor(chainUnaryInterceptors(
|
||
> AuthInterceptor(),
|
||
> LoggingInterceptor(),
|
||
> MetricsInterceptor(),
|
||
> )),
|
||
> )
|
||
> ```
|
||
>
|
||
> **注意：** 这个问题只在 Go 中存在。Java 的 `Server.intercept()` 支持注册多个拦截器并按序执行，不需要手动串联。
|
||
>
|
||
> 💡 **链式封装思路：** 从右往左包裹 handler。最后一个拦截器最先收到请求（离 handler 最近），第一个拦截器最后收到请求（站在最外层做全局处理）。
|
||
|
||
---
|
||
|
||
### Q7.【状态码选择】
|
||
|
||
客户端发起订单创建请求时，服务端校验发现 `user_id` 格式不合法。最合适的 gRPC 状态码是：
|
||
|
||
A. `Internal` —— 因为这是一个服务端的错误
|
||
B. `InvalidArgument` —— 客户端传入的参数不符合要求
|
||
C. `FailedPrecondition` —— 前置条件不满足
|
||
D. `Unknown` —— 不确定应该用哪个状态码
|
||
|
||
> [!tip]- Q7 答案
|
||
> **B — InvalidArgument 是最准确的语义**
|
||
>
|
||
> **解析：**
|
||
> gRPC 的 16 个标准状态码各有明确的语义边界：
|
||
>
|
||
> | 状态码 | 适用场景 | 本例是否匹配 |
|
||
> |--------|---------|-------------|
|
||
> | `InvalidArgument` | 参数校验失败、格式不合法 | ✅ user_id 格式不对 |
|
||
> | `Internal` | 代码 bug、不可恢复的内部状态 | ❌ 这是预期的业务校验 |
|
||
> | `FailedPrecondition` | 系统状态不允许操作（如账户已被封禁） | ❌ 不是系统状态问题，是入参问题 |
|
||
> | `Unknown` | 无法归类 | ❌ 完全可以归入已有 code |
|
||
>
|
||
> **关键原则：** 永远用 `codes.*` 而不是 `fmt.Errorf` 做返回值。这样才能让客户端通过 `status.Code(err)` 精准判断该重试、降级还是报错。
|
||
>
|
||
> ```go
|
||
> // ❌ 丢掉语义
|
||
> return nil, fmt.Errorf("invalid user_id format")
|
||
>
|
||
> // ✅ 保持 gRPC 一致性
|
||
> return nil, status.Error(codes.InvalidArgument, "user_id must be a valid UUID")
|
||
> ```
|
||
>
|
||
> 💡 **扩展：** 如果需要更精细的错误信息，可以用 `status.New(codes.InvalidArgument, "...").WithDetails(detail).Err()` 附加结构化详情。
|
||
|
||
---
|
||
|
||
### Q8.【Keepalive 配置目的】
|
||
|
||
gRPC 默认不发送 keepalive ping，生产环境中开启 Keepalive 的主要目的是：
|
||
|
||
A. 检测对端是否还活着，实现心跳机制
|
||
B. 防止中间代理（Nginx/云 LB）的 idle timeout 切断空闲连接
|
||
C. 提高数据传输的吞吐量
|
||
D. 触发客户端自动负载均衡切换
|
||
|
||
> [!tip]- Q8 答案
|
||
> **B — 防止中间代理切断空闲连接**
|
||
>
|
||
> **解析：**
|
||
> 两个微服务之间建立了 gRPC 连接后，如果 30 分钟没有任何请求，中间经过的 Nginx、云厂商 LB 或 AWS ALB 很可能已经因 idle timeout 切断了连接。但两端都还以为连接是活的，于是第一个 `Send()` 报 `use of closed network connection`。
|
||
>
|
||
> **解决方案：**
|
||
> ```go
|
||
> grpc.KeepaliveParams(keepalive.ServerParameters{
|
||
> Time: 10 * time.Second, // 每 10s 发一次 ping
|
||
> Timeout: 5 * time.Second, // 等了 5s 没回复就算对方挂了
|
||
> })
|
||
> ```
|
||
>
|
||
> **逐项分析：**
|
||
> - ❌ A：Keepalive 确实能检测存活，但这不是主要目的——gRPC 已经有内置的健康检查机制
|
||
> - ✅ B：正确。大多数生产环境故障源于此，开启 Keepalive 是稳定性标配
|
||
> - ❌ C：Keepalive 增加的是很小的 ping 帧，不影响业务数据的吞吐
|
||
> - ❌ D：负载均衡切换由 picker 和 health check 驱动，和 Keepalive 无关
|
||
>
|
||
> 💡 **额外收获：** `MaxConnectionAge` 配合 Keepalive 使用可以实现平滑退役——让旧连接到期失效，新流量走新连接。
|
||
|
||
---
|
||
|
||
### Q9.【OpenTelemetry 上下文传播】
|
||
|
||
通过 `otelgrpc` 中间件实现分布式追踪时，gRPC 上下文中 trace context 的传播方式是：
|
||
|
||
A. 通过 `context.Value` 传递，不需要序列化
|
||
B. 自动注入 W3C Trace Context 到 HTTP/2 metadata 中
|
||
C. 需要在每个 handler 中手动传递 `traceparent` header
|
||
D. 通过 gRPC 的 payload 字段携带 trace ID
|
||
|
||
> [!tip]- Q9 答案
|
||
> **B — otelgrpc 自动注入 TraceContext 到 metadata**
|
||
>
|
||
> **解析：**
|
||
> gRPC 使用 HTTP/2 metadata 作为键值对的元数据通道。`otelgrpc` 中间件会在每次 RPC 调用时自动：
|
||
> 1. 读取上游传入的 `traceparent`/`tracestate` metadata
|
||
> 2. 从中提取 Span Context 并创建新的 Span
|
||
> 3. 在新的出向调用中自动注入新的 TraceContext 到 metadata
|
||
>
|
||
> ```go
|
||
> // 服务端——自动从 incoming metadata 中提取并继承 trace context
|
||
> server := grpc.NewServer(
|
||
> grpc.StatsHandler(otelgrpc.NewServerStatsHandler()),
|
||
> )
|
||
>
|
||
> // 客户端——自动把 span context 注入 outgoing metadata
|
||
> conn, _ := grpc.Dial(target,
|
||
> grpc.WithStatsHandler(otelgrpc.NewClientStatsHandler()),
|
||
> )
|
||
> ```
|
||
>
|
||
> **为什么不手动传：** 手动维护 metadata 繁琐且易遗漏。一旦漏传了一跳，整个链路就在这一跳断开了，Jaeger/Grafana 上看不到完整链路图。
|
||
>
|
||
> 💡 **W3C Trace Context 格式：** `Traceparent: 00-trace_id-span_id-flags`，是一个行业通用的标准，不仅适用于 gRPC，HTTP 请求也是同样的传播方式。
|
||
|
||
---
|
||
|
||
### Q10.【Buf 工具链】
|
||
|
||
关于 Buf 代码生成工具链的作用，以下描述**最全面**的是：
|
||
|
||
A. Buf 替代 protoc 生成 Go 代码，但不支持 JavaScript
|
||
B. `buf.lock` 锁定 proto 依赖的确切 commit，类似 go.mod 锁定 Go 模块版本
|
||
C. Buf 只能在 CI 中使用，不能在本地开发环境中运行
|
||
D. Buf 只能生成 gRPC 桩代码，不能处理自定义 validator
|
||
|
||
> [!tip]- Q10 答案
|
||
> **B — buf.lock 锁定依赖版本，保证构建可重现**
|
||
>
|
||
> **解析：**
|
||
> Buf 是 Protocol Buffers 的现代工具链，提供统一依赖管理、linting 和 CI 集成。
|
||
>
|
||
> **逐项分析：**
|
||
> - ❌ A：Buf 支持多种语言插件（Go、TS/JS、Python 等），不限于 Go
|
||
> - ✅ B：正确。像 `go mod tidy` 锁定 go.sum，`buf dep update` 生成 `buf.lock`，CI 中加入 `git diff --exit-code` 检查可以防止生成的代码过期
|
||
> - ❌ C：Buf 可以在本地运行 `buf generate` 生成代码，也可以和 `buf watch` 配合实现热更新
|
||
> - ❌ D：Buf 支持 `validate.proto` 插件，可以为 message 字段添加校验规则并自动生成校验代码
|
||
>
|
||
> ```yaml
|
||
> # buf.gen.yaml
|
||
> plugins:
|
||
> - remote: buf.build/protocolbuffers/go # 生成 Go struct
|
||
> - remote: buf.build/grpc/go # 生成 gRPC stub
|
||
> - remote: buf.build/bufbuild/validate-go # 生成校验逻辑
|
||
> ```
|
||
>
|
||
> 💡 **CI 集成模式：**
|
||
> ```bash
|
||
> buf generate # 生成代码
|
||
> buf mod update # 更新 lock
|
||
> git diff --exit-code # 如果生成的代码不一致说明 lock 过期了
|
||
> ```
|
||
|
||
---
|
||
|
||
## 二、填空题（每题 3 分，共 24 分）
|
||
|
||
> 根据知识填写空缺的概念或代码。
|
||
|
||
### Q11.【gRPC 协议栈层次】
|
||
|
||
请按照从上到下的顺序排列 gRPC 的协议栈层级：
|
||
|
||
___（Application）→ Generated Stub → ___ → HTTP/2 → ___
|
||
|
||
> [!tip]- Q11 答案
|
||
> **gRPC Framework** ； **TCP/IP**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 层级 | 解决的问题 | 类比 |
|
||
> |------|-----------|------|
|
||
> | Application | 业务逻辑 | 写信的内容 |
|
||
> | Generated Stub | Proto 对象映射为二进制编码 | 翻译官（Proto = 字典） |
|
||
> | gRPC Framework | 重试、拦截器、流控 | 邮局分拣系统 |
|
||
> | HTTP/2 | 多路复用 + 头部压缩 + 二进制帧 | 快递包裹分装规范 |
|
||
> | TCP/IP | 可靠传输 + 路由寻址 | 公路运输网络 |
|
||
>
|
||
> 💡 **调试视角：** 排查问题时定位在哪一层很重要——超时通常是 HTTP/2/Transport 层，序列化问题是 Stub 层，业务逻辑 Bug 在 Application 层。
|
||
|
||
---
|
||
|
||
### Q12.【Proto 命名约定】
|
||
|
||
Proto 文件的组织规范中：package 使用 __________ 风格（如 `order.v1`）；service 使用 PascalCase + __________ 后缀；enum 使用 PascalCase + Status 或 Type 后缀；message 中的 field 使用 __________ 风格（如 `user_id`）。
|
||
|
||
> [!tip]- Q12 答案
|
||
> **小写点分隔** ； **Service** ； **snake_case**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 元素 | 命名风格 | 示例 |
|
||
> |------|---------|------|
|
||
> | package | 小写点分隔，含版本前缀 | `order.v1` |
|
||
> | service | PascalCase + Service | `OrderService` |
|
||
> | rpc method | PascalCase | `CreateOrder`, `GetUserInfo` |
|
||
> | message | PascalCase | `CreateOrderRequest` |
|
||
> | enum | PascalCase + Status/Type | `OrderStatus`, `RoleType` |
|
||
> | field | snake_case | `user_id`, `created_at` |
|
||
>
|
||
> 💡 **为什么 field 用 snake_case：** Proto3 的代码生成器会自动将 `snake_case` field 名转换为目标语言的驼峰命名（Go 转驼峰、Java 也转驼峰），这样在不同语言间保持一致性。
|
||
|
||
---
|
||
|
||
### Q13.【状态码分类速记】
|
||
|
||
gRPC 定义了 16 个标准状态码，按业务含义可分为三类：
|
||
|
||
| 业务场景 | 推荐状态码 |
|
||
|---------|-----------|
|
||
| 参数校验失败 | _(空1)_ |
|
||
| 权限不足 | _(空2)_ |
|
||
| 服务不可用（连接断开） | _(空3)_ |
|
||
| 限流 | _(空4)_ |
|
||
|
||
> [!tip]- Q13 答案
|
||
> **(空1) InvalidArgument** ； **(空2) PermissionDenied** ； **(空3) Unavailable** ； **(空4) ResourceExhausted**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 状态码 | 等价 HTTP | 典型场景 |
|
||
> |--------|----------|---------|
|
||
> | `InvalidArgument` | 400 | 参数格式不对、必填项缺失 |
|
||
> | `PermissionDenied` | 403 | Token 无效但已提供 |
|
||
> | `Unavailable` | 503 | 下游宕机、连接断开、过载 |
|
||
> | `ResourceExhausted` | 429 | 限流、配额用完 |
|
||
>
|
||
> **记忆口诀：** "参数不正（InvalidArgument）、权限不够（PermissionDenied）、服务不稳（Unavailable）、资源耗尽（ResourceExhausted）"。
|
||
>
|
||
> 💡 **客户端侧策略：** `InvalidArgument` 不应该重试（改了也没用），`Unavailable` 可以重试（可能临时抖动），`ResourceExhausted` 需要退避（限流正在生效）。
|
||
|
||
---
|
||
|
||
### Q14.【拦截器执行顺序】
|
||
|
||
在一个完整的 gRPC 请求链中，典型的拦截器执行顺序如下：
|
||
|
||
```
|
||
客户端开始
|
||
→ Metrics（记录耗时）
|
||
→ Retry（根据错误码决定是否重试）
|
||
→ Auth（注入 Token）
|
||
↕ HTTP/2 传输
|
||
→ Auth（验证 Token）
|
||
→ Logging（记录请求/响应）
|
||
→ Metrics（统计服务端耗时）
|
||
→ Handler（业务逻辑）
|
||
→ _________（后置：服务端 metrics 记录）
|
||
→ _________（后置：服务端日志记录）
|
||
→ _________（后置：服务端 auth 释放资源）
|
||
客户端结束
|
||
```
|
||
|
||
> [!tip]- Q14 答案
|
||
> **Metrics** ； **Logging** ； **Auth**
|
||
>
|
||
> **解析：**
|
||
> 拦截器的执行遵循**洋葱模型**：前置部分正序执行（靠近 handler 的内层先启动），后置部分逆序执行（内层先返回再逐层退出）。
|
||
>
|
||
> ```
|
||
> 正向：[Metrics] → [Retry] → [Auth] → Handler
|
||
> ↑ ↑
|
||
> 逆向： [Auth释放] ← [Logging后置] ← [Metrics后置]
|
||
> ```
|
||
>
|
||
> 注意这里的"后置"顺序和前序相反，就像进出电梯——进来的时候按楼层排好队，出去的时候最后一个先进的人反而最早出来。
|
||
>
|
||
> 💡 **Debug 技巧：** 如果你在每个拦截器的进入和退出处打印时间戳，可以看到典型的"进出栈"模式——这正是中间件链的本质。
|
||
|
||
---
|
||
|
||
### Q15.【Well-Known Types 用法】
|
||
|
||
Proto3 内置了 Well-Known Types，以下是三个常用类型的用途：
|
||
|
||
| Well-Known Type | 用途 |
|
||
|----------------|------|
|
||
| `google.protobuf.Timestamp` | _(空1)_ |
|
||
| `google.protobuf.Empty` | _(空2)_ |
|
||
| `google.protobuf.StringValue` | _(空3)_ |
|
||
|
||
> [!tip]- Q15 答案
|
||
> **(空1) RFC 3339 纳秒级时间戳**；**(空2) 无参数/无返回值的 RPC 占位**；**(空3) 包装基本类型表示"可选"语义（区分 unset 和空串）**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> Proto3 没有 Optional 关键字，这意味着当你声明 `string name = 1;` 时，你无法区分"用户传了空串"和"用户根本没传这个字段"。
|
||
>
|
||
> `StringValue` 等 Wrapper 类型解决了这个问题：
|
||
> ```proto
|
||
> string normal_field = 1; // "" 无法区分 unset 还是传了空串
|
||
> StringValue optional_field = 2; // nil = 未传, Some("") = 传了空串
|
||
> ```
|
||
>
|
||
> **各类型速览：**
|
||
>
|
||
> | Type | 包装的基本类型 | 什么时候用到 |
|
||
> |------|-------------|------------|
|
||
> | `Timestamp` | 时间 | 替代手动拼字符串 |
|
||
> | `Duration` | 时长 | 替代 float/double |
|
||
> | `Empty` | 无 | Oneof RPC 返回类型（无返回参数） |
|
||
> | `StringValue/Int32Value/BoolValue` | 对应的基元类型 | 需要区分 null/empty/实际值 |
|
||
> | `Any` | 任意消息 | 泛型容器，需搭配 type URL |
|
||
>
|
||
> 💡 **工程经验：** 如果一个字段未来可能会被废弃，先用 `reserved` 锁定编号而不是直接删除。
|
||
|
||
---
|
||
|
||
### Q16.【负载均衡策略选择】
|
||
|
||
gRPC 内建的几种负载均衡策略各有适用场景：
|
||
|
||
| 策略 | 行为特点 | 适用场景 |
|
||
|------|---------|---------|
|
||
| pick_first（默认） | 每次只用一个 SubConn | _(空1)_ |
|
||
| round_robin | _(空2)_ | 无状态服务、均匀负载 |
|
||
| hash-based | 按 key hash 选定后端 | _(空3)_ |
|
||
|
||
> [!tip]- Q16 答案
|
||
> **(空1) 单一后端或简单场景**；**(空2) 轮询分发到新连接**；**(空3) 需要会话粘性的场景**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 策略 | 风险 | 建议 |
|
||
> |------|------|------|
|
||
> | pick_first | 单点故障——该连接对应的后端挂了要等 health check 失败才切 | 高可用场景切换到 round_robin |
|
||
> | round_robin | 不适用于后端规格不一致的情况 | 集群所有实例同规格时使用 |
|
||
> | weighted_round_robin | Go 1.25+ 才支持 | 混合部署（新机器+旧机器） |
|
||
> | hash-based | hash 变化会导致粘性失效 | 需要持久化用户关联时使用 |
|
||
>
|
||
> ```go
|
||
> // 指定 round_robin
|
||
> conn, _ := grpc.Dial(
|
||
> "dns:///orderservice:9000",
|
||
> grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[{"round_robin":{}}]}`),
|
||
> )
|
||
> ```
|
||
>
|
||
> 💡 **pick_first 的隐患：** 如果你的服务有多个实例，但用了默认的 pick_first，gRPC 只会连接到其中一个实例——其余实例完全收不到请求。这不是 bug，是设计如此，但很多人上线时忘了改。
|
||
|
||
---
|
||
|
||
### Q17.【重试与安全边界】
|
||
|
||
gRPC 客户端配置自动重试时，有以下三条安全红线：
|
||
|
||
1. 仅 __________ 操作（GET、DELETE）可以安全重试
|
||
2. POST/create 操作重试可能产生 __________，必须在业务层加幂等键
|
||
3. 重试会增加 __________，特别是涉及 DB 的场景
|
||
|
||
> [!tip]- Q17 答案
|
||
> **幂等** ； **重复数据** ； **读放大**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 操作类型 | 可重试？ | 原因 |
|
||
> |---------|---------|------|
|
||
> | Query / Get | ✅ | 本身幂等，查十次结果一样 |
|
||
> | Update / Patch | ⚠️ 有条件 | DB 层加乐观锁或唯一索引 |
|
||
> | Create / Insert | ❌ 谨慎 | 可能重复插入，必须有幂等键机制 |
|
||
> | Delete | ✅ | 幂等操作 |
|
||
>
|
||
> ```json
|
||
> {
|
||
> "retryPolicy": {
|
||
> "maxAttempts": 3,
|
||
> "initialBackoff": "0.1s",
|
||
> "maxBackoff": "1s",
|
||
> "backoffMultiplier": 2,
|
||
> "retryableStatusCodes": ["UNAVAILABLE", "DEADLINE_EXCEEDED"]
|
||
> }
|
||
> }
|
||
> ```
|
||
>
|
||
> 💡 **重要提示：** `retryableStatusCodes` 必须精确——不是所有错误都能重试。`INTERNAL`、`InvalidArgument` 重试没有意义，反而浪费资源。通常只重试瞬态错误（`Unavailable`、`DeadlineExceeded`）。
|
||
|
||
---
|
||
|
||
### Q18.【Dial 配置选项】
|
||
|
||
gRPC 客户端 Dial 时的关键配置项：
|
||
|
||
| 配置项 | 默认值 | 建议值 | 方向 |
|
||
|--------|--------|--------|------|
|
||
| MaxCallRecvMsgSize | ___ | 10MB | 客户端 |
|
||
| InitialWindowSize | 64KB | 1MB（高吞吐） | 连接级 |
|
||
| BackoffBaseDelay | 100ms | 100ms | 重连 |
|
||
|
||
> [!tip]- Q18 答案
|
||
> **4MB**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> gRPC 默认的最大收/发包大小都是 4MB。对于大多数 CRUD 操作绰绰有余，但如果你的业务涉及大文件元数据或批量查询返回大量记录，会遇到如下错误：
|
||
>
|
||
> ```
|
||
> grpc: received message larger than max (12345678 vs 4194304)
|
||
> ```
|
||
>
|
||
> **解决方式：**
|
||
> ```go
|
||
> grpc.MaxCallRecvMsgSize(10 << 20), // 10 MB
|
||
> grpc.MaxCallSendMsgSize(10 << 20), // 10 MB
|
||
> ```
|
||
>
|
||
> **⚠️ 风险提示：** 设得太大会消耗大量内存。建议配合分块传输（Client Streaming）使用，避免一次性拉取过大数据。
|
||
>
|
||
> 💡 **Initial Window Size：** 默认 64KB 在高吞吐场景会成为瓶颈。调大到 1MB 后可以显著减少 flow control 导致的停顿。
|
||
|
||
---
|
||
|
||
## 三、代码补全（每题 6 分，共 30 分）
|
||
|
||
> 补充代码中空缺的部分。有些题目有多个空。
|
||
|
||
### Q19.【优雅降级——按状态码处理错误】
|
||
|
||
```go
|
||
resp, err := client.GetUser(ctx, &pb.GetUserRequest{Id: userId})
|
||
if err != nil {
|
||
switch status.Code(err) {
|
||
case codes.NotFound:
|
||
// 用户不存在 → 降级：返回默认值
|
||
return defaultUser, nil
|
||
case codes.Unavailable:
|
||
// 下游挂了 → 降级：尝试从缓存加载
|
||
return fallbackFromCache(ctx, userId)
|
||
case codes.DeadlineExceeded:
|
||
// 超时 → 降级：返回友好提示
|
||
return cachedUser, nil
|
||
_________:
|
||
// 其他错误 → 直接返回
|
||
return nil, err
|
||
}
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q19 答案
|
||
> **`default`**
|
||
>
|
||
> **解析：**
|
||
> 这是 gRPC 客户端优雅降级的经典模式：**根据状态码选择不同的恢复策略**，而不是所有错误一律重试或一律上报。
|
||
>
|
||
> | 状态码 | 策略 | 原因 |
|
||
> |--------|------|------|
|
||
> | `NotFound` | 返回默认值 | 不是系统问题，重试也无济于事 |
|
||
> | `Unavailable` | 缓存降级 | 下游暂时不可用，尝试兜底 |
|
||
> | `DeadlineExceeded` | 缓存兜底 | 网络抖动的临时现象 |
|
||
> | `default` | 透传错误 | 其他错误应该暴露给上层处理 |
|
||
>
|
||
> **关键点：** `status.Code()` 会从错误中提取 gRPC status code，不受 `fmt.Errorf` 包装的影响。这是正确使用 gRPC 错误处理的基础。
|
||
>
|
||
> ```go
|
||
> // 别忘了先 import "google.golang.org/grpc/status"
|
||
> import "google.golang.org/grpc/status"
|
||
> ```
|
||
>
|
||
> 💡 **防御编程思想：** 不要把所有错误归为一类处理——每种错误码代表了不同类型的故障，针对性的恢复策略远比"一刀切"效果好。
|
||
|
||
---
|
||
|
||
### Q20.【拦截器——鉴权中间件】
|
||
|
||
补全一个 gRPC 服务端鉴权拦截器：
|
||
|
||
```go
|
||
func AuthInterceptor() grpc.UnaryServerInterceptor {
|
||
return func(ctx context.Context, req any,
|
||
info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
|
||
|
||
// 白名单：健康检查和反射服务跳过鉴权
|
||
skipPaths := []string{"/health.Health/Check"}
|
||
for _, p := range skipPaths {
|
||
if info.FullMethod == p {
|
||
_________ // 空1：放行到下一个拦截器/handler
|
||
}
|
||
}
|
||
|
||
// 从 incoming context 中提取 metadata
|
||
md, ok := metadata.FromIncomingContext(ctx)
|
||
if !ok {
|
||
return nil, status.Error(codes.Unauthenticated, "missing metadata")
|
||
}
|
||
|
||
tokens := md.Get("authorization")
|
||
if len(tokens) == 0 || !validateToken(tokens[0]) {
|
||
return nil, status.Error(codes.Unauthenticated, "invalid token")
|
||
}
|
||
|
||
// 提取 userID 并注入 context（传递给下游 handler）
|
||
userCtx := context.WithValue(ctx, "userID", extractUserID(tokens[0]))
|
||
_________ // 空2：带着 userID 进入 handler
|
||
}
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q20 答案
|
||
> **空1：** `return handler(ctx, req)` ； **空2：** `return handler(userCtx, req)`
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 空 | 填空 | 作用 |
|
||
> |----|------|------|
|
||
> | 空1 | `return handler(ctx, req)` | 白名单路径不鉴权，直接进入 handler |
|
||
> | 空2 | `return handler(userCtx, req)` | 鉴权通过后将增强后的 context 传给 handler |
|
||
>
|
||
> **完整流程：**
|
||
> ```
|
||
> 请求进来 → AuthInterceptor 检查 path
|
||
> → skip? → handler(ctx, req) [直接放行]
|
||
> → not skip? → 从 metadata 取 token
|
||
> → invalid? → status.Error(Unauthenticated)
|
||
> → valid? → handler(userCtx, req) [带 userID 进入]
|
||
> ```
|
||
>
|
||
> **关键细节：**
|
||
> - 白名单路径非常必要——健康检查 `/health.Health/Check` 和 gRPC reflection 不需要鉴权
|
||
> - `info.FullMethod` 的格式是 `/package.Service/Method`，例如 `/order.v1.OrderService/CreateOrder`
|
||
> - 将用户信息放入 context 而非 global variable，保证并发安全
|
||
>
|
||
> 💡 **进阶：** 生产环境通常会用一个专门的 `middleware` package 集中管理所有 interceptor，并通过配置文件决定哪些接口需要鉴权、哪些走白名单。
|
||
|
||
---
|
||
|
||
### Q21.【客户端流式——批量上传】
|
||
|
||
补全一个客户端流式 RPC，用于批量上传日志：
|
||
|
||
```go
|
||
func (s *logServer) UploadLogs(stream pb.LogService_UploadLogsServer) error {
|
||
var count int32
|
||
for {
|
||
log, err := stream.Recv()
|
||
if err == io.EOF {
|
||
_________ // 空1：正常结束循环
|
||
}
|
||
if err != nil {
|
||
return err
|
||
}
|
||
s.store.Save(log.Message)
|
||
_________ // 空2：计数
|
||
}
|
||
return stream.SendAndClose(&pb.UploadResult{Count: _________}) // 空3
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q21 答案
|
||
> **空1：** `break` ； **空2：** `count++` ； **空3：** `count`
|
||
>
|
||
> **解析：**
|
||
>
|
||
> 客户端流式的模式固定：**for 循环 + Recv() + EOF 判断**：
|
||
>
|
||
> ```go
|
||
> for {
|
||
> item, err := stream.Recv()
|
||
> if err == io.EOF {
|
||
> break // 客户端调用了 CloseSend()，对流发送端关闭
|
||
> }
|
||
> if err != nil {
|
||
> return err // 非 EOF 的错误直接返回
|
||
> }
|
||
> // 处理业务...
|
||
> }
|
||
> return stream.SendAndClose(&result) // 最后一次性返回结果
|
||
> ```
|
||
>
|
||
> | 空 | 填空 | 说明 |
|
||
> |----|------|------|
|
||
> | 空1 | `break` | Recv() 返回 EOF 表示发送端关闭，退出循环 |
|
||
> | 空2 | `count++` | 累加已处理的日志条数 |
|
||
> | 空3 | `count` | 聚合结果作为最终响应返回 |
|
||
>
|
||
> 💡 **客户端写法：** 客户端需要用 `CloseSend()` 通知服务端"我不再发了"：
|
||
> ```go
|
||
> stream, _ := client.UploadLogs(ctx)
|
||
> for _, log := range logs {
|
||
> stream.Send(&pb.LogEntry{Message: log})
|
||
> }
|
||
> result, err := stream.CloseSend() // CloseSend 同时返回最终响应
|
||
> ```
|
||
|
||
---
|
||
|
||
### Q22.【OKTEL 自动注入 StatsHandler】
|
||
|
||
补全 OpenTelemetry gRPC 集成配置：
|
||
|
||
```go
|
||
import "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
|
||
|
||
func main() {
|
||
// 服务端
|
||
server := grpc.NewServer(
|
||
_________ // 空1：注册服务端 stats handler
|
||
)
|
||
|
||
// 客户端
|
||
conn, _ := grpc.Dial(target,
|
||
_________ // 空2：注册客户端 stats handler
|
||
)
|
||
defer conn.Close()
|
||
|
||
client := pb.NewOrderServiceClient(conn)
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q22 答案
|
||
> **空1：** `grpc.StatsHandler(otelgrpc.NewServerStatsHandler())` ； **空2：** `grpc.WithStatsHandler(otelgrpc.NewClientStatsHandler())`
|
||
>
|
||
> **解析：**
|
||
>
|
||
> otelgrpc 通过 gRPC 的 `StatsHandler` 接口实现自动埋点：
|
||
>
|
||
> - **服务端** `NewServerStatsHandler()`：自动在入向请求时创建 Span、提取上游 trace context
|
||
> - **客户端** `NewClientStatsHandler()`：自动在出向请求时创建 Span、注入 trace context 到 metadata
|
||
>
|
||
> ```
|
||
> 请求流向：
|
||
> ClientSpan.Start() → otelgrpc.ClientStatsHandler.InjectTraceContext → metadata
|
||
> ↓ HTTP/2
|
||
> otelgrpc.ServerStatsHandler.ExtractTraceContext → ServerSpan.Start()
|
||
> ```
|
||
>
|
||
> | 空 | 填空 | 要点 |
|
||
> |----|------|------|
|
||
> | 空1 | `grpc.StatsHandler(otelgrpc.NewServerStatsHandler())` | 注意是 `grpc.StatsHandler()` 不是 `grpc.UnaryInterceptor()` |
|
||
> | 空2 | `grpc.WithStatsHandler(otelgrpc.NewClientStatsHandler())` | 客户端用 `WithStatsHandler` 选项 |
|
||
>
|
||
> 💡 **statsHandler vs Interceptor：** StatsHandler 负责指标采集和链路追踪，Interceptor 负责业务横切逻辑（鉴权、日志、重试）。两者互补，各司其职。
|
||
|
||
---
|
||
|
||
### Q23.【重试策略配置】
|
||
|
||
补全 gRPC 客户端重试服务的 JSON 配置：
|
||
|
||
```go
|
||
retryPolicy := `{
|
||
"retryPolicy": {
|
||
"maxAttempts": ___ , // 空1：最大重试次数（含首次）
|
||
"initialBackoff": "___" , // 空2：初始退避时间
|
||
"maxBackoff": "___" , // 空3：最大退避时间
|
||
"backoffMultiplier": ___ , // 空4：退避倍率
|
||
"retryableStatusCodes": ["___", "___"] // 空5~6：可重试的状态码
|
||
}
|
||
}`
|
||
```
|
||
|
||
> [!tip]- Q23 答案
|
||
> **空1：** `3` ； **空2：** `0.1s`（或合理值如 `100ms`）； **空3：** `1s`（或合理值）； **空4：** `2` ； **空5：** `UNAVAILABLE` ； **空6：** `DEADLINE_EXCEEDED`
|
||
>
|
||
> **解析：**
|
||
>
|
||
> **指数退避计算公式：** `wait = min(initialBackoff × backoffMultiplier^n, maxBackoff)`
|
||
>
|
||
> | 第几次 | 计算 | 实际等待 |
|
||
> |--------|------|---------|
|
||
> | 第1次（首次） | — | 立即 |
|
||
> | 第2次（重试1） | 0.1s × 2^0 = 0.1s | 100ms |
|
||
> | 第3次（重试2） | 0.1s × 2^1 = 0.2s | 200ms |
|
||
> | （理论第4次） | 0.1s × 2^2 = 0.4s → capped at 1s | ≤ 1s |
|
||
>
|
||
> | 空 | 填空 | 说明 |
|
||
> | |----|------|------|
|
||
> | 空1 | `3` | maxAttempts 包含首次调用，总共尝试 3 次 |
|
||
> | 空2 | `0.1s` | 第一次重试的等待基数，太短打满服务器，太长影响体验 |
|
||
> | 空3 | `1s` | 上限防止无限等待 |
|
||
> | 空4 | `2` | 每次退避时间翻倍 |
|
||
> | 空5 | `UNAVAILABLE` | 下游不可用（连接断开、过载），通常可恢复 |
|
||
> | 空6 | `DEADLINE_EXCEEDED` | 超时也可能是暂时的（GC pause、网络抖动） |
|
||
>
|
||
> 💡 **为什么要限制 retryableStatusCodes：** 很多开发者把所有错误都设为可重试，这会导致重试风暴——下游本来就挂了，你还拼命重试。只重试**瞬态错误**，不重试**确定性错误**（InvalidArgument、PermissionDenied 等）。
|
||
|
||
---
|
||
|
||
## 四、主观题（每题 4 分，共 16 分）
|
||
|
||
> 简要回答即可，不需要长篇大论。关键是说出你的理解。
|
||
|
||
### Q24.【Proto 版本演进策略】
|
||
|
||
你的 `.proto` 文件中有一个 message 定义了 20 个字段，已经被多个服务引用。半年后你想在这个 message 中添加第 21 个字段，但在添加之前你要删除第 10 个字段（已废弃）。请说明正确的操作步骤，以及如果操作不当（比如直接删除编号并重用）会带来什么后果。
|
||
|
||
> [!tip]- Q24 参考答案
|
||
>
|
||
> **正确步骤：**
|
||
> 1. 在 message 中加上 `reserved <旧的编号>;` 锁定已删除字段的编号
|
||
> 2. 如果有对应的字段名也想一起删除，一并写上 `reserved "old_field_name";`
|
||
> 3. 新增字段使用更大的编号（如 21），不要使用已 reserved 的编号
|
||
> 4. 旧客户端收到包含新编号字段的数据时会忽略它（向后兼容）
|
||
> 5. 新客户端收到旧服务端响应时，新字段会使用默认值（向前兼容）
|
||
>
|
||
> ```proto
|
||
> message User {
|
||
> reserved 10; // 锁定已删除编号
|
||
> reserved "deprecated_email"; // 锁定已删除字段名
|
||
>
|
||
> string name = 1;
|
||
> int32 age = 2;
|
||
> // ... 其他字段
|
||
> string new_field = 21; // 新增字段
|
||
> }
|
||
> ```
|
||
>
|
||
> **错误操作的后果：** 如果把原来编号 10 的字段删掉后，又新建一个字段也用编号 10：
|
||
> - 旧客户端把新字段的数据解析成了已废弃的旧字段类型 → **静默数据损坏**
|
||
> - 新旧客户端语义错位，bug 排查极其困难
|
||
> - 这种问题在编译期不会报错，运行时也不会 panic，属于"最危险的兼容性问题"
|
||
>
|
||
> 💡 **核心认知：** Proto 编号是合约的一部分。编号一旦分配就不再收回，这是 protobuf 向前兼容的设计哲学。
|
||
|
||
---
|
||
|
||
### Q25.【Keepalive 与 MaxConnectionAge 的组合】
|
||
|
||
在生产环境中部署了一个有 5 个后端的 gRPC 服务。你需要进行滚动升级：逐个替换后端实例为新版本。请问应该如何配置 Keepalive 相关参数来确保升级过程平滑？具体说明 `MaxConnectionAge` 的作用和它与 Keepalive Time 的区别。
|
||
|
||
> [!tip]- Q25 参考答案
|
||
>
|
||
> **平滑升级策略：**
|
||
>
|
||
> 1. **开启 Keepalive**：`Time = 10~30s`，防止中间代理在空闲时切断连接
|
||
> 2. **设置 MaxConnectionAge**：比如 `MaxConnectionAge = 5min`，让连接最大存活时间为 5 分钟
|
||
> 3. 当一个后端实例准备升级时，等待该实例上的旧连接自然到期（最多 5 分钟后）
|
||
> 4. 客户端检测到连接关闭后自动创建新连接，指向新的后端实例
|
||
> 5. 完成升级后再处理下一个实例
|
||
>
|
||
> **MaxConnectionAge vs Keepalive Time 的区别：**
|
||
>
|
||
> | 参数 | 作用 | 类比 |
|
||
> |------|------|------|
|
||
> | Keepalive Time | 保活 ping 间隔——防止代理切断空闲连接 | 定期跟朋友打个招呼："你还在吗？" |
|
||
> | MaxConnectionAge | 连接最大寿命——强制旧连接到期换新 | 合同到期不再续签，换一家供应商 |
|
||
>
|
||
> 两者目的不同：Keepalive 是为了**维持**连接不被外部杀死；MaxConnectionAge 是为了**主动销毁**旧连接实现无缝迁移。
|
||
>
|
||
> 💡 **注意事项：** MaxConnectionAge 是服务端控制的，客户端无权修改。如果客户端不支持动态感知连接关闭，需要配合 health check 一起使用。
|
||
|
||
---
|
||
|
||
### Q26.【何时选择 gRPC 而非 HTTP/JSON】
|
||
|
||
gRPC 有很多优势（类型安全、代码即 SDK、流式能力），但也并非万能。请列举至少三个 gRPC **不适用**的场景，并说明在这些场景中为什么 HTTP/JSON（REST）仍然是更好的选择。
|
||
|
||
> [!tip]- Q26 参考答案
|
||
>
|
||
> **gRPC 不适用的场景：**
|
||
>
|
||
> 1. **对外暴露公开 API**——第三方接入者不想安装 Protocol Buffer 编译器，浏览器也不能直接调用 gRPC（没有 HTTP/2 原生支持）。HTTP/JSON 通过 `fetch()` 即可调用，生态成熟。
|
||
>
|
||
> 2. **需要浏览器直接交互的前端页面**——虽然 HTTP/2 已在现代浏览器普及，但浏览器的 Fetch API 不支持 gRPC 的 proto 定义格式。如需全双工通信，WebSocket + JSON 仍是首选。
|
||
>
|
||
> 3. **简单的单体应用内部通信**——如果应用只有一两个服务、QPS 不高，引入 gRPC 增加了 proto 编译、代码生成的复杂度，收益不明显。HTTP/JSON 足以应付。
|
||
>
|
||
> 4. **搜索引擎爬虫抓取内容**——Google/Bing 的爬虫只支持 HTTP/HTML，不可能去编译 proto 文件然后发起 gRPC 请求。
|
||
>
|
||
> 5. **遗留系统集成**——如果老系统只支持 SOAP/XML，引入 gRPC 需要做桥接转换，不如直接在原系统上加一层 HTTP API 网关。
|
||
>
|
||
> **总结：** gRPC 的定位是**微服务之间的内部通信**——强类型、全团队统一 proto、高性能需求。边界清晰，不要把锤子当钉子用。
|
||
>
|
||
> 💡 **混合部署模式：** 实际项目中经常是"对内 gRPC + 对外 REST"的双栈模式——内部服务用 gRPC 高效通信，API Gateway 层把 gRPC 转换为 HTTP/JSON 暴露给外部。
|
||
|
||
---
|
||
|
||
### Q27.【流式调用的错误处理特殊性】
|
||
|
||
普通 Unary RPC 可以通过 `err != nil` 判断调用是否成功。但对于 Server Streaming 和 Client Streaming 等流式调用，错误发生在 `Recv()` 或 `Send()` 的迭代过程中。请解释流式调用中错误处理的特殊性，并给出一个正确处理 Server Streaming 错误的代码示例。
|
||
|
||
> [!tip]- Q27 参考答案
|
||
>
|
||
> **特殊性：** 流式调用的错误不是一次性的返回值，而是在遍历流的过程中逐步产生的。`Recv()` 可能在接收到最后一个有效消息之前就返回错误。
|
||
>
|
||
> **处理流程：**
|
||
> ```go
|
||
> stream, err := client.ListOrders(ctx, req)
|
||
> if err != nil {
|
||
> // 调用建立阶段就失败了
|
||
> return nil, err
|
||
> }
|
||
>
|
||
> for {
|
||
> order, err := stream.Recv()
|
||
> if err == io.EOF {
|
||
> // 正常结束：服务端发完了所有消息
|
||
> break
|
||
> }
|
||
> if err != nil {
|
||
> // 流中间出错：可能是网络断开、服务端 panic、deadline 到了
|
||
> // status.Code(err) 可以判断具体的错误类型
|
||
> log.Errorf("stream recv error: %v", err)
|
||
> return nil, err
|
||
> }
|
||
> // 处理正常消息
|
||
> process(order)
|
||
> }
|
||
> ```
|
||
>
|
||
> **关键点：**
|
||
> 1. **EOF ≠ 错误**：`io.EOF` 表示服务端正常关闭了发送端，是预期行为
|
||
> 2. **需要先判断 EOF**：因为 `Recv()` 在 EOF 时也返回 `err != nil`，必须先判断 `err == io.EOF`
|
||
> 3. **状态码解析**：流中间的错误需要通过 `status.Code(err)` 判断具体是什么故障
|
||
> 4. **服务端也必须主动关闭**：服务端如果忘记 return nil 或 return error，客户端会永远阻塞在 Recv()
|
||
>
|
||
> **Client Streaming 同理：**
|
||
> ```go
|
||
> stream, _ := client.UploadLogs(ctx)
|
||
> for _, log := range logs {
|
||
> if err := stream.Send(&pb.LogEntry{Message: log}); err != nil {
|
||
> return err // Send 期间出错也要处理
|
||
> }
|
||
> }
|
||
> result, err := stream.CloseAndRecv()
|
||
> return result, err
|
||
> ```
|
||
>
|
||
> 💡 **核心认知：** 流式错误处理的关键是"区分正常结束和异常结束"——EOF 是好的结束，其他 err 是不好的结束。这个判断顺序不能颠倒。
|
||
|
||
---
|
||
|
||
## 评分参考
|
||
|
||
| 题目类型 | 满分 | 权重 |
|
||
|---------|------|------|
|
||
| 选择题（Q1-Q10） | 40 分 | 40% |
|
||
| 填空题（Q11-Q18） | 24 分 | 24% |
|
||
| 代码补全（Q19-Q23） | 30 分 | 30% |
|
||
| 主观题（Q24-Q27） | 16 分 | 16% |
|
||
| **总计** | **100 分** | **100%** |
|
||
|
||
**及格线：** ≥70 分
|
||
**优秀线：** ≥85 分
|