微服务高频面试题

高频说明：这里的“高频”来自 Java 后端面试常见覆盖面整理，不代表公开统计排名；暂无来源可查。
复习方式：先按“架构目标”回答，再落到“组件、故障、治理、实践”。

快速答题框架

  • 先讲为什么拆：复杂度、团队协作、独立发布、弹性伸缩。
  • 再讲怎么拆：业务边界、数据边界、接口契约、团队边界。
  • 再讲怎么治：注册发现、网关、配置、限流、熔断、链路追踪、日志、指标。
  • 最后讲怎么兜底：降级、重试、幂等、补偿、灰度、回滚。

基础认知

什么是微服务？

面试官想看什么

  • 是否理解微服务不是“把项目拆小”这么简单。

核心答案

  • 微服务是一种架构风格，把系统拆成围绕业务能力构建、可独立开发、部署和演进的服务。
  • 每个服务通常拥有清晰边界，通过轻量通信协议协作。
  • 微服务带来独立发布和弹性扩展，也带来分布式复杂度：网络、数据一致性、观测、治理、运维成本。

常见追问

  • 微服务和单体架构怎么选？
  • 微服务是不是服务越小越好？

一句话模板

微服务的重点不是拆得多小，而是按业务能力拆出清晰边界，并用治理能力消化分布式复杂度。

单体架构和微服务架构怎么取舍？

面试官想看什么

  • 是否知道架构选择要看阶段和成本。

核心答案

  • 单体适合早期业务、团队规模小、边界不稳定、部署链路简单的阶段。
  • 微服务适合业务复杂、团队并行、模块演进节奏不同、局部扩展需求强的阶段。
  • 微服务会增加网络调用、数据一致性、部署运维、监控告警和故障治理成本。
  • 不建议为了“显得先进”而过早微服务化。

常见追问

  • 老系统如何从单体演进到微服务？
  • 什么模块适合先拆？

一句话模板

单体优先简单，微服务优先解耦和自治；是否拆分要看业务复杂度、团队协作和运维治理能力。

微服务如何划分边界？

面试官想看什么

  • 是否能从业务而不是技术层拆分。

核心答案

  • 优先按业务能力和领域边界划分，而不是按 Controller、Service、DAO 技术层拆分。
  • 一个服务应有相对独立的数据和业务规则。
  • 关注高内聚、低耦合：强相关能力放一起，频繁跨服务事务的边界要谨慎。
  • 可以结合领域驱动设计里的限界上下文思想。

常见追问

  • 用户、订单、支付、库存怎么拆？
  • 拆错了怎么办？

一句话模板

服务边界要按业务能力和数据所有权来拆，拆完以后跨服务调用和跨服务事务越少越好。

注册发现与网关

服务注册与发现解决什么问题？

面试官想看什么

  • 是否理解动态实例地址和负载均衡。

核心答案

  • 在微服务中，服务实例会扩缩容、重启、漂移，调用方不能写死 IP。
  • 服务注册中心保存服务名和实例地址。
  • 服务提供者启动时注册，停止或异常时下线。
  • 服务消费者通过服务名发现可用实例，再进行负载均衡调用。

常见追问

  • 注册中心挂了服务还能调用吗？
  • 心跳和健康检查怎么设计？

一句话模板

注册发现就是把“固定地址调用”变成“按服务名动态发现实例”，支撑扩缩容和故障摘除。

客户端负载均衡和服务端负载均衡有什么区别？

面试官想看什么

  • 是否理解负载均衡发生的位置。

核心答案

  • 客户端负载均衡：调用方拿到实例列表后自己选择目标实例。
  • 服务端负载均衡：请求先到负载均衡器，由负载均衡器转发到后端实例。
  • 客户端方式少一跳，但客户端要维护发现和策略。
  • 服务端方式集中治理更清晰，但负载均衡器自身也要高可用。

常见追问

  • Spring Cloud 里常见负载均衡怎么做？
  • Kubernetes Service 属于哪类思路？

一句话模板

客户端负载均衡把选择权放在调用方，服务端负载均衡把选择权放在中间层，各自取舍是性能、治理和复杂度。

API 网关有什么作用？

面试官想看什么

  • 是否知道网关不是业务服务。

核心答案

  • 统一入口：路由、鉴权、限流、灰度、跨域、协议转换、日志审计。
  • 隐藏内部服务拓扑，减少客户端直接依赖多个后端服务。
  • 不建议在网关堆太多业务逻辑，否则会变成新的单体瓶颈。

常见追问

  • 网关和 Nginx 有什么区别？
  • 网关如何做鉴权？

一句话模板

网关是微服务的统一入口，负责通用流量治理，不应承载核心业务流程。

配置与服务治理

配置中心解决什么问题？

面试官想看什么

  • 是否知道集中配置、动态刷新、环境隔离。

核心答案

  • 把配置从应用包里抽离，支持不同环境、不同服务集中管理。
  • 支持配置变更审计、灰度发布、动态刷新。
  • 敏感配置要加密或接入密钥管理系统，不能明文散落。
  • 配置动态刷新要注意线程安全和回滚。

常见追问

  • 哪些配置适合动态刷新？
  • 配置中心挂了服务能启动吗？

一句话模板

配置中心解决配置集中管理和动态变更问题，但敏感信息、回滚和本地兜底也必须设计。

熔断、降级、限流分别是什么？

面试官想看什么

  • 是否能区分保护对象和触发条件。

核心答案

  • 熔断：下游异常或超时达到条件后，短时间内直接失败或走兜底，避免继续压垮下游。
  • 降级：牺牲非核心功能，保障核心链路可用。
  • 限流：限制进入系统或某个资源的请求量，防止过载。
  • 三者目标都是保护系统，但位置和触发机制不同。

常见追问

  • 熔断恢复怎么做？
  • 降级返回什么内容？

一句话模板

限流挡入口，熔断保护下游，降级保核心体验，它们是高可用治理的不同手段。

重试应该怎么设计？

面试官想看什么

  • 是否知道重试可能放大故障。

核心答案

  • 只对幂等、短暂性失败适合重试。
  • 重试要有超时、次数上限、退避策略和熔断配合。
  • 不要在多层都重试，否则会造成重试风暴。
  • 写操作重试必须配合幂等键或业务去重。

常见追问

  • 哪些错误不应该重试？
  • MQ 消费失败如何重试？

一句话模板

重试不是默认开关，只适合幂等和瞬时失败；必须有上限、退避和熔断，否则会放大故障。

超时为什么很重要？

面试官想看什么

  • 是否理解线程资源和级联故障。

核心答案

  • 没有超时的远程调用可能长期占用线程、连接和内存。
  • 超时要按调用链预算设计，不能所有服务都设很长。
  • 超时后要配合降级、重试或失败返回。
  • 客户端、网关、服务端、数据库、缓存都要有合理超时。

常见追问

  • 超时时间怎么定？
  • 连接超时和读取超时区别？

一句话模板

超时是分布式系统的止损线，没有超时就可能把局部慢调用扩散成整体雪崩。

数据一致性与事务

微服务为什么不推荐跨服务强事务？

面试官想看什么

  • 是否理解服务自治和分布式事务成本。

核心答案

  • 跨服务强事务会增加耦合、锁持有时间、协调成本和故障恢复复杂度。
  • 微服务更常采用最终一致性，用消息、补偿、对账等方式保证业务正确。
  • 对一致性要求极高的核心链路要谨慎拆分，或把强一致边界放在同一服务内。

常见追问

  • 最终一致性怎么保证？
  • 什么场景必须强一致？

一句话模板

微服务优先让强一致发生在服务内部，跨服务更多用最终一致和补偿机制解决。

分布式事务常见方案有哪些？

面试官想看什么

  • 是否能说出适用场景和缺点。

核心答案

  • Saga：把长事务拆成多个本地事务，每步失败后执行补偿。
  • TCC：Try、Confirm、Cancel 三个阶段，业务侵入强，但控制精细。
  • 本地消息表或 Outbox：本地事务同时写业务数据和消息记录，再异步投递。
  • 可靠消息最终一致：通过消息确认、重试、幂等消费和对账保证一致性。
  • 强协调事务适用面窄，通常成本较高。

常见追问

  • 订单扣库存适合什么方案？
  • 补偿失败怎么办？

一句话模板

分布式事务没有银弹，核心是在一致性、性能、侵入性和恢复复杂度之间取舍。

如何保证接口幂等？

面试官想看什么

  • 是否能落到数据库和缓存实现。

核心答案

  • 幂等是同一请求重复执行不会产生额外副作用。
  • 常见方案：唯一业务号、幂等表、数据库唯一约束、状态机流转、分布式锁、Token 防重。
  • 写接口要明确幂等键来源，比如订单号、请求号、支付流水号。
  • 幂等结果要可查询，不能只简单拒绝重复请求。

常见追问

  • MQ 重复消费怎么幂等？
  • 支付回调为什么必须幂等？

一句话模板

幂等的关键是给请求一个业务唯一标识，并用数据库约束或状态机把重复请求收敛成同一个结果。

如何处理 MQ 重复消费？

面试官想看什么

  • 是否知道消息系统通常更强调至少一次投递语义。

核心答案

  • 消费端必须设计幂等。
  • 可用消息 ID、业务单号、去重表、唯一索引、状态机判断处理。
  • 处理成功后再确认消息，失败则重试或进入死信队列。
  • 消费逻辑要能安全重入。

常见追问

  • 先 ack 再处理会怎样？
  • 去重表会不会成为瓶颈？

一句话模板

不要假设消息只会到一次，消费端必须用业务唯一键或状态机做幂等。

如何处理 MQ 消息顺序？

面试官想看什么

  • 是否知道顺序和吞吐的取舍。

核心答案

  • 全局顺序成本高，通常只保证同一业务键内有序。
  • 同一订单、同一用户的消息路由到同一队列或分区。
  • 消费端串行处理同一业务键。
  • 如果乱序不可避免，要用版本号、状态机或补偿校正。

常见追问

  • 为什么不追求全局有序？
  • 分区扩容后顺序怎么保证？

一句话模板

消息顺序通常按业务键保证局部有序，全局有序会严重牺牲吞吐和可扩展性。

观测与故障排查

微服务可观测性包括什么？

面试官想看什么

  • 是否知道日志、指标、链路追踪的互补关系。

核心答案

  • 日志：记录离散事件和上下文。
  • 指标：观察趋势和告警，比如 RT、错误率、吞吐、资源使用。
  • 链路追踪：串起跨服务调用路径，定位慢点和错误传播。
  • 三者要统一 traceId 或关联字段。

常见追问

  • traceId 怎么传递？
  • 日志过多怎么办？

一句话模板

日志看细节，指标看趋势，链路追踪看调用路径，三者结合才能排查微服务问题。

链路追踪如何设计？

面试官想看什么

  • 是否理解 traceId、span、上下文传播。

核心答案

  • 一次请求生成 traceId，跨服务透传。
  • 每个服务内部关键操作形成 span。
  • HTTP、RPC、MQ 都要传递上下文。
  • 采样要平衡成本和排查价值，错误请求可提高采样优先级。

常见追问

  • 异步消息如何继续链路？
  • 采样会不会漏问题？

一句话模板

链路追踪本质是把一次请求在各服务中的片段用 traceId 串起来，帮助定位跨服务慢点和错误点。

如何排查微服务接口超时？

面试官想看什么

  • 是否能按调用链逐层缩小范围。

核心答案

  • 从网关或入口服务看请求耗时和错误。
  • 查链路追踪，定位最慢 span。
  • 查对应服务日志、线程池、连接池、GC、数据库、缓存、下游依赖。
  • 看是否有重试放大、限流触发、连接池耗尽、慢 SQL、锁等待。
  • 用时间线关联发布、配置变更、流量变化。

常见追问

  • 没有链路追踪怎么办？
  • 超时和熔断日志怎么关联？

一句话模板

超时排查要沿调用链找最大耗时点，再下钻到线程池、连接池、数据库、缓存和下游依赖。

安全与接口设计

微服务鉴权怎么做？

面试官想看什么

  • 是否能区分认证、授权和服务间信任。

核心答案

  • 认证解决“你是谁”，授权解决“你能做什么”。
  • 常见做法是入口网关验证用户身份，服务内部继续做资源级权限校验。
  • 服务间调用可使用 mTLS、签名、短期 Token 或内网身份机制。
  • 不能只依赖前端传参或网关校验，核心服务仍要做关键权限判断。

常见追问

  • JWT 注销怎么处理？
  • RBAC 和 ABAC 区别？

一句话模板

网关做统一认证，业务服务做细粒度授权，服务间调用也要有可信身份机制。

JWT 有什么优缺点？

面试官想看什么

  • 是否知道无状态和撤销难之间的取舍。

核心答案

  • 优点：自包含、易于跨服务验证、减少集中会话查询。
  • 缺点：签发后撤销困难、载荷变大、敏感信息不能明文放入载荷。
  • 适合短有效期、配合刷新令牌、黑名单或版本号机制。
  • 必须校验签名、过期时间、签发方和受众等关键字段。

常见追问

  • JWT 放在哪里更安全？
  • 如何处理密钥轮换？

一句话模板

JWT 适合无状态认证，但撤销和泄露风险要通过短期令牌、刷新机制和服务端控制补齐。

API 如何设计错误码？

面试官想看什么

  • 是否知道业务错误和 HTTP 语义要分层。

核心答案

  • HTTP 状态码表达协议层结果，比如认证失败、权限不足、资源不存在、服务不可用。
  • 业务错误码表达业务原因，比如余额不足、库存不足、状态不允许。
  • 错误响应要包含可读消息、错误码、traceId，方便排查。
  • 不要所有错误都返回成功状态再靠业务码区分。

常见追问

  • 参数错误用什么状态码？
  • 限流用什么状态码？

一句话模板

HTTP 状态码管协议语义，业务错误码管业务语义，两层都清楚，客户端和排查才舒服。

发布与稳定性

灰度发布、蓝绿发布、滚动发布怎么区分？

面试官想看什么

  • 是否知道发布策略和回滚策略。

核心答案

  • 滚动发布：逐批替换实例，资源成本较低，但新旧版本会共存。
  • 蓝绿发布：准备两套环境，流量整体切换，回滚快，但资源成本高。
  • 灰度发布：按用户、比例、区域或标签逐步放量，适合控制风险。
  • 发布前要保证接口兼容、数据库变更兼容、配置可回滚。

常见追问

  • 数据库变更怎么配合灰度？
  • 新旧版本接口不兼容怎么办？

一句话模板

滚动省资源，蓝绿回滚快，灰度控风险；真正难点是兼容性和可回滚设计。

如何设计服务降级？

面试官想看什么

  • 是否能区分核心和非核心能力。

核心答案

  • 明确核心链路和非核心链路。
  • 非核心能力失败时返回缓存、默认值、静态数据或隐藏功能。
  • 降级要可配置、可灰度、可观测。
  • 降级不能掩盖核心数据错误，支付、资金、库存等链路要谨慎。

常见追问

  • 降级数据会不会误导用户？
  • 如何恢复降级？

一句话模板

降级是牺牲非核心功能保护核心链路，必须提前设计，而不是故障时临时拍脑袋。

如何防止雪崩？

面试官想看什么

  • 是否理解级联故障。

核心答案

  • 设置合理超时，避免线程长期占用。
  • 限流保护入口和关键资源。
  • 熔断隔离异常下游。
  • 线程池或连接池隔离，避免一个依赖拖垮全部请求。
  • 降级保证核心链路可用。
  • 监控告警提前发现异常趋势。

常见追问

  • 隔离有哪些方式？
  • 缓存雪崩和服务雪崩有什么区别？

一句话模板

防雪崩靠超时、限流、熔断、隔离、降级和观测组合，核心是阻断故障扩散。

Spring Cloud 与 Kubernetes

Spring Cloud 常见组件怎么分工？

面试官想看什么

  • 是否知道组件解决的问题，而不是只背名字。

核心答案

  • Spring Cloud Gateway：网关路由和过滤。
  • Spring Cloud Config：集中配置。
  • Spring Cloud LoadBalancer：客户端负载均衡。
  • Spring Cloud CircuitBreaker：熔断抽象，可接入 Resilience4j 等实现。
  • 具体注册中心可根据技术栈选择，比如 Eureka、Nacos、Consul 等。

常见追问

  • OpenFeign 和网关有什么区别？
  • Spring Cloud Alibaba 常见组件有哪些？

一句话模板

Spring Cloud 是一组微服务治理抽象和组件，重点要说清每个组件解决哪类治理问题。

Kubernetes 中 Deployment、Service、Ingress 分别是什么？

面试官想看什么

  • 是否理解容器编排基础对象。

核心答案

  • Deployment 管理 Pod 副本和滚动更新。
  • Service 为一组 Pod 提供稳定访问入口和服务发现。
  • Ingress 管理外部 HTTP/HTTPS 访问规则，通常配合 Ingress Controller。
  • Pod 是运行容器的基本调度单元。

常见追问

  • Service 如何找到 Pod？
  • Readiness Probe 和 Liveness Probe 区别？

一句话模板

Deployment 管副本，Service 管稳定访问，Ingress 管外部入口，Pod 承载实际容器。

健康检查怎么设计？

面试官想看什么

  • 是否知道存活检查和就绪检查的区别。

核心答案

  • 存活检查判断进程是否需要重启。
  • 就绪检查判断实例是否可以接流量。
  • 启动慢的服务要配置启动保护，避免还没初始化完就被重启。
  • 健康检查不能太重，不能依赖大量下游调用。

常见追问

  • 数据库连不上健康检查要失败吗？
  • 如何避免健康检查放大故障？

一句话模板

存活检查决定要不要重启，就绪检查决定要不要接流量，二者不能混用。

缓存与数据库

缓存穿透、击穿、雪崩怎么处理？

面试官想看什么

  • 是否能区分三个概念和解决方案。

核心答案

  • 穿透：查询不存在的数据绕过缓存打到数据库，可用空值缓存、布隆过滤器、参数校验。
  • 击穿：热点 key 过期瞬间大量请求打到数据库，可用互斥锁、逻辑过期、热点预热。
  • 雪崩：大量 key 同时失效或缓存集群故障，可用过期时间随机化、多级缓存、限流降级。

常见追问

  • 空值缓存有什么风险？
  • 布隆过滤器误判怎么办？

一句话模板

穿透是查不到，击穿是热点失效，雪崩是大面积失效；先区分场景再选方案。

数据库拆分后如何处理跨库查询？

面试官想看什么

  • 是否知道拆库后的查询代价。

核心答案

  • 优先避免跨库查询，通过业务边界和冗余字段减少 join。
  • 读模型可通过异步同步、宽表、搜索引擎、数据仓库解决。
  • 必须跨库时由应用层聚合，但要控制分页、排序和一致性问题。
  • 重要数据要有对账和补偿机制。

常见追问

  • 分库分表后的分页怎么做？
  • 冗余字段如何保持一致？

一句话模板

拆库后不能再依赖数据库 join 思维，要用业务边界、冗余读模型和异步同步来换取扩展性。

场景题

订单服务调用库存服务失败怎么办？

核心答案

  • 先判断业务一致性要求。
  • 同步链路可设置超时、重试、熔断和明确失败返回。
  • 异步链路可用消息驱动、库存预占、超时取消、补偿和对账。
  • 所有写操作要幂等，防止重复扣减或重复创建订单。

一句话模板

订单库存这类链路重点是状态机、幂等和补偿，不能只靠一次 RPC 成功来保证业务正确。

秒杀系统微服务要注意什么？

核心答案

  • 入口限流和排队削峰。
  • 热点商品缓存和库存预热。
  • 库存扣减要原子化，避免超卖。
  • 下单异步化，快速返回排队或受理结果。
  • 防刷、风控、幂等、降级和监控必须提前设计。

一句话模板

秒杀核心是削峰、限流、热点缓存、库存原子扣减和异步化，先保护系统再保证体验。

面试最后可反问

  • 你们现在微服务拆分是按业务域还是按技术层？
  • 线上主要用什么注册中心、网关和链路追踪方案？
  • 发布策略是滚动、蓝绿还是灰度？数据库变更如何回滚？
  • 服务故障时有没有统一的降级和熔断平台？

来源与出处

信心指数

信心指数：8/10。
低于满分原因：不同公司对“高频”的排序没有统一公开统计来源；本文按 Java 后端常见面试覆盖面整理，已在开头标注“暂无来源可查”。