微服务架构

一、知识体系

1. 微服务基础 ★★

1.1 单体 vs 微服务

• 核心结论
  • 单体的优势是研发链路短、部署简单、调试方便，适合业务早期或团队规模较小时快速迭代。
  • 微服务的核心收益不是“技术更先进”，而是让系统边界、团队边界和发布边界逐步对齐。
  • 微服务的代价也非常真实，包括分布式事务、链路调试、容量治理、组织协作和平台建设成本。
• 原理展开
  • 单体架构的问题通常不是代码一定写不好，而是随着业务复杂度上升，任何一个模块上线都需要整包发布，局部变更会放大为全局风险。
  • 微服务把模块间调用从进程内调用变成网络调用，换来了独立部署和独立扩容，但也引入了超时、重试、幂等、注册发现、链路追踪这些新问题。
  • 真正适合拆分的前提一般是业务边界已经逐渐稳定，且不同模块的迭代节奏、性能瓶颈、团队职责开始明显分化。
• 面试怎么答
  • “单体和微服务不是先进落后的关系，而是不同阶段的工程权衡。单体赢在简单，微服务赢在边界清晰和独立演进。只有当业务复杂度、团队规模、发布节奏都逼着系统解耦时，拆微服务才真正有价值。”
• 易错点
  • 过早拆分会先得到复杂度，后得到收益。
  • 不是把应用拆成多个进程就叫微服务，真正关键的是边界、自主发布和独立治理能力。

1.2 服务拆分原则 ★★★

单一职责、高内聚低耦合

• 核心结论
  • 服务拆分首先是业务边界设计，不是代码包结构拆分。
  • 一个服务最好只承担一类清晰职责，对外暴露稳定能力，对内保持自己的数据和演进节奏。
• 原理展开
  • 如果一个服务同时承担订单、库存、营销等多种职责，就会出现需求互相影响、发布互相牵连的问题。
  • 高内聚低耦合在微服务里意味着“内部变化尽量不扩散到外部”，包括 API、消息模型、数据结构都要尽量稳定。
• 面试怎么答
  • “我会先看业务职责是否单一，再看是否能形成稳定接口和独立数据边界。如果一个服务总是和别的服务一起发版、一起改表，通常边界还没拆对。”

按业务领域拆分，而不是按技术层拆分

• 核心结论
  • 微服务边界更适合按领域能力划分，而不是拆成“用户服务、DAO 服务、公共工具服务”这种技术层服务。
• 原理展开
  • 技术层拆分会让一次业务请求在多个基础服务之间来回穿梭，导致调用链过长、职责模糊，最后既没有复用价值，也没有清晰边界。
  • 结合 DDD 看，限界上下文是天然候选边界；统一语言发生变化的地方，往往就是服务边界要切开的地方。
• 面试怎么答
  • “我更偏向按业务能力和领域边界拆，而不是按技术层拆。按技术层拆最容易得到一堆共享服务，最后所有业务都耦合在一起。”

拆分粒度怎么把握

• 核心结论
  • 粒度太粗，失去独立演进价值；粒度太细，分布式成本会迅速吞掉收益。
• 原理展开
  • 判断粒度时通常会同时看三个维度：业务是否独立、数据是否独立、团队是否能独立负责。
  • 一个经验判断是：一个 2-3 人小团队能否独立维护、独立发布、独立排障。如果不能，边界可能还不稳定。
• 面试怎么答
  • “我不会用固定规则定粒度，而是看业务边界、数据边界、团队边界是否一致。最终目标不是拆得越细越好，而是拆到能独立负责、独立发布、独立扩容。”
• 易错点
  • 把公共代码抽成公共服务往往是反模式，优先抽 SDK 或中台能力，不要轻易引入一层远程依赖。

数据库要不要拆分

• 核心结论
  • 服务拆分最终要走向数据自治，但数据库拆分通常要和业务边界、查询模式、迁移成本一起评估，不能机械“一拆服务就拆库”。
• 原理展开
  • 服务不拆库时，虽然能先降低迁移难度，但后期容易出现跨服务直接联表、边界被数据库反向侵蚀。
  • 真正成熟的微服务体系通常强调“一服务一库或一逻辑库边界”，跨服务数据通过接口、消息或同步链路获取，而不是直接跨库访问。
• 面试怎么答
  • “我的原则是服务边界先行，数据自治是目标，但落地可以分阶段。早期可以先逻辑拆分，后面再逐步做物理拆库，关键是禁止跨服务直接改对方数据。”

2. Spring Cloud体系 ★★★

2.1 核心组件

注册中心：Eureka / Nacos / Consul

• 核心结论
  • 注册中心的本质是维护服务实例列表和健康状态，让调用方拿到可用地址，而不是把地址硬编码在配置里。
• 原理展开
  • 服务启动后向注册中心注册自己，并持续发送心跳；消费者定期拉取或订阅实例变更，再结合客户端负载均衡完成路由。
  • Nacos 的价值在于同时覆盖注册发现和配置中心，并且支持 AP/CP 模式切换；Eureka 更偏 AP 和高可用；Consul 更偏一致性和多场景服务发现。
• 面试怎么答
  • “我会先从 CAP 权衡讲，再落到业务场景：核心链路一般更看重可用性，所以服务发现常选 AP；对强一致元数据要求更高时再考虑 CP。”
• 易错点
  • 注册中心不是流量转发节点，大多数场景它不在请求主链路上，挂掉后短时间内服务通常仍能靠本地缓存继续调用。

配置中心：Nacos Config / Apollo / Spring Cloud Config

• 核心结论
  • 配置中心的目标不是集中存文件，而是把配置治理做成可审计、可灰度、可回滚的系统能力。
• 原理展开
  • 动态配置刷新通常依赖监听机制 + Environment 更新 + Bean 刷新；但不是所有配置都适合动态刷新，数据库连接池、线程池等要区分热加载边界。
  • 线上更重要的是版本管理、灰度发布、权限控制和回滚能力，而不是“能不能实时推送”。
• 面试怎么答
  • “配置中心我重点看三件事：配置是否能按环境和应用隔离，变更是否可审计可回滚，动态刷新是否有明确边界，避免把本该重启生效的配置强行热更。”

负载均衡：Ribbon / Spring Cloud LoadBalancer

• 核心结论
  • 微服务里常见的是客户端负载均衡，消费者拿到实例列表后本地做选择，这样少一跳代理，扩展性更好。
• 原理展开
  • 常见策略包括轮询、随机、权重、最少连接、一致性 Hash。真正线上选型要结合接口特征，比如缓存命中、会话粘性、节点异构能力。
  • Spring Cloud 新体系更多使用 Spring Cloud LoadBalancer 替代 Ribbon。
• 面试怎么答
  • “客户端负载均衡的核心是实例列表来自注册中心，路由策略在调用端本地执行。策略不是越复杂越好，关键要跟流量模型匹配。”

服务调用：OpenFeign / RestTemplate

• 核心结论
  • Feign 的价值在于把 HTTP 调用封装成接口语义，降低模板代码，但底层仍然是网络调用，必须配置好超时、重试、连接池和降级策略。
• 原理展开
  • Feign 本质上通过动态代理把接口方法转换成 HTTP 请求，再结合编码器、解码器和负载均衡组件发起调用。
  • RestTemplate 更偏底层和手工，OpenFeign 更偏声明式调用；性能差异通常不是瓶颈，治理能力和团队规范才是重点。
• 面试怎么答
  • “Feign 本质是动态代理 + HTTP Client + 负载均衡，不会因为写成接口就没有网络成本。线上重点是超时、连接池、幂等重试和异常映射。”

API网关：Spring Cloud Gateway / Zuul

• 核心结论
  • 网关承担的是统一入口能力，包括路由、鉴权、限流、灰度、协议转换和统一观测，而不是把所有业务都堆进去。
• 原理展开
  • Gateway 基于 WebFlux + Netty，适合高并发异步场景，过滤器链一般分为全局过滤器和路由级过滤器。
  • 网关是系统治理核心点，但也容易成为大泥球，所以要把它限制在“流量治理层”，不要承载复杂业务编排。
• 面试怎么答
  • “我会把网关看成统一流量入口，负责鉴权、路由、限流、灰度和统一日志，不在这里堆业务逻辑，否则很快又做回单体。”

熔断降级：Sentinel / Hystrix / Resilience4j

• 核心结论
  • 熔断降级不是为了隐藏问题，而是为了把局部故障限制在可控范围内，避免把一个慢节点放大成全链路雪崩。
• 原理展开
  • 熔断器一般基于滑动窗口统计 RT、异常比例、异常数等指标，状态在 Closed、Open、Half-Open 之间切换。
  • Sentinel 在国内生态更常见，除熔断外还擅长流控、热点参数和系统保护；Hystrix 已停更，更多作为面试历史知识。
• 面试怎么答
  • “熔断的本质是先承认下游不稳定，再通过快速失败、隔离和恢复探测保护主链路。真正要讲的是判定指标、恢复策略和 fallback 的业务边界。”

2.2 Spring Cloud Alibaba ★★★

• 核心结论
  • Spring Cloud Alibaba 的价值在于把 Nacos、Sentinel、Seata、RocketMQ 等常见中间件整合成更符合国内团队习惯的一套微服务基础设施。
• 原理展开
  • Nacos 解决注册发现和配置管理，Sentinel 解决流量治理，Seata 处理分布式事务，RocketMQ 支撑异步解耦；这套组合天然适合“交易链路 + 流量治理 + 配置中心”的常见场景。
  • 选用时要注意版本兼容矩阵，尤其是 Spring Boot、Spring Cloud、Spring Cloud Alibaba 三者之间的匹配关系。
• 面试怎么答
  • “我会把 Spring Cloud Alibaba 看成适配国内中间件生态的整合方案，真正落地时重点不是组件名，而是版本兼容、治理边界和故障预案。”

3. Dubbo框架 ★★

3.1 核心架构

• 核心结论
  • Dubbo 是典型 RPC 框架，强调高性能服务调用、丰富治理能力和 SPI 扩展性，适合内部服务调用场景。
• 原理展开
  • Provider 暴露服务，Consumer 订阅服务，Registry 负责地址发现，Monitor 用于统计监控。
  • 它和 Spring Cloud HTTP 体系的主要差别，不只是协议，而是调用模型、治理方式和接口定义习惯不同。
• 面试怎么答
  • “Dubbo 更像内部高性能 RPC 体系，Spring Cloud 更偏 HTTP 微服务治理体系。实际项目里也可能同时存在，外部走 HTTP，内部核心链路走 RPC。”

3.2 核心特性

负载均衡与集群容错

• 核心结论
  • Dubbo 的治理能力很强，负载均衡和集群容错策略是面试高频点。
• 原理展开
  • Random 默认是加权随机，LeastActive 更适合处理节点处理能力不均，ConsistentHash 适合请求粘性。
  • 容错策略里的 Failover 适合读场景，Failfast 适合非幂等写操作，Forking 用可用性换资源。
• 面试怎么答
  • “我会把负载均衡和容错放一起答，因为真正线上要同时考虑路由怎么选和失败后怎么处理，而不是孤立地背几个策略名。”

SPI 扩展机制

• 核心结论
  • Dubbo 的可扩展性很大程度来自 SPI，它让协议、负载均衡、序列化、路由等能力都能按插件扩展。
• 原理展开
  • 与 JDK SPI 相比，Dubbo SPI 更强调按需加载、自适应扩展和 IOC 注入，便于框架做治理增强。
• 面试怎么答
  • “Dubbo SPI 不是简单的 ServiceLoader 包装，而是为了支撑框架级扩展点，既要能动态选择实现，也要能把扩展能力串到调用链里。”

3.3 Dubbo 3.x新特性

• 核心结论
  • Dubbo 3.x 重点是应用级服务发现、Triple 协议和更强的云原生兼容能力。
• 面试怎么答
  • “Dubbo 3.x 不只是版本升级，背后是从接口级注册逐步走向应用级治理，以及对 HTTP/2、云原生场景更友好的适配。”

4. 服务治理 ★★★

4.1 服务注册与发现 ★★★

注册中心选型：Nacos vs Eureka vs ZK vs Consul

• 核心结论
  • 选型本质是看可用性、一致性、生态整合、运维复杂度和团队经验，而不是追求唯一标准答案。
• 原理展开
  • Eureka 偏 AP，自我保护机制明显；Nacos 更均衡，兼顾注册和配置；ZooKeeper 强一致但不太适合承受大规模频繁心跳；Consul 在服务发现和健康检查上也很成熟。
• 面试怎么答
  • “如果是典型 Java 微服务，我会优先在 Nacos 和 Eureka 之间选。Nacos 赢在功能整合，Eureka 赢在理念简单。ZK 和 Consul更多看团队已有基础设施和一致性诉求。”

注册中心挂了，服务还能调用吗

• 核心结论
  • 通常能短时间继续调用，因为消费者和提供者本地都缓存了实例列表；真正受影响的是新实例注册、实例变更传播和长期一致性。
• 面试怎么答
  • “注册中心挂掉不等于服务立刻全挂，已有实例列表通常还能支撑一段时间。但这时系统进入退化状态，新节点不可见、坏节点可能无法及时剔除，所以要尽快恢复。”

优雅上下线

• 核心结论
  • 优雅上下线的目标是让流量切换和实例生命周期对用户尽量无感。
• 原理展开
  • 上线时通常先完成预热、缓存填充和依赖检查，再对外注册；下线时先摘流量、再等待在途请求处理完成，最后关闭进程。
• 面试怎么答
  • “我会把优雅上下线拆成注册层、流量层、进程层三个动作：先让实例不再接新流量，再排空在途请求，最后安全退出。”

4.2 链路追踪 ★★

• 核心结论
  • 链路追踪解决的是“请求经过了谁、每一跳耗时多少、错误落在哪一层”，本质是用 Trace 和 Span 把一次调用串起来。
• 原理展开
  • TraceId 标识一次完整请求，SpanId 标识链路中的单个片段，ParentSpanId 表示父子关系。
  • OpenTelemetry 正在逐步成为统一标准，SkyWalking、Zipkin、Jaeger 这些工具更多是不同的实现和生态选择。
• 面试怎么答
  • “追踪系统最核心的不是工具名，而是 TraceId 能否全链路透传、采样策略是否合理、埋点成本能否控制。”

4.3 服务网格(Service Mesh) ★★（P8+加分）

• 核心结论
  • Service Mesh 是把服务治理能力下沉到 Sidecar 或数据面代理，让业务代码少关心重试、熔断、mTLS、观测这些基础能力。
• 原理展开
  • Istio 体系里 Envoy 负责数据面流量转发，Istiod 负责控制面配置分发。
  • 它与 Spring Cloud 不是简单替代关系，更像是治理下沉和应用层框架的分工变化。
• 面试怎么答
  • “Mesh 的价值是治理下沉、语言无关和统一控制，但也会引入资源开销和平台复杂度。大部分团队不是直接替换 Spring Cloud，而是按场景互补使用。”

4.4 可观测性三支柱 ★★

• 核心结论
  • Metrics、Logging、Tracing 三者解决的问题不同，真正成熟的体系是三者打通，而不是各自孤立堆工具。
• 原理展开
  • 指标擅长发现异常，日志擅长定位细节，链路擅长还原路径。
  • 日志系统还要额外处理脱敏、采样、结构化输出和日志量控制，否则排障系统会先变成成本黑洞。
• 面试怎么答
  • “指标告诉我哪里有问题，链路告诉我问题发生在哪一跳，日志告诉我当时具体发生了什么。三者缺一个，定位效率都会明显下降。”

5. 容器化与云原生 ★★

5.1 Docker ★★

• 核心结论
  • Docker 的价值是把应用运行环境和依赖打包成可交付单元，提高环境一致性和交付效率。
• 原理展开
  • 与 VM 相比，Docker 共享宿主机内核，启动更快、资源更轻，但隔离粒度与安全边界也不同。
  • 多阶段构建、最小化基础镜像、分层缓存和只读根文件系统，是线上镜像治理的常见优化点。
• 面试怎么答
  • “Docker 不是只会写 Dockerfile，真正高频点是镜像怎么瘦身、容器怎么观察、配置和密钥怎么外置、发布怎么和平台结合。”

5.2 Kubernetes基础 ★★

• 核心结论
  • Kubernetes 解决的是容器编排问题，包括调度、扩缩容、服务发现、发布策略和声明式运维。
• 原理展开
  • Pod 是最小调度单元，Deployment 负责副本管理和滚动发布，Service 提供稳定访问入口，Ingress 负责七层入口流量。
  • Liveness、Readiness、Startup Probe 分别对应存活、就绪、启动阶段健康检查，理解它们的区别比背定义更重要。
• 面试怎么答
  • “K8s 我通常围绕调度、服务发现和发布策略来答，尤其是就绪探针、滚动发布和 HPA，这些和微服务稳定性直接相关。”

5.3 CI/CD ★

• 核心结论
  • CI/CD 的目标不是自动化本身，而是把构建、测试、发布、回滚做成稳定可重复流程。
• 面试怎么答
  • “我会重点讲流水线和发布策略如何降低变更风险，比如金丝雀、蓝绿、滚动发布，再补 GitOps 如何把发布动作收口到声明式变更。”

6. DDD领域驱动设计 ★★★（P8+核心）

6.1 战略设计

限界上下文

• 核心结论
  • 限界上下文的本质是给模型和语言画边界，同一个词在不同上下文里含义不同，就不应该强行共用一个模型。
• 原理展开
  • 例如“订单”在交易域关注履约和支付，在客服域关注查询与售后，在结算域关注对账；如果用一个统一对象覆盖所有语义，模型很快会失真。
• 面试怎么答
  • “限界上下文是微服务边界的重要来源，因为它同时定义了模型边界、团队协作边界和数据边界。”

6.2 战术设计

实体、值对象、聚合根

• 核心结论
  • 实体看身份，值对象看值，聚合根负责一致性边界和外部访问入口。
• 原理展开
  • 聚合内允许强一致事务，跨聚合更适合用事件和最终一致性衔接；否则服务一多，就会退化成跨服务大事务。
• 面试怎么答
  • “聚合根不是为了概念完整而设，它解决的是修改入口和一致性边界问题。哪些对象必须一起变更，哪些可以异步协同，这才是聚合设计的关键。”

6.3 DDD与微服务

• 核心结论
  • DDD 不是微服务的必选项，但它非常适合在业务复杂、概念容易混乱的系统里帮助划清边界。
• 原理展开
  • 限界上下文可以映射成服务边界，聚合可以映射成事务边界，领域事件天然适合做服务间解耦通信。
  • Event Sourcing 和 CQRS 是更重的武器，只有在审计、回放、复杂查询拆分等场景下才值得投入。
• 面试怎么答
  • “DDD 对微服务最大的帮助不是画图，而是让边界有业务依据，避免按组织结构或数据库表拍脑袋拆服务。”

---

二、高频面试题

基础级（P7必答）

1. 微服务和单体架构各自的优缺点？什么时候该拆微服务？

• 30秒答法
  • 单体优势是开发、测试、部署链路简单，适合业务早期快速试错；微服务优势是边界清晰、独立发布、独立扩容，但代价是分布式复杂度显著上升。一般在业务边界稳定、团队分工清晰、模块迭代节奏明显不同后再拆，而不是一开始就拆。
• 关键词
  • 发布耦合
  • 独立扩容
  • 分布式复杂度
  • 组织边界
• 追问提醒
  • 继续准备“拆分失败通常因为什么”和“如何判断过早拆分”。

2. 注册中心 Nacos 和 Eureka 的区别？AP 和 CP 怎么选？

• 30秒答法
  • Eureka 更偏 AP 和高可用，核心能力聚焦服务发现；Nacos 同时覆盖服务发现和配置中心，并支持 AP/CP 模式切换。服务发现一般更看重可用性，所以常优先 AP；如果是强一致元数据管理，再考虑 CP。
• 关键词
  • AP / CP
  • Distro
  • Raft
  • 配置中心整合
• 追问提醒
  • 继续准备“注册中心挂了会怎样”和“临时实例、持久实例的差别”。

3. Feign 的工作原理？如何实现负载均衡？

• 30秒答法
  • Feign 通过动态代理把接口调用转换成 HTTP 请求，再结合编码器、解码器和负载均衡组件发起调用。负载均衡一般是客户端模式，从注册中心拿到实例列表后按轮询、随机、权重等策略在本地选节点。
• 关键词
  • 动态代理
  • HTTP Client
  • 实例列表
  • 客户端负载均衡
• 追问提醒
  • 继续准备“超时、重试、幂等如何配合设计”。

4. 熔断器的三种状态？Sentinel 和 Hystrix 的区别？

• 30秒答法
  • 熔断器通常有 Closed、Open、Half-Open 三种状态，用于在异常比例或 RT 异常时快速失败，并在恢复阶段探测下游是否可用。Hystrix 已停更，Sentinel 在国内生态更常见，除了熔断还支持流控、热点参数和系统保护。
• 关键词
  • 滑动窗口
  • 快速失败
  • Half-Open
  • 流控
• 追问提醒
  • 继续准备“阈值怎么定”和“fallback 要不要兜底返回默认值”。

5. Spring Cloud Gateway 和 Zuul 的区别？

• 30秒答法
  • Gateway 基于 WebFlux 和 Netty，异步非阻塞，更适合高并发场景；Zuul 1.x 基于 Servlet，同步阻塞。面试里更重要的是讲清网关职责：统一路由、鉴权、限流、灰度和观测，而不是只背技术栈差异。
• 关键词
  • WebFlux
  • Netty
  • 过滤器链
  • 流量治理
• 追问提醒
  • 继续准备“网关为什么不能承载业务编排”。

6. Dubbo 的负载均衡策略？集群容错策略？

• 30秒答法
  • Dubbo 常见负载均衡有加权随机、轮询、最少活跃、一致性 Hash；容错策略有 Failover、Failfast、Failsafe、Failback、Forking。真正答题时要把策略和场景绑在一起，比如非幂等写操作更适合 Failfast，读场景常用 Failover。
• 关键词
  • Random
  • LeastActive
  • Failover
  • 幂等
• 追问提醒
  • 继续准备“一致性 Hash 适合什么场景”和“失败重试为什么可能放大问题”。

7. 微服务之间如何做服务鉴权？

• 30秒答法
  • 外部请求通常在网关统一做认证授权，服务间调用再透传用户身份或调用方身份；内部服务之间可结合 JWT、内部签名、mTLS、白名单和零信任策略。关键是减少重复鉴权，同时保证链路可追踪和权限边界清晰。
• 关键词
  • 网关统一鉴权
  • Header 透传
  • mTLS
  • 零信任
• 追问提醒
  • 继续准备“内部调用身份如何防伪造”。

8. 如何做微服务的优雅上下线？

• 30秒答法
  • 上线时先预热，再注册，再逐步放量；下线时先摘流量，再等在途请求处理完，最后再停进程。重点是把注册状态、负载均衡摘除、K8s 就绪探针和进程关闭钩子配合起来。
• 关键词
  • 预热
  • 摘流量
  • 在途请求
  • preStop
• 追问提醒
  • 继续准备“K8s readinessProbe 和优雅停机如何联动”。

9. 微服务拆分原则是什么？如何判断拆分粒度？

• 30秒答法
  • 原则是单一职责、高内聚低耦合、按业务领域拆分、尽量做到数据自治。粒度判断要看业务边界、数据边界和团队边界是否一致，目标不是拆得越细越好，而是拆到能独立负责、独立发布、独立扩容。
• 关键词
  • 领域边界
  • 数据自治
  • 康威定律
  • 独立发布
• 追问提醒
  • 继续准备“拆分后共享数据怎么办”。

10. K8s 的 Pod、Deployment、Service 分别是什么？滚动更新如何实现？

• 30秒答法
  • Pod 是最小调度单元，Deployment 负责副本和版本滚动管理，Service 提供稳定访问入口。滚动更新通过新旧 ReplicaSet 的渐进切换完成，并依赖 readinessProbe、maxSurge、maxUnavailable 控制切换速度和可用性。
• 关键词
  • Pod
  • ReplicaSet
  • readinessProbe
  • maxSurge
• 追问提醒
  • 继续准备“发布失败如何回滚”和“HPA 对滚动更新有什么影响”。

进阶级（P8+深挖）

1. 你在实际项目中是如何划分微服务边界的？用了 DDD 吗？

• 30秒答法
  • 我会先按业务流程和统一语言识别限界上下文，再看数据归属、团队职责和发布节奏是否一致。DDD 不是为了画模型，而是为了让“订单、库存、结算”这类概念在各自上下文里有清晰边界，避免服务拆分完全按数据库表或组织结构拍脑袋。
• 关键词
  • 限界上下文
  • 统一语言
  • 数据边界
  • 发布边界
• 追问提醒
  • 继续准备“一个术语在不同上下文语义不同怎么办”。

2. 微服务拆分后数据一致性问题你是怎么解决的？

• 30秒答法
  • 默认优先最终一致性，常见手段是本地消息表加 MQ、可靠事件发布、定时补偿和对账。只有强一致要求非常高的链路才考虑 TCC 或分布式事务框架，而且要严格控制范围，避免把所有链路都做成重事务。
• 关键词
  • 最终一致性
  • 本地消息表
  • 补偿
  • TCC
• 追问提醒
  • 继续准备“消息重复、乱序、幂等怎么处理”。

3. 服务网格和 Spring Cloud 是什么关系？你认为未来趋势是什么？

• 30秒答法
  • Spring Cloud 更像应用层 SDK 治理方案，Mesh 更像基础设施层治理下沉方案。二者并不是互斥关系，Mesh 更擅长流量治理、安全和观测统一，Spring Cloud 仍然负责应用装配和业务框架能力，短中期内更可能长期共存。
• 关键词
  • Sidecar
  • 治理下沉
  • 语言无关
  • 互补
• 追问提醒
  • 继续准备“为什么 Mesh 没有完全替代业务框架”。

4. 如何设计一个支持灰度发布的微服务架构？

• 30秒答法
  • 核心是全链路标签透传。网关按用户或请求标签路由到灰度实例，服务间调用继续透传标签，消息链路也要保留标签，数据层再通过影子表、逻辑隔离或特定租户标识防止污染。重点不只是入口路由，而是链路不串线。
• 关键词
  • 灰度标签
  • Header 透传
  • MQ 路由
  • 数据隔离
• 追问提醒
  • 继续准备“回滚时如何快速摘除灰度流量”。

5. 聚合根的边界如何确定？跨聚合的事务怎么处理？

• 30秒答法
  • 聚合根边界看一致性要求，必须一起成功或失败的对象放在同一聚合内；跨聚合尽量走事件和最终一致性，而不是同步大事务。这样才能把事务边界控制在服务和聚合内部，避免系统规模变大后事务链路失控。
• 关键词
  • 一致性边界
  • 聚合根
  • 领域事件
  • 最终一致性
• 追问提醒
  • 继续准备“如何判断两个实体一定要放进同一聚合”。

三、实战场景题（P8+重点）

1. 服务拆分：一个单体电商系统要拆微服务，你会怎么规划拆分步骤？数据库怎么处理？

• 回答框架
  • 先识别核心业务链路和限界上下文，确定首批拆分对象。
  • 先拆变化频率高、收益明显、风险可控的模块，不追求一步到位。
  • 数据层优先做逻辑隔离，再逐步走向物理拆库，期间严格禁止跨服务直连改数。
• 核心关注点
  • 边界是否按领域而不是按表拆。
  • 双写、迁移、回滚方案是否明确。
  • 拆分期间单体与微服务并存阶段的调用治理如何处理。

2. 全链路灰度：需要实现从网关到服务到中间件的全链路灰度发布，如何设计？

• 回答框架
  • 网关识别灰度规则并打标签。
  • RPC/HTTP/MQ 全链路透传标签。
  • 消费者、任务调度、缓存、数据库分别设计隔离或兼容策略。
• 核心关注点
  • 标签透传是否会丢。
  • MQ、异步任务、定时任务是否串线。
  • 灰度回滚是否足够快、是否支持按批次撤销。

3. 注册中心选型：你的系统有 200 个微服务、3000 个实例，注册中心怎么选？考虑什么因素？

• 回答框架
  • 先看可用性和一致性诉求，再看生态整合和运维经验。
  • 评估心跳规模、实例变更频率、配置中心需求和多机房部署方案。
  • 做容量压测和故障演练，不只看功能列表。
• 核心关注点
  • 高峰期实例抖动时是否稳定。
  • 控制面故障对业务面的影响范围。
  • 多机房、跨地域场景下的数据同步与容灾能力。

4. 服务雪崩：一个下游服务变慢导致整个调用链阻塞，如何设计防护机制？

• 回答框架
  • 先做超时、隔离、限流、熔断四层保护。
  • 再区分读写链路、核心非核心链路设计不同 fallback。
  • 最后通过观测和压测验证阈值是否合理。
• 核心关注点
  • 线程池是否被慢请求耗尽。
  • 重试是否放大故障。
  • fallback 是否真的有业务意义，而不是返回一堆假成功。

5. 微服务演进：你接手的系统从单体到微服务的演进路径是怎样的？遇到了哪些坑？

• 回答框架
  • 按演进阶段回答：单体治理、模块化、服务化、平台化。
  • 每个阶段分别说明收益、问题和补救动作。
  • 最后总结哪些坑来自技术，哪些坑来自组织协作。
• 核心关注点
  • 是否讲清“不是拆了就赢”，而是治理能力逐步补齐。
  • 是否能举出事务、观测、发布、边界失真等真实问题。
  • 是否能说明后来如何通过规范、平台和组织机制修正。

四、学习资源推荐

书籍

• 《微服务架构设计模式》：适合系统理解拆分、事务、Saga、观测和治理模式。
• 《领域驱动设计》：适合建立限界上下文、聚合和统一语言的原始认知。
• 《实现领域驱动设计》：更偏落地，对微服务边界设计帮助更直接。

博客/文章

• Spring Cloud Alibaba 官方文档：适合核对组件职责、版本矩阵和接入方式。
• Dubbo 官方文档：适合补 RPC 治理、SPI 和 3.x 新特性。
• OpenTelemetry 官方文档：适合理解追踪标准、采样和语义约定。

视频

• 极客时间《微服务架构核心 20 讲》：适合补体系化认知。
• 极客时间《DDD 实战课》：适合把领域建模和服务边界联系起来。