Go 微服务面试题集：从八个问题收口

属于 S4 Go 微服务 · 收口篇 上一篇：治理与稳定性

微服务的高频问题，每题练到连续追问三层。

Q1：gRPC 为什么比 HTTP/JSON 快？

Protobuf 二进制编码（小、快）+ HTTP/2 多路复用 + 头部压缩。

追问：多路复用解决什么？ HTTP/1.1 的队头阻塞（一个连接同时只能处理一个请求）。

Q2：微服务怎么拆分？

按业务领域边界，高内聚低耦合，每服务独立数据库。拆分过细的代价是分布式事务、调用链长、运维复杂。

追问：同步还是异步通信？ 核心链路同步 RPC，可异步化（发短信）用消息队列。

追问：边界怎么定（详解见单体拆分与边界设计）？ 康威定律（团队边界）→ DDD 限界上下文（业务边界）→ database-per-service（数据所有权）三个锚点；边界画错的信号：一个需求改 3 个服务、跨服务 JOIN、循环依赖、分布式事务频发。

Q3：服务注册发现怎么做？

实例启动注册 + 心跳续期，调用方拉列表 + 负载均衡。下线先注销再停。

追问：etcd 和 consul 区别？ etcd 强一致（Raft）带租约，consul 带健康检查。

Q4：熔断、限流、降级区别？

限流控制进入量，熔断下游故障快速失败（Closed→Open→Half-Open），降级关非核心保核心。

追问：为什么必须设超时？ 不设超时，慢服务会拖死所有调用方，级联雪崩。

Q5：优雅上下线怎么做？

优雅停机：停新请求 → 处理在途 → 注销 → 退出（Go 用 signal.NotifyContext + Shutdown(ctx)）。优雅上线：预热完再注册接流量。

追问：为什么需要预热？ 避免刚注册就被打满。

Q6：超时重试有什么坑？

重试会重复执行副作用，所以重试必须配合幂等。

追问：怎么保证幂等？ 唯一键、token、状态机。

Q7：什么时候拆单体？（详解见单体拆分与边界设计）

团队冲突 + 发布变慢 + 故障爆炸半径大 + 独立扩缩容，出现 2 条以上才拆；团队小/领域不清/强一致要求高时不拆（Monolith-first）。

追问：怎么安全迁移？ 绞杀者模式（新功能走新服务、老功能逐个搬）+ 防腐层隔离老模型 + 契约先行 + 数据双写过渡 + 按流量/用户灰度 + 影子流量对比。

Q8：拆库后跨服务数据一致性怎么解决？

不用 2PC：本地消息表 / 事务消息（RocketMQ）/ SAGA 补偿 + 消费幂等（状态机 + 唯一键）+ 对账任务兜底，最终一致。

追问：本地消息表原理？ 业务表和消息表同一个本地事务写，事务提交后后台扫消息表发 MQ，发成功置 done——"先本地事务，再异步投递"。

---

自测清单

八题 + 追问全答上，S4 过关。进入 S5 高并发场景题。