微服务架构 速查卡#

🎯 覆盖 16 题 | ⭐ 高频 8 题 | 预计扫描 9 分钟 📌 先看⭐一句话答案 → 展开要点 → 自测清单检验

一、注册与发现#

知识地图：Nacos(AP Distro / CP JRaft) / 临时实例(心跳) vs 永久实例(探测) / 注册→订阅→缓存→调用

⭐ Nacos 注册与发现#

一句话： Nacos 支持临时实例(AP 模式/Distro 协议/客户端心跳)和永久实例(CP 模式/JRaft 协议/服务端探测)，客户端注册后靠 gRPC 长连接接收服务端推送感知实例变更（1.x 为 UDP 推送+定时拉取），本地缓存实例列表实现容灾。

Distro 协议要点： Hash 分片写入 → 异步复制到其他节点 → 每节点持有全量数据（读任意节点）；写入快但有毫秒级不一致

注册流程核心步骤：

启动 → register(IP:Port+元数据) → 写入内存 ConcurrentHashMap
     → Distro 异步同步 → gRPC 推送订阅者（1.x 为 UDP）
     → gRPC 长连接保活，断连即剔除（1.x 为 5s 心跳，NOT_FOUND 重注册）

⭐ Nacos vs Eureka vs ZooKeeper#

一句话： 注册中心优先选 AP 模型——网络分区时宁可返回旧数据也不要拒绝服务；Nacos AP+CP 可切换且内置配置中心，功能最全。

⚠️ ZK 的 CP 特性对注册中心是劣势——分区时无法写入导致注册失败

二、API 网关#

知识地图：Gateway(WebFlux+Netty) / Route+Predicate+Filter 三大件 / GlobalFilter vs GatewayFilter

⭐ Spring Cloud Gateway 架构#

一句话： Gateway 基于 WebFlux+Reactor+Netty 全异步非阻塞；核心三组件——Route(路由规则)、Predicate(匹配条件)、Filter(过滤器链)，请求经 Pre Filter 链 → 路由转发 → Post Filter 链。

网关八大职责： 路由转发 / 负载均衡 / 认证鉴权 / 限流熔断 / 协议转换 / 灰度发布 / 日志监控 / 跨域处理

三大核心组件：

Filter 分类：

GatewayFilter（局部）：只作用于单个路由 → StripPrefix / Retry / RateLimiter
GlobalFilter （全局）：作用于所有路由 → 认证 / 日志 / 链路追踪
执行顺序：Pre(Order 升序) → 路由转发 → Post(Order 降序)

Gateway vs Zuul 1.x： Gateway=Netty 异步非阻塞(高性能+WebSocket) vs Zuul=Servlet 同步阻塞(并发高时线程耗尽)

三、负载均衡与通信#

知识地图：服务端LB(Nginx/LVS/F5) vs 客户端LB(SC LoadBalancer/Ribbon) / 六大算法

⭐ 客户端 vs 服务端负载均衡#

一句话： 服务端 LB(Nginx/LVS)做外部流量入口，多一跳但集中管控；客户端 LB(SC LoadBalancer)做内部服务间调用，直连无单点，实例列表从注册中心获取并本地缓存。

六大算法： RoundRobin(轮询) / Random(随机) / WeightedRoundRobin(加权轮询) / LeastConnections(最少连接) / ConsistentHash(一致性哈希) / ResponseTimeWeighted(响应时间加权)

四、配置中心#

知识地图：Nacos Config(长轮询) / Apollo(强管理) / Spring Cloud Config(Git-Based)

⭐ Nacos Config 热刷新#

一句话： Nacos Config 靠 gRPC 长连接 + MD5 比对——配置变更时服务端推送变更的 dataId 列表，客户端再拉取最新配置并触发 RefreshScope 刷新 Bean（1.x 用 HTTP 长轮询，服务端 hold 29.5s）。

1.x 长轮询流程（2.x 改为服务端 gRPC 推送+客户端拉取）：

Client POST /listener (dataId+group+md5)
  → Server 对比 MD5：
    相同 → hold 29.5s 后返回空
    不同 → 立即返回变更 dataId 列表
  → Client GET /configs 拉取最新配置
  → 更新本地缓存 + 触发 Listener
  → 立即发起下一次长轮询

ClientWorker 双线程池： 调度线程(10ms 检查) + 长轮询线程(HTTP 请求)

Spring 集成两种方式：

• @RefreshScope + @Value：配置变更时清掉缓存的旧 Bean，下次访问再创建（旧实例状态丢失、有重建开销）
• @ConfigurationProperties：直接修改属性值，更平滑（推荐）

⚠️ Nacos 客户端会将配置缓存到本地文件，Server 宕机后仍可使用缓存

五、熔断与弹性#

知识地图：断路器三状态(Closed→Open→Half-Open) / 滑动窗口 / Sentinel vs Resilience4j vs Hystrix

⭐ 断路器状态机#

一句话： 断路器三状态——Closed(正常放行，滑动窗口统计失败率) → 请求数达最小请求数且失败率>=阈值 → Open(快速失败+fallback，等冷却时间) → Half-Open(放行少量探测请求，失败率低于阈值回 Closed，否则回 Open)。

         失败率 >= 阈值
  CLOSED ──────────────→ OPEN(快速失败, 等待60s)
    ↑                       │
    │ 探测成功率达标          ↓ 冷却时间到
    └──────── HALF_OPEN ←───┘
              (放行少量探测)
              探测失败 → 回到 OPEN

滑动窗口统计： 时间窗口切分为多个桶(如 1s=5*200ms)，统计各桶成功/失败数，实时计算失败率

Sentinel 熔断策略： 慢调用比例 / 异常比例 / 异常数（三种任选）

⭐ Sentinel vs Resilience4j vs Hystrix#

一句话： Sentinel=流量治理完整方案(限流+熔断+热点+Dashboard)；Resilience4j=轻量级函数式弹性库；Hystrix=已停更(线程池隔离开销大)。

选型： SC Alibaba → Sentinel | Spring Boot 轻量 → Resilience4j | 老项目 → 从 Hystrix 迁走

六、分布式追踪与可观测#

知识地图：Trace ID + Span ID + Parent Span ID / 传播(HTTP Header/RPC Context/MQ Header)

⭐ 分布式追踪原理#

一句话： 链路追踪核心是 Trace ID(全局唯一标识一次完整请求) + Span(每个操作一个 Span，含 Span ID/Parent Span ID/耗时/标签)；Trace ID 通过 HTTP Header / RPC Context / MQ Header 在服务间传播。

Trace/Span 结构示意：

Trace ID: abc-123
├── Span A: 网关 [0~200ms]
│   ├── Span B: 订单服务 [10~180ms]
│   │   ├── Span C: MySQL查询 [20~50ms]
│   │   └── Span D: 库存服务 [60~150ms]
│   └── Span F: 支付服务 [50~190ms]

传播方式： HTTP=Header(X-B3-TraceId/SpanId) / RPC=Context(Attachment/Metadata) / MQ=Message Header

方案对比： SkyWalking(Agent零侵入) / Zipkin(存储展示后端,埋点靠 Brave 等库,常用框架可自动埋点) / Jaeger(CNCF,自适应采样) / OpenTelemetry(当前事实标准,统一API/SDK)

补充速览#

🧠 助记汇总#

✅ 自测清单#

💡 首次全部过一遍 → 第2天只过答不上来的 → 第4天再复习 → 面试前一天最后扫一遍