Java后端面试知识库

外观

微服务架构 速查卡 ​

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

一、注册与发现 ​

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

⭐ Nacos 注册与发现 ​

一句话： Nacos 支持临时实例(AP 模式/Distro 协议/客户端心跳)和永久实例(CP 模式/JRaft 协议/服务端探测)，客户端注册后通过 UDP 推送+HTTP 长轮询感知实例变更，本地缓存实例列表实现容灾。

维度临时实例 (Ephemeral)永久实例 (Persistent)
健康检查客户端心跳 5s/次服务端主动探测 TCP/HTTP
不健康处理15s 标记不健康，30s 剔除标记不健康但不剔除
一致性协议AP — Distro（最终一致）CP — JRaft（强一致）
场景Spring Cloud 微服务数据库、中间件等基础设施

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

注册流程核心步骤：

启动 → register(IP:Port+元数据) → 写入内存 ConcurrentHashMap
     → Distro 异步同步 → UDP 推送订阅者
     → 心跳定时任务 5s/次（返回 NOT_FOUND 则重新注册）

⭐ Nacos vs Eureka vs ZooKeeper ​

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

维度NacosEurekaZooKeeper
CAPAP + CP 可切换APCP
协议Distro / JRaft对等复制ZAB(类 Paxos)
推/拉推(UDP) + 拉(长轮询)拉(30s 轮询)推(Watch)
自我保护有(Distro 容忍)有(Renew<85%不剔除)无(过半不可用则不可写)
配置中心内置不支持需封装
权重/灰度原生支持不支持不支持
维护阿里活跃Netflix 已停更Apache 活跃但偏底层

⚠️ 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 链。

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

三大核心组件：

组件作用示例
Route路由规则(id + uri + predicates + filters)uri: lb://order-service
Predicate匹配条件(Path/Method/Header/Cookie/Weight...)Path=/api/order/**
Filter过滤器链(Pre→转发→Post)StripPrefix / AddRequestHeader

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)做内部服务间调用，直连无单点，实例列表从注册中心获取并本地缓存。

维度服务端负载均衡客户端负载均衡
代表Nginx / LVS / F5 / ALBSC LoadBalancer / Ribbon
链路Client → LB → Server(多一跳)Client → Server(直连)
单点LB 是单点(需高可用)无单点
适用外部流量入口(用户→网关)内部调用(服务→服务)

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

四、配置中心 ​

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

⭐ Nacos Config 热刷新 ​

一句话： Nacos Config 采用长轮询(Long Polling)+MD5 比对——客户端携带配置 MD5 发请求，服务端 hold 住连接最多 29.5s，有变更立即返回 dataId 列表，客户端再拉取最新配置并触发 RefreshScope 刷新 Bean。

长轮询流程：

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

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

Spring 集成两种方式：

  • @RefreshScope + @Value：配置变更时销毁旧 Bean 创建新 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=已停更(线程池隔离开销大)。

维度SentinelResilience4jHystrix
维护阿里活跃社区活跃已停更(2018)
隔离信号量(轻量)信号量(轻量)线程池+信号量(开销大)
限流内置(QPS/并发/关联/排队/预热)Rate Limiter不支持
热点参数支持不支持不支持
系统自适应CPU/Load 自适应限流不支持不支持
Dashboard自带(实时监控+动态规则)无(需 Prometheus+Grafana)Hystrix Dashboard
编程模型注解+API+Dashboard函数式(装饰器)注解+HystrixCommand

选型： 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(SDK埋点,侵入高) / Jaeger(CNCF,自适应采样) / OpenTelemetry(未来标准,统一API)

补充速览 ​

关键词核心答案
注册到调用全链路注册→订阅/推送→本地缓存实例列表→LoadBalancer选实例→Feign/Dubbo调用→失败重试/熔断降级
Gateway 自定义 FilterGlobalFilter(全局认证/日志,实现GlobalFilter接口) / GatewayFilter(局部,继承AbstractGatewayFilterFactory)
OpenFeign 原理@FeignClient→JDK动态代理→解析注解构建RequestTemplate→LoadBalancer选实例替换URL→HTTP调用→Decoder反序列化
配置中心三方案Nacos Config(长轮询,简单) / Apollo(推送,管理强大) / SC Config(Git-Based,功能少)
降级策略Fallback方法(最常用) / 静态默认值 / 缓存降级(读旧数据) / 功能开关(关非核心)
可观测三支柱Metrics(Prometheus+Grafana) + Logging(ELK/Loki) + Tracing(SkyWalking)；Trace ID 是关联纽带
gRPC vs REST vs DubboREST=跨语言/对外API；gRPC=高性能/多语言/HTTP2+Protobuf；Dubbo=Java生态/内置服务治理
Service Mesh / Sidecar治理能力下沉到 Sidecar 代理(Envoy)；Istio=控制面(Pilot/Citadel)+数据面(Envoy)；优势=语言无关/零侵入；代价=+2~5ms延迟/运维复杂

🧠 助记汇总 ​

口诀含义
临心Distro，永探JRaft临时实例=心跳+Distro(AP)；永久实例=探测+JRaft(CP)
路断过(Route/Predicate/Filter)Gateway 三大核心组件
服外客内服务端LB做外部入口，客户端LB做内部调用
长轮询MD5Nacos Config 热刷新=长轮询+MD5比对
关开半(C→O→HO)断路器三状态：Closed→Open→Half-Open
Trace穿Span量Trace ID 贯穿全链路，Span 度量每个操作
哨轻停(Sentinel/R4j/Hystrix)Sentinel全面 / Resilience4j轻量 / Hystrix已停更

✅ 自测清单 ​

#问题你能说出...
1Nacos 注册发现临时 vs 永久实例 + AP(Distro) vs CP(JRaft) + 心跳机制
2Nacos vs Eureka vs ZKCAP 模型 + 推/拉模型 + 为什么注册中心优先 AP
3Gateway 架构Route/Predicate/Filter + 异步非阻塞 + vs Zuul
4客户端 vs 服务端 LB适用场景 + 六大算法
5Nacos Config 热刷新长轮询+MD5 + ClientWorker + @RefreshScope vs @ConfigurationProperties
6断路器状态机Closed→Open→Half-Open + 滑动窗口 + 熔断策略
7Sentinel vs R4j vs Hystrix隔离策略 + 限流 + Dashboard + 选型建议
8分布式追踪Trace ID+Span ID + 传播机制 + SkyWalking 零侵入

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