微服务架构面试问题集合

July 15, 2025

Tags

• 技术

整体性问题

1. 什么是微服务架构：

   微服务架构简单讲, 是把一个应用拆分成多个模块, 每个每块具有单一职责, 独立部署运行, 使用 api 通信的一种架构方法.
   

2. 怎么保证微服务架构的高可用

   微服务高可用关键策略：
   设计：服务解耦、冗余部署、断路器、降级、异步通信。
   开发：健康检查、幂等性、分布式追踪。
   部署：容器化（Docker）、编排（Kubernetes）、多活架构、负载均衡。
   运维：监控（Prometheus/Grafana）、自动恢复、弹性伸缩、混沌测试。
   数据：分布式数据库、缓存（Redis）、备份恢复。
   安全：API网关、DDoS防护、快速回滚。
   流程：DevOps、SLA/SLO、故障复盘。
   核心：冗余、容错、监控、自动化。结合业务场景优化投入产出比。
   

3. 怎么判定服务是否已经健康? / 怎么判定服务已经从不健康状态恢复过来了?

   看响应时间、错误率、超时率
   

4. 如果服务不健康该怎么办?

   客户端需要容错、注册中心剔除服务
   

5. 听你说你用到了 Redis 作为缓存，如果你的 Redis 崩溃了会怎么样?/ 听你说你用到了 Kafka 作为消息队列，如果你的 Kafka 崩溃了怎么办?

   应用无法启动, 直接崩溃, 无法进行服务注册
   

6. 现在需要设计一个开放平台，即提供接口给合作伙伴用，你觉得需要考虑一些什么问题?

   安全性：认证、授权、签名验证、数据加密
   可用性：限流、熔断、降级、监控
   可扩展性：版本管理、向后兼容
   可观测性：日志、监控、告警、审计
   易用性：SDK、文档、错误处理
   商业化：配额管理、计费、SLA
   合规性：数据脱敏、隐私保护、审计
   

01 | 服务注册与发现:注册中心应该选 AP 还是 CP?

1. 什么是注册中心

   存储注册服务的地方
   

2. 服务注册与发现机制的基本模型是怎样的?

   服务端将自己的地址注册进注册中心, 同时开启心跳机制确保自己有效; 客户端通过向注册中心寻找服务端信息拿到服务端地址, 同时监听注册中心确保,服务端列表有效.
   

3. 服务上线与服务下线的步骤是什么?

   上线: 服务向注册中心注册自己的地址信息, 同时绑定租约, 定期更新租约信息; 下线:服务租约过期, 注册中心删除节点, 推送最新服务地址给客户端.
   

4. 注册中心选型需要考虑哪些因素?

   cap 中 p 一定需要,  只剩a 或者 c, 看重可用性选 a, 数据一致性选 c.
   

5. 你为什么使用 Zookeeper/Nacos/etcd 作为你的注册中心?

   zookeeper、etcd 是 cp 模型; nacos 是 ap.
   确保注册中心高可用, 通常选用 ap 模型, 即使拿到不完全正确的服务端列表也没关系,因为客户端可以容错重试; 如果体量小,集群规模不大选 cp.
   

6. 什么是CAP?

   在分布式系统中, c 数据一致性, a 可用性, p 分区容错性.
   

7. 在服务注册与发现里面你觉得应该用 AP 还是 CP?

   客户端有容错,优选 ap;
   体量小, 集群规模不大 < 10, 可以选 cp.
   

8. 如何保证服务注册与发现的高可用?

     注册服务端崩溃检测: 服务周期发送续约, 注册中心会检测租约, 会在租约过期后删除服务实例.
     客户端容错: 请求超时失败、故障,要可以重试
     注册中心选型cap: etcd , cp 模型.
   

9. 服务器崩溃，如何检测?

   服务端接口暴露自检; 注册中心续约是否过期; 探针检查
   

10. 客户端容错的措施有哪些?

    故障转移, 重试
    

11. 注册中心崩溃了怎么办?

    服务降级临时绕过, 或者不用服务发现, 直接静态配置
    

12. 注册中心怎么判断服务端已经崩溃了?

    基于心跳机制的租约; 健康端点检查
    

02 | 负载均衡:调用结果、缓存机制怎么影响负载均衡的?

1. 你了解负载均衡算法吗?

   静态负载均衡算法和动态负载算法, 轮询、权重、随机、哈希和 最小活跃请求、最快响应时间
   

2. 静态负载均衡算法和动态负载均衡算法的核心区别是什么?

   静态没有考虑节点的实际负载
   

3. 轮询与随机负载均衡算法有什么区别?

   轮询是1个接着1个
   

4. 你了解平滑的加权轮询算法吗?

   基于权重算法, 可能一个节点连续多次被选中. 平滑后主要就是破坏这种连续性.
   

5. 如何根据调用结果来调整负载均衡效果?

   根据响应时间
   

6. 为什么有些算法要动态调整节点的权重?权重究竟代表了什么?

   权重一般是代表节点处理能力, 越大越强
   

7. 最快响应时间负载均衡算法有什么缺点?

   需要客户端维持每个节点的响应时间
   

8. 如果我现在有一个应用，对内存和 CPU 都非常敏感，你可以针对这个特性设计一个负载 均衡算法吗?

   需要采集指标
   

9. 为什么使用轮询、加权轮询、随机之类的负载均衡算法，系统始终会出现偶发性的流量不均衡，以至于某台服务器出故障的情况?怎么解决这一类问题?

   没有考虑请求本身是不是大数据请求, 解决方法: 业务拆分做限制查询量, 或者区分出这类请求做隔离专用另排节点
   

03 | 熔断:熔断-恢复-熔断-恢复，抖来抖去怎么办?

1. 为什么说熔断可以提高系统的可用性?

   服务不可用熔断后,  可以给出一定时间恢复
   

2. 如何判断节点的健康状态，需要看哪些指标?

   结合业务比如响应时间, 错误率.
   

3. 触发熔断之后，该熔断多久?

   60s, 个人经验
   

4. 怎么避免偶发性超过阈值的情况?

   熔断后给一段时间恢复
   

5. 服务熔断后如何恢复?

   熔断后一段时间后, 开始进入半打开状态, 允许一定量的请求通过,当连根据参数配置连续请求通过后熔断器关闭, 同时只要任何一次失败熔断器重新打开
   

6. 产生抖动的原因，以及如何解决抖动问题?

   短暂不可用和可用来会切换, 给予一定时间自动恢复.
   

04 | 降级:为什么每次大促的时候总是要把退款之类的服务停掉?

1. 什么时候会用到降级，请举例说明?

   服务器资源紧张、中间件服务压力过大
   

2. 降级有什么好处?

   腾出节点资源、减缓中间件压力
   

3. 跨服务降级常见的做法是什么?

   把不重要的服务停掉或者减少节点
   

4. 你怎么评估业务服务的重要性?或者说，你怎么知道 A 服务比 B 服务更加重要?

   评估服务重要程度
   

5. 请说一说服务内部常见的降级思路。

   读写服务降级写服务、 快慢路径停掉慢路径
   

6. 怎么判断哪些服务需要降级?

   服务是否正常响应
   

7. 触发降级之后，应该保持在降级状态多久?

   等到负载下降
   

8. 服务降级之后如何恢复，如何保证恢复过程中不发生抖动?

   逐渐恢复
   

9. 你们公司的产品首页是如何保证高可用的?

   默认首页榜单是公共的, 过一段时间后会提供个人推荐, 缓存中个人推荐未命中 会走 快路径 提供公共推荐
   

05 | 限流:别说算法了，就问你阈值怎么算?限流的目的是什么?

1. 限流算法都包括哪些?

   静态算法:令牌桶、漏桶、固定窗口、滑动窗口; 动态算法:bbr 算法
   

2. 不同的限流算法怎么选?

   固定、滑动窗口,有毛刺问题; 令牌桶, 允许一定的突发数量; 漏桶, 是绝对均匀的.
   

3. 限流的对象应该如何选择?

   非vip、ip、业务id
   

4. 怎么确定流量的阈值?

   观测、压测、估算、借鉴
   

5. 如何应对突发流量?

   令牌桶可以设置允许一定的突发流量
   

6. 被限流的请求会被怎么处理?

   直接的话就是返回499; 还要继续处理, 就可以等待、同步转异步
   

7. 为什么使用了限流，系统还是有可能崩溃?

   限流只是考虑了请求数量, 没有考虑请求本身对资源消耗的的大小
   

8. 我们有一个功能，对于普通用户来说，一些接口需要限制在每分钟不超过 10 次，整天不 能超过 1000 次;VIP 用户不限制。你怎么解决这个问题?

   基于id 区分用户, 基于 ip 进行 每分钟、每天限流
   

06 | 隔离:怎么保证尊贵的 VIP 用户体验不受损?

1. 什么是隔离，你用来解决什么问题?

   隔离是通过资源划分, 在不同服务之间建立边界, 防止相互影响的一种治理措施.
   

2. 你了解哪些隔离策略?你用过哪些?

   实例隔离、机房隔离、分组隔离、第三方依赖隔离
   

3. 当某个服务崩溃的时候，你有什么办法保证其它服务不受影响?

   服务隔离, 通过独立的资源分配, 确保一个服务的崩溃不会影响其他服务
   

4. 在使用线程池、连接池和协程池的时候，怎么避免业务之间相互影响?

   分组专用
   

07|超时控制:怎么保证用户一定能在1s内拿到响应?

1. 为什么要做超时控制?

   节省系统资源, 提高资源利用的效率.
   

2. 为什么缺乏超时控制有可能引起连接泄露、线程泄露?

   资源无法被有效使用
   

3. 什么是链路超时控制?

   整个调用链路使用一个超时时间控制
   

4. 如何确定超时时间?

   根据用户体验、根据响应时间、压力测试、根据代码计算
   

5. 怎么在链路中传递超时时间?

   协议头
   

6. 超时时间传递的是什么?

   剩余时间、时间戳
   

7. 如何计算网络传输时间?

   测试
   

8. 什么是时钟同步问题?

   如果时钟不一致, 传递超时时间戳会有问题
   

9. 客户端和服务端谁来监听超时?

   通常是客户端, 超时直接返回
   

10. 超时之后能不能中断业务?怎么中断?

    可以不中断、没有主动检测可以不中断.
    

08|调用第三方:下游的接口不稳定性能又差怎么办?

1. 如何保证调用第三方接口的可用性?

   因为调用第三方,可能不止一个相同功能的第三方,第一是要做好一致性抽象;
   第二是做好客户端治理,比容常见的策略就是熔断、限流、降级和超时控制;
   第三就是做好可观测性支持, 做好监控和报警.
   第四就是测试支持, 比如mock服务, 供调用方自测
   

2. 如果在出错的时候你会切换不同的第三方，但是如果全部第三方换一遍之后都崩溃了，怎 么办?

   no way
   

3. 调用第三方接口出错的时候，你是怎么重试的?重试次数和重试间隔你是怎么确定的?

   重试3次,每次重试间隔基于一个正常的响应时间的指数退避策略*2*x
   

4. 你怎么判定第三方服务已经非常不可用，以至于要切换一个新的第三方服务了?

   响应时间、错误率、超时率
   

5. 对时效性要求不高的接口，你可以怎么优化架构?

   临时存储请求、消息队列解耦
   

6. 在压力测试一个接口的时候，如果这个接口依赖了一个第三方接口，你怎么解决?

   mock 第三方
   

7. 公司业务依赖一个非常关键的第三方依赖，我要怎么保证我在调用第三方的时候不出错?

   熔断机制：
   - 使用熔断器（如 Hystrix）监控第三方服务的响应时间和错误率。
   - 当错误率或响应时间超过阈值时，触发熔断，直接返回默认值或错误，避免继续发送请求。
   限流机制：
   - 对请求进行限流，限制每秒的最大请求数，避免过多请求压垮第三方服务。
   - 可以使用令牌桶或漏桶算法实现。
   降级策略：
   - 在第三方服务不可用时，提供默认值或缓存数据。
   - 例如，返回静态页面、默认推荐内容，或提示稍后重试。
   重试机制：
   - 对失败的请求进行有限次数的重试，避免因网络抖动导致的偶发性失败。
   - 使用指数退避策略增加重试间隔，减少对第三方服务的压力。
   异步解耦：
   - 使用消息队列（如 Kafka、RabbitMQ）将请求异步化，减少对第三方服务的直接依赖。
   - 请求失败时可以将消息存储到队列中，稍后重试。
   多服务冗余：
   - 配置多个第三方服务，支持快速切换。
   - 例如，使用 DNS 或负载均衡器切换到备用服务。
   监控与告警：
   - 实时监控第三方服务的响应时间、错误率、超时率。
   - 设置告警机制，及时发现问题并采取措施。
   测试与演练：
   - 定期进行压力测试，模拟高并发场景，验证容错机制的有效性。
   - 演练第三方服务不可用的场景，确保系统能够平稳降级。