微服务架构 - 面试题库
一、基础题 ⭐
Q1. 微服务架构和单体架构的主要区别是什么？
关联知识点：微服务基础、架构设计
答案：单体架构将所有功能模块打包成一个应用部署，共享同一个进程、数据库和代码库。微服务架构将系统拆分为多个独立部署的小型服务，每个服务拥有独立的进程、数据存储和代码库，通过轻量级通信（HTTP/gRPC）协作。微服务的优势在于独立部署、技术栈灵活、故障隔离；代价是运维复杂度提升、分布式事务处理困难、网络延迟增加。选择架构时应根据团队规模、业务复杂度和交付频率综合权衡。
Q2. 什么是服务注册与发现？
关联知识点：微服务基础、Spring Cloud
答案：服务注册与发现是微服务架构中管理服务实例的核心机制。服务启动时向注册中心（如 Eureka、Consul、Nacos）注册自己的地址和元数据，消费者通过注册中心查询可用实例列表进行调用。注册中心通过心跳检测实现健康检查，自动剔除不可用实例。服务发现分为客户端发现（如 Eureka）和服务端发现（如 API Gateway + 负载均衡）。这种机制实现了服务间的动态路由，避免了硬编码地址，支持弹性伸缩和故障转移。
Q3. 微服务之间常用的通信方式有哪些？
关联知识点：微服务基础、通用概念
答案：同步通信主要使用 HTTP/REST 和 gRPC。REST 基于 JSON，可读性好但性能较低；gRPC 基于 Protobuf 序列化，性能高且支持双向流。异步通信主要使用消息队列（如 Kafka、RabbitMQ），适用于解耦和削峰场景。此外还有 GraphQL 用于灵活查询、WebSocket 用于实时通信。选择通信方式时需考虑延迟、吞吐量、可靠性和开发效率。同步调用简单直接但存在级联故障风险，异步调用可靠性高但增加了系统复杂度。
Q4. 什么是 API Gateway？它解决了什么问题？
关联知识点：微服务基础、架构设计
答案：API Gateway 是微服务架构的统一入口，位于客户端和后端服务之间。它解决的问题包括：客户端需要知道多个服务地址（Gateway 统一路由）、认证逻辑分散（Gateway 集中鉴权）、协议不匹配（Gateway 协议转换）、缺乏限流和监控（Gateway 统一治理）。常见实现有 Spring Cloud Gateway、Kong、Envoy。Gateway 还承担负载均衡、缓存、日志聚合、请求聚合等功能。但 Gateway 也可能成为性能瓶颈，需要高可用部署。
Q5. 什么是服务熔断？为什么需要熔断机制？
关联知识点：微服务基础、服务治理
答案：服务熔断是一种保护机制，当某个服务调用失败率达到阈值时，自动”跳闸”停止对该服务的调用，快速返回错误响应，避免资源持续浪费和故障扩散。熔断器有三种状态：关闭（正常调用）、打开（快速失败）、半开（试探性放行少量请求）。熔断解决了微服务间的级联故障问题——一个下游服务宕机可能导致上游服务线程池耗尽，进而引发雪崩效应。常见实现有 Hystrix、Resilience4j、Sentinel。
Q6. 微服务架构中如何实现配置管理？
关联知识点：微服务基础、Spring Cloud
答案：微服务的配置管理需要解决配置分散、动态更新、环境隔离等问题。常见方案：（1）配置中心模式，如 Spring Cloud Config、Nacos、Apollo，将配置集中存储，服务启动时拉取；（2）环境变量注入，适合容器化部署；（3）配置文件打包，灵活性差。配置中心支持动态刷新（无需重启）、版本管理、灰度发布和权限控制。敏感信息（如密码）应加密存储。配置变更需要有审计日志和回滚能力，避免配置错误导致大面积故障。
Q7. 什么是服务网格（Service Mesh）？
关联知识点：微服务基础、架构设计
答案：服务网格是微服务间的通信基础设施层，将服务间通信的逻辑（负载均衡、熔断、限流、认证、可观测性）从业务代码中剥离，下沉到独立的 Sidecar 代理中。典型实现是 Istio + Envoy，每个服务实例旁边部署一个 Sidecar 代理，所有进出流量都经过 Sidecar 处理。服务网格的优势是业务代码无侵入、统一治理能力、跨语言支持；代价是增加部署复杂度、引入额外延迟和资源开销。适用于服务数量庞大、多语言技术栈的场景。
Q8. 微服务如何设计数据库？
关联知识点：微服务基础、架构设计
答案：微服务遵循”数据库按服务拆分”原则，每个服务拥有独立的数据库，禁止跨服务直接访问数据库。拆分策略：（1）按业务域拆分，如用户服务用 user_db，订单服务用 order_db；（2）按数据量拆分，大表独立存储。数据一致性通过服务间 API 调用或事件驱动实现。跨服务查询使用 CQRS 模式（读写分离）或数据同步（如 Canal 监听 Binlog）。数据库选型可以异构，如用户服务用 MySQL，搜索服务用 Elasticsearch。难点在于分布式事务和跨服务 JOIN 查询。
二、进阶题 ⭐⭐
Q9. Spring Cloud 中 Eureka 和 Nacos 的区别是什么？
关联知识点：Spring Cloud、服务注册与发现
答案：Eureka 是 Netflix 开源的服务注册中心，仅支持服务注册发现，采用 AP 模型（高可用），通过心跳续约和健康检查实现实例管理，已停止维护。Nacos 是阿里巴巴开源的注册配置中心，同时支持服务注册发现和动态配置管理，支持 AP 和 CP 模型切换（Distro/Raft 协议），性能更高，支持权重路由、元数据管理和多环境隔离。Nacos 在国内生态更活跃，是 Spring Cloud Alibaba 的核心组件。新项目推荐选择 Nacos，老项目使用 Eureka 可继续运行。
Q10. Spring Cloud Gateway 的工作原理是什么？
关联知识点：Spring Cloud、API Gateway
答案：Spring Cloud Gateway 基于 Spring WebFlux（响应式编程），核心概念包括路由（Route）、断言（Predicate）和过滤器（Filter）。工作流程：（1）请求到达 Gateway，路由断言处理器匹配路由规则（如路径、请求头、时间）；（2）匹配成功后，请求经过前置过滤器（鉴权、限流、日志）；（3）转发到目标服务；（4）响应经过后置过滤器（响应处理、埋点）。支持动态路由配置（从 Nacos/Consul 拉取），集成 Ribbon 实现负载均衡，支持熔断降级（集成 Resilience4j）。相比 Zuul 1.x，性能更优且非阻塞。
Q11. Spring Cloud 中 OpenFeign 的工作原理是什么？
关联知识点：Spring Cloud、服务间通信
答案：OpenFeign 是声明式 HTTP 客户端，通过接口注解定义服务调用，底层自动生成 HTTP 请求。工作流程：（1）启动时扫描 @FeignClient 注解的接口，创建动态代理；（2）调用接口方法时，根据注解信息（服务名、路径、参数）构建 HTTP 请求；（3）集成 Ribbon 实现客户端负载均衡，从注册中心获取实例列表；（4）发送请求并反序列化响应。支持自定义拦截器（添加认证头）、编码器/解码器、重试策略和降级处理（集成 Sentinel）。优势是代码简洁，像调用本地方法一样调用远程服务。
Q12. 分布式事务的解决方案有哪些？
关联知识点：分布式事务、通用概念
答案：分布式事务的常见方案：（1）2PC（两阶段提交）：强一致性，协调者先 prepare 再 commit，但阻塞且性能差；（2）TCC（Try-Confirm-Cancel）：业务层面实现补偿逻辑，性能好但侵入性强；（3）本地消息表 + 消息队列：最终一致性，业务操作和消息写入同一事务，消费者保证幂等；（4）Saga 模式：长事务拆分为多个本地事务，通过补偿操作回滚；（5）Seata 框架：提供 AT（自动）、TCC、Saga 多种模式。选择时需权衡一致性要求和业务复杂度，互联网场景多用最终一致性。
Q13. 什么是 CAP 定理？在微服务中如何取舍？
关联知识点：分布式事务、通用概念
答案：CAP 定理指出分布式系统无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者，最多满足两项。由于网络分区不可避免（P 必须保证），实际只能在 CP 和 AP 之间选择。CP 系统（如 ZooKeeper、etcd）保证强一致，分区时拒绝部分请求；AP 系统（如 Eureka、Cassandra）保证可用，分区时返回可能过期的数据。微服务中通常采用 BASE 理论（基本可用、软状态、最终一致性），核心数据用 CP，非核心数据用 AP，通过补偿机制达到最终一致。
Q14. 如何实现微服务的限流和降级？
关联知识点：服务治理、Spring Cloud
答案：限流用于控制系统流量，防止服务过载。常见算法：（1）计数器：简单但存在临界问题；（2）滑动窗口：更精确；（3）令牌桶：允许突发流量；（4）漏桶：平滑输出。降级是服务不可用时返回兜底数据。实现方案：Sentinel 支持 QPS/线程数限流、热点参数限流、系统自适应保护；Resilience4j 提供轻量级限流和熔断；网关层可做全局限流。限流策略应根据服务容量和业务重要性配置，核心接口阈值高，非核心接口严格限流。降级逻辑需提前设计兜底方案。
Q15. 微服务架构中如何实现链路追踪？
关联知识点：服务治理、可观测性
答案：链路追踪用于追踪请求在微服务间的完整调用路径，解决分布式系统故障定位困难的问题。核心概念：Trace（一次请求的完整追踪）、Span（调用链中的一个节点）、SpanContext（传递追踪上下文）。实现方案：（1）SkyWalking：国产开源，无侵入 Agent 字节码注入，支持 Java/.NET/Go；（2）Zipkin + Brave/Sleuth：Spring Cloud 生态，需代码集成；（3）Jaeger：Uber 开源，CNCF 项目。关键是在请求入口生成 TraceId，通过 HTTP Header 在服务间传递，各服务上报 Span 到收集器，最终可视化展示调用拓扑和延迟分布。
Q16. 微服务如何进行灰度发布（金丝雀发布）？
关联知识点：服务治理、架构设计
答案：灰度发布是将新版本服务逐步放量，验证无误后全量上线的发布策略。实现方式：（1）网关层路由：根据用户 ID、地域、标签等条件将部分流量路由到新版本；（2）注册中心权重：调整新旧版本实例的流量权重；（3）Service Mesh：Istio 通过 VirtualService 和 DestinationRule 精细控制流量比例。灰度策略：先内部用户 → 1% 线上用户 → 10% → 50% → 全量。需要配套的监控告警，发现异常快速回滚。数据库变更需兼容新旧版本，避免破坏性变更。
Q17. 微服务架构中如何设计幂等性？
关联知识点：服务治理、通用概念
答案：幂等性指同一操作执行多次结果一致，在微服务中尤为重要（网络重试、消息重复消费）。实现方案：（1）唯一索引：数据库唯一约束防止重复插入；（2）乐观锁：版本号机制，更新时检查版本号；（3）去重表：记录已处理的请求 ID，处理前检查；（4）Token 机制：先获取 Token，提交时验证并删除；（5）状态机：只有特定状态才能转换，避免重复操作。消息队列消费需保证幂等，消费者处理前先检查是否已处理。分布式锁可辅助实现，但要注意锁粒度。
Q18. 什么是 CQRS 模式？适用场景是什么？
关联知识点：架构设计、通用概念
答案：CQRS（Command Query Responsibility Segregation）将读写操作分离为独立的模型。写模型（Command）处理业务逻辑和数据变更，读模型（Query）专门优化查询性能，两者通过事件或异步同步保持一致。适用场景：（1）读写负载差异大，如电商读多写少；（2）复杂查询场景，读模型可设计为宽表或 Elasticsearch；（3）多数据源聚合查询。优势是读写独立扩展、查询性能优化、模型简化；代价是数据最终一致、系统复杂度增加。不适合强一致性要求高的场景。
Q19. 微服务架构中如何实现分布式锁？
关联知识点：分布式事务、通用概念
答案：分布式锁用于跨服务实例的互斥访问。常见实现：（1）Redis 分布式锁：SET key value NX EX 命令，配合 Lua 脚本保证原子性，Redlock 算法提高可靠性；（2）ZooKeeper：利用临时顺序节点实现，可靠性高但性能较低；（3）etcd：基于 Lease 和 Compare-And-Swap，适合云原生场景。关键问题：锁超时（防止死锁）、可重入（同一线程多次获取）、续期（WatchDog 机制）、公平性。Redisson 是 Java 常用的 Redis 分布式锁库。选择时需权衡性能、可靠性和运维成本。
Q20. 微服务中如何处理分布式 ID 生成？
关联知识点：架构设计、通用概念
答案：分布式 ID 需要全局唯一、趋势递增、高性能生成。常见方案：（1）UUID：简单但无序，不适合作为主键；（2）数据库自增：简单但单点瓶颈，可用号段模式优化；（3）雪花算法（Snowflake）：Twitter 开源，64 位 ID 包含时间戳 + 机器 ID + 序列号，高性能且趋势递增，但时钟回拨问题需处理；（4）Leaf（美团）：号段模式和雪花模式双模式；（5）UidGenerator（百度）：优化版雪花算法。选择时需考虑生成速度、有序性、可读性和容灾能力。雪花算法是最常用的方案。
三、高级题 ⭐⭐⭐
Q21. 如何设计一个高可用的微服务注册中心？
关联知识点：服务治理、架构设计
答案：高可用注册中心需解决单点故障、数据一致性和跨机房同步问题。设计要点：（1）集群部署：至少 3 个节点，避免脑裂；（2）数据同步：AP 模型用 Distro 协议（Nacos），CP 模型用 Raft 协议（etcd）；（3）客户端缓存：客户端缓存服务列表，注册中心宕机时仍可用；（4）健康检查：被动检测（请求失败）+ 主动探测（心跳）；（5）多机房部署：同机房优先路由，跨机房异步同步。Nacos 支持 AP/CP 切换，核心服务用 CP 保证一致性，非核心服务用 AP 保证可用性。
Q22. Seata 的 AT 模式是如何实现分布式事务的？
关联知识点：分布式事务、Spring Cloud
答案：Seata AT 模式是一种无侵入的分布式事务方案。工作流程：（1）一阶段：业务数据和回滚日志（undo_log）在同一本地事务中提交，Seata 拦截 SQL 解析前后镜像生成 undo_log；（2）二阶段提交：异步删除 undo_log；（3）二阶段回滚：根据 undo_log 反向补偿，恢复数据。核心优势是对业务代码零侵入，只需添加 @GlobalTransactional 注解。前提条件：数据库支持本地事务、表必须有主键、undo_log 表需预先创建。适用于大多数基于关系型数据库的微服务场景。
Q23. 微服务架构中如何设计消息队列的可靠性投递？
关联知识点：消息队列、服务治理
答案：可靠投递需要保证消息不丢失、不重复。生产端：（1）事务消息或本地消息表，确保业务操作和消息发送原子性；（2）发送确认机制，未收到 ACK 则重试。Broker 端：（1）持久化存储，消息落盘；（2）多副本同步复制，避免单点丢失。消费端：（1）手动 ACK，处理成功后确认；（2）幂等消费，通过唯一 ID 去重；（3）死信队列，处理失败的消息隔离。Kafka 通过 ISR 机制保证副本一致性，RabbitMQ 通过 Publisher Confirms 和 Consumer ACK 保证可靠性。
Q24. 微服务拆分的原则和边界如何确定？
关联知识点：架构设计、通用概念
答案：微服务拆分应遵循高内聚低耦合原则。拆分策略：（1）领域驱动设计（DDD）：按限界上下文（Bounded Context）划分服务边界，聚合根作为服务核心实体；（2）单一职责：一个服务只做一件事；（3）数据自治：服务拥有独立数据库；（4）团队对齐：康威定律——服务边界与团队边界一致。避免过度拆分：服务间调用延迟、分布式事务复杂度、运维成本会随服务数量指数增长。建议初期粗粒度拆分，随业务发展逐步细化。服务间依赖应保持单向，避免循环依赖。
Q25. 如何处理微服务间的循环依赖问题？
关联知识点：架构设计、服务治理
答案：循环依赖（A 调用 B，B 调用 A）会导致耦合紧密、部署困难和级联故障。解决方案：（1）引入中间服务 C，A 和 B 都通过 C 交互，打破循环；（2）事件驱动：A 完成操作后发布事件，B 订阅事件异步处理，解除同步依赖；（3）数据冗余：B 冗余 A 的部分数据，减少调用；（4）接口下沉：将共同依赖的接口提取为独立服务。设计阶段应绘制服务依赖图，检测循环依赖。运行时可通过网关限制调用方向，核心服务优先保证单向依赖链。
Q26. 微服务架构中如何设计多租户系统？
关联知识点：架构设计、通用概念
答案：多租户系统的三种数据隔离方案：（1）独立数据库：每个租户一个数据库，隔离性最强，成本高，适合大客户；（2）共享库独立 Schema：同一数据库不同 Schema，平衡隔离和成本；（3）共享库共享 Schema：通过 tenant_id 字段区分，成本最低但隔离性弱。架构设计要点：租户识别（请求头/Token 中携带 tenant_id）、数据过滤（自动注入 tenant_id 条件）、资源隔离（核心租户独立部署）、计费隔离（按租户统计资源使用）。SaaS 平台常用方案 3，通过中间件自动注入租户条件实现透明隔离。
Q27. 如何优化微服务间的调用延迟？
关联知识点：服务治理、性能优化
答案：延迟优化从多个层面入手：（1）通信协议：gRPC 替代 HTTP/REST，Protobuf 替代 JSON，减少序列化和网络开销；（2）连接复用：HTTP/2 多路复用，避免频繁建连；（3）批量调用：多个小请求合并为一次批量调用；（4）异步化：非关键路径改为异步调用或消息队列；（5）缓存：热点数据本地缓存（Caffeine）或分布式缓存（Redis）；（6）就近路由：同机房/同可用区优先调用；（7）超时和重试优化：合理设置超时时间，避免重试风暴。监控 P99 延迟而非平均延迟，定位长尾问题。
Q28. 微服务架构中如何实现动态扩缩容？
关联知识点：架构设计、云原生
答案：动态扩缩容基于负载指标自动调整实例数量。实现方案：（1）Kubernetes HPA：基于 CPU/内存/自定义指标（QPS、延迟）自动调整 Pod 副本数；（2）云厂商自动伸缩组：AWS ASG、阿里云 ESS，基于负载指标调整 ECS 实例；（3）Serverless：按需分配资源，如 AWS Lambda、阿里云函数计算。关键配置：扩缩容阈值（避免频繁抖动）、冷却时间（防止震荡）、预热时间（新实例就绪前的流量分配）、最大/最小实例数。需要配套的负载均衡自动注册新实例，以及优雅下线处理存量请求。
Q29. 微服务架构中的安全设计要点有哪些？
关联知识点：架构设计、安全
答案：微服务安全设计涵盖多个层面：（1）认证：统一认证中心（OAuth2/OIDC），Gateway 集中鉴权，服务间使用 mTLS 或 JWT；（2）授权：RBAC/ABAC 模型，细粒度权限控制；（3）通信安全：HTTPS/TLS 加密传输，内部服务网格自动 mTLS；（4）数据安全：敏感信息加密存储，传输脱敏；（5）审计日志：记录关键操作，支持追溯；（6）API 安全：防重放攻击、防 SQL 注入、限流防刷。零信任架构假设内部网络也不安全，所有服务调用都需要验证身份。密钥管理使用 Vault 等专用工具。
Q30. 如何设计一个可观测的微服务系统？
关联知识点：服务治理、可观测性
答案：可观测性由三大支柱构成：（1）日志（Logging）：记录事件，结构化日志（JSON 格式），包含 TraceId 便于关联，集中存储（ELK/ Loki）；（2）指标（Metrics）：量化系统状态，RED 方法（Rate 请求速率、Errors 错误率、Duration 延迟），USE 方法（Utilization 利用率、Saturation 饱和度、Errors 错误），Prometheus + Grafana 是主流方案；（3）链路追踪（Tracing）：追踪请求路径，定位性能瓶颈，SkyWalking/Jaeger。三者通过 TraceId/SpanId 关联。此外需要健康检查端点（/health）和告警规则，实现主动发现问题的能力。
Q31. 微服务架构中如何处理数据库迁移？
关联知识点：分布式事务、架构设计
答案：微服务的数据库迁移需要保证平滑过渡和回滚能力。策略：（1）扩展-迁移-收缩：先添加新字段/新表，双写新旧结构，逐步迁移数据，最后删除旧结构；（2）蓝绿迁移：新旧两套数据库并行，流量逐步切换，出问题快速回滚；（3）在线迁移工具：Flyway、Liquibase 管理版本化迁移脚本。关键原则：向前兼容（新版本兼容旧数据结构）、幂等迁移（可重复执行）、分批迁移（大表分批次）、回滚方案（每步可逆）。跨服务的数据迁移通过事件驱动，保证最终一致性。迁移期间需要加强监控。
Q32. 微服务架构中如何设计缓存策略？
关联知识点：架构设计、性能优化
答案：缓存策略需考虑多层缓存和数据一致性。缓存层次：（1）客户端缓存：浏览器/APP 本地缓存静态资源；（2）CDN 缓存：边缘节点缓存热点内容；（3）网关缓存：Gateway 层缓存公共接口响应；（4）服务缓存：本地缓存（Caffeine）+ 分布式缓存（Redis）。一致性方案：（1）Cache-Aside：先查缓存，未命中查数据库后写入缓存（最常用）；（2）Write-Through：写操作同时更新缓存和数据库；（3）延迟双删：更新数据库后删除缓存，延迟再删一次防止并发问题。缓存穿透用布隆过滤器，缓存雪崩用随机过期时间。
Q33. 什么是 Saga 模式？如何实现？
关联知识点：分布式事务、架构设计
答案：Saga 模式将长事务拆分为多个本地事务，每个本地事务有对应的补偿操作。执行方式：（1）编排式（Orchestration）：中央协调器按顺序调用各服务，失败时逆序调用补偿；（2）协同式（Choreography）：各服务通过事件触发下一步，失败时发布补偿事件。适用场景：跨多个服务的长流程，如订单创建（扣库存 → 创建订单 → 扣款 → 发货），任一环节失败则逆向补偿（取消发货 → 退款 → 取消订单 → 恢复库存）。难点：补偿逻辑设计（可能失败）、隔离性弱（中间状态可见）、并发控制。适合最终一致性场景。
Q34. 微服务架构中如何实现服务间的版本管理？
关联知识点：服务治理、架构设计
答案：服务版本管理解决接口变更时的兼容性问题。策略：（1）URL 版本化：/api/v1/users、/api/v2/users，最直观但 URL 膨胀；（2）请求头版本化：Accept: application/vnd.myapi.v1+json，URL 不变；（3）向后兼容：新增字段可选，不删除已有字段，保证旧客户端可用；（4）并行部署：新旧版本同时运行，流量逐步迁移。API Gateway 负责路由到正确版本。废弃版本需有明确的生命周期管理：公告 → 过渡期 → 下线。内部服务间建议使用 Protobuf 的向后兼容规则，字段只增不删。
Q35. 微服务架构中如何排查线上故障？
关联知识点：服务治理、可观测性
答案：线上故障排查需要系统化的方法。步骤：（1）确认影响范围：哪些服务/用户受影响，通过监控大盘快速定位；（2）查看告警：最近的错误率、延迟突增、资源使用率异常；（3）链路追踪：通过 TraceId 追踪请求路径，定位故障节点；（4）日志分析：查看故障时间段的错误日志，关注异常堆栈；（5）资源检查：CPU、内存、磁盘、网络、数据库连接池；（6）变更回溯：最近的代码发布、配置变更、基础设施变更。常用工具：Grafana（指标）、SkyWalking（链路）、ELK（日志）。建立 On-Call 机制和故障响应流程，事后进行复盘。