微服务架构设计

1. 怎么划服务边界？2. 粒度多细合适？3. 共享库 vs 共享库耦合怎么破？4. 拆分顺序与数据怎么迁？5. 拆完后分布式事务怎么治？

第一步：分析。拆分目标不是「多服务」，而是独立部署、独立演进、故障隔离。边界按业务能力（DDD 限界上下文）划，而非技术层。

第二步：挑战。边界模糊致耦合；粒度太细→运维/事务爆炸；数据库难拆；团队协作模式要变。

第三步：架构。按领域划分：用户、商品、库存、订单、支付、营销、物流。先绞杀者模式抽边缘域（商品/营销），核心交易最后拆；数据库按域垂直拆，共享表建为独立服务（如用户中心）。

第四步：选型。Spring Cloud Alibaba（Nacos/OpenFeign/Sentinel）+ DDD 限界上下文 + 绞杀者迁移。

第五步：一致性。跨域用最终一致（事件/Outbox）；强一致仅限域内。

第六步：高可用。拆分即隔离；核心域独立资源池；灰度迁移。

第七步：优化。「先宽后窄」：先粗粒度（8~12 域）跑通，再按热点细分；避免过度微服务（康威定律匹配团队）。

为什么 DDD 限界上下文？它是业务语义边界，比技术分层更稳。粒度：一个服务应由一个 2-pizza 团队维护；常见 8~15 个域起步，避免「一个接口一个服务」。共享库陷阱：把公共实体打成 jar 共享→改一处全编译，应改为「共享服务 + 防腐层（ACL）」。

// 防腐层：订单域调用用户域，不依赖其模型
public interface UserClientACL {
    UserSnapshot get(Long uid);  // 返回本域所需最小字段
}
// 绞杀者：老单体路由逐步切到新服务（Gateway 权重）
// 迁移顺序由依赖度决定：被依赖少的先拆

1. 雪崩是怎么形成的？2. 舱壁、熔断、限流、降级分别治什么？3. 超时怎么设？4. 熔断阈值怎么定？5. fallback 怎么写才不丢数据？

第一步：分析。雪崩 = 一个慢依赖耗尽调用方资源 → 调用方变慢 → 上游资源耗尽，连锁。四件套：限流（入口）、舱壁（隔离）、熔断（快速失败）、降级（保核心）。

第二步：挑战。资源耗尽、连锁、误判、降级丢数据。

第三步：架构。①每下游独立线程池（舱壁）；②调用设超时（如 300ms）+ 重试有限；③错误率超阈值熔断（Sentinel/Resilience4j），半开探测恢复；④非核心降级 fallback；⑤入口限流防过载。

第四步：选型。Sentinel（限流/熔断/降级）+ Resilience4j（舱壁/重试）+ OpenFeign 集成。

第五步：一致性。熔断/降级只影响非核心；核心数据写仍需成功（排队/异步补偿）。

第六步：高可用。隔离防扩散；熔断防雪崩；超时防挂死。

第七步：优化。超时=依赖 P99×安全系数；熔断配最小请求数防抖动误判。

熔断 vs 舱壁：舱壁防「一个慢依赖拖垮整个线程池」，熔断防「下游已死还持续打」。两者互补。超时：不设=线程永久挂起=雪崩；设太短=误熔断。用 P99+余量。fallback：非核心返回默认值/缓存；核心走异步队列稍后补。

// OpenFeign + Sentinel 熔断降级
@FeignClient(name = "user-svc", fallback = UserFallback.class)
public interface UserClient { @GetMapping("/auth") AuthResult auth(Long uid); }
// 独立线程池（舱壁）
ThreadPoolExecutor userPool = new ThreadPoolExecutor(20, 20, 60s, queue, reject→ fallback);
// 超时：RestTemplate/WebClient 设 connect/read timeout = 300ms

1. 网关和 BFF 区别？2. 网关放哪些能力、不放哪些？3. 聚合接口放哪？4. 网关成为瓶颈/单点怎么办？5. 灰度在网关怎么做？

第一步：分析。网关=横切（鉴权/限流/路由/灰度）；BFF=面向前端的聚合编排层，按端定制。

第二步：挑战。能力边界；聚合位置；网关瓶颈；灰度。

第三步：架构。①Gateway（Spring Cloud Gateway）：鉴权、限流、路由、灰度路由、日志；②BFF 层（按端：app-bff/web-bff）聚合多个后端域，减少前端往返；③后端域只暴露领域 API，不感知端。

第四步：选型。Spring Cloud Gateway（WebFlux 异步）+ Nacos（路由/灰度配置）+ BFF 独立服务。

第五步：一致性。网关不持有业务状态；鉴权结果透传（JWT/上下文）；灰度靠路由权重。

第六步：高可用。网关多实例 + LVS/SLB；无状态；限流防过载；BFF 按端独立部署互不影响。

第七步：优化。网关只做轻量（鉴权用本地公钥验签）；重聚合下沉 BFF；避免网关成业务层。

网关 vs BFF：网关关注「通用横切 + 路由」，BFF 关注「前端体验聚合」。把聚合放网关会让网关变胖变慢、难维护。为什么异步 WebFlux？网关高并发 IO 密集，响应式非阻塞提升吞吐、降资源。灰度：网关按 header/用户标签路由到新版本实例。

// Gateway 灰度路由：按 header 版本路由
@Bean public RouteLocator routes(RouteLocatorBuilder b) {
  return b.routes()
    .route("order-v2", r -> r.header("x-version", "v2")
        .uri("lb://order-svc-v2"))
    .route("order", r -> r.alwaysTrue().uri("lb://order-svc"))
    .build();
}
// BFF 并行聚合（CompletableFuture）
CompletableFuture<User> u = userClient.get(uid);
CompletableFuture<List<Order>> o = orderClient.list(uid);

1. Nacos/Eureka/ZK/Consul 怎么选？2. 健康检查怎么做才不误剔？3. 注册中心挂了服务还能调吗？4. 多机房怎么就近调用？5. 临时实例 vs 持久实例？

第一步：分析。注册中心是「系统的电话簿」，核心矛盾是 一致性 vs 可用性（CAP）：ZK/CP 强一致但分区时不可用；Nacos（可配 AP/CP）/Eureka（AP）优先可用性。

第二步：挑战。误剔、注册中心挂、跨机房延迟、一致性选择。

第三步：架构。①选 Nacos（AP 模式）做注册发现（优先可用，容忍短暂不一致）；②健康检查：客户端心跳 + 服务端探测，设合理超时（如 15s×3）防抖动误剔；③本地缓存：消费者缓存实例列表，注册中心挂仍可调用；④就近路由：按 zone/region 优先同机房；⑤保护阈值：健康实例比例过低时保留全部，防雪崩剔除。

第四步：选型。Nacos（AP 注册 + 配置）；Eureka（纯 AP 备选）；ZK 用于强一致协调（如选主）。

第五步：一致性。AP 模式允许短暂脏列表，靠客户端重试+健康检查自愈；强一致场景用 CP/ZK。

第六步：高可用。注册中心 3/5 节点集群；消费者本地缓存兜底；多级降级。

第七步：优化。保护阈值 + 心跳间隔调优防误剔；就近路由降延迟。

为什么 AP？注册中心挂比「短暂脏列表」危害小；AP 保证注册中心故障时服务仍可互调。保护阈值：当健康实例 < 阈值（如 80%），不再剔除，宁可负载高也不让流量无路可走。临时 vs 持久：临时实例靠心跳（进程死即删），持久实例手动（如 DB、配置）。

// Nacos 保护阈值：健康比例过低保留全部实例
// application.yml
spring.cloud.nacos.discovery: health-check-interval: 5  # 秒
# 控制台设 protect-threshold: 0.8
// 消费者：启用本地缓存+就近（同 cluster 优先）
// NacosDiscoveryClient 默认带本地缓存，注册中心挂仍可读取

1. 蓝绿/滚动/金丝雀区别？2. 全链路灰度怎么保证同用户打到同一版本？3. 灰度流量怎么打标传递？4. DB 变更怎么灰度（不兼容怎么办）？5. 回滚怎么做快？

第一步：分析。灰度=用小流量验证新版本，错误半径可控。难点在全链路：一个请求经过多服务，必须「打标→透传→路由」一致。

第二步：挑战。多服务版本一致性；标传递；DB 不兼容变更；快速回滚。

第三步：架构。①网关按用户标签（uid%100）路由到灰实例；②灰度标写入请求上下文透传（OpenTelemetry baggage / 自定义 header）；③各服务按标路由到同版本；④DB 变更：先加字段（兼容）→ 双写 → 迁读 → 删旧（扩展式迁移）；⑤回滚：保留旧版本实例 + 路由权重一键回 0。

第四步：选型。Nacos（权重）+ Spring Cloud Gateway（路由）+ OTel（标透传）+ K8s（多版本 Deployment）。

第五步：一致性。灰度标全链路透传保证「用户 x 全程同版本」；DB 兼容式变更保证新旧并存。

第六步：高可用。灰度故障仅影响小流量；监控对比新旧；自动熔断异常版本。

第七步：优化。基于指标（错误率/RT）自动推进/回滚；影子流量（复制真实流量到新版本比对）。

蓝绿 vs 金丝雀：蓝绿是整量切换（快但错误半径大），金丝雀是逐步放量（安全但慢）。全链路灰度必须金丝雀+标透传。DB 不兼容变更：绝不能「改列类型一步到位」，要扩展式三阶段，保证新旧版本同时可读写。

// 灰度标透传：ThreadLocal + Feign 拦截器
public class GrayInterceptor implements RequestInterceptor {
  public void apply(RequestTemplate t) {
    t.header("x-gray", GrayContext.get()); // 透传标
  }
}
// DB 兼容式：先加新字段，旧逻辑照常；新版本读新字段，逐步切换

1. 超时怎么设才合理？2. 重试为什么危险、怎么安全重试？3. 调用链 RT 怎么预算？4. 下游依赖怎么分级？5. 重试幂等怎么保证？

第一步：分析。调用治理=「超时预算 + 安全重试 + 分级降级」，目标是错误不放大、延迟可预期。

第二步：挑战。超时叠加、重试风暴、非幂等重试致脏数据。

第三步：架构。①超时预算：订单总 RT 预算 500ms，按调用链分配（库存 150ms、优惠 100ms、用户 80ms），用 Context 级联超时（如 gRPC deadline）；②重试：仅对超时/5xx（非业务 4xx），指数退避+抖动+上限（≤2 次），且必须幂等；③分级：强依赖（支付）fail-fast，弱依赖（推荐）降级；④熔断配合。

第四步：选型。OpenFeign + Sentinel（超时/熔断）+ Resilience4j（重试/退避）+ 上下文超时传递。

第五步：一致性。重试只针对可重试错误；幂等键防重复副作用。

第六步：高可用。超时防挂死；重试上限防风暴；降级保核心。

第七步：优化。超时基于各依赖 P99 实测；重试配 token bucket 限重试流量。

为什么级联超时？上游超时到了，下游还在跑=浪费+可能重复。用 deadline 让下游提前取消。重试风暴：每层重试 N 次，链路 M 层 → N^M 倍请求。必须限制总重试且退避。幂等：非幂等接口重试会重复扣款，必须带幂等键。

// 重试装饰：仅超时/未知异常，退避，上限2，要求幂等
RetryConfig rc = RetryConfig.custom()
  .maxAttempts(2).waitDuration(Duration.ofMillis(100))
  .retryOnException(e -> e instanceof TimeoutException
                    || e instanceof UnknownError).build();
Supplier<R> s = Retry.decorateSupplier(Retry.of("inv", rc), () -> client.call(req.withIdempotKey()));
// 调用链路减法超时（父剩 200ms 则子最多 200ms）

1. 微服务为什么不能跨库 JOIN？2. 冗余数据怎么保证不脏？3. CQRS 怎么落地？4. 聚合查询一致性怎么妥协？5. 冗余存储成本？

第一步：分析。微服务「数据私有」，跨域查询需冗余/物化视图或CQRS：写走领域，读走聚合视图。

第二步：挑战。跨库 JOIN、冗余一致性、聚合可用性。

第三步：架构。①数据冗余：订单域通过事件（用户改名→UserUpdatedEvent）更新本地冗余用户昵称，读时无需跨服务；②CQRS：写模型（规范化的领域库）+ 读模型（宽表/ES 聚合视图），通过 CDC/事件同步；③聚合服务：BFF 并行调各域拼装，单域挂用缓存/默认值兜底。

第四步：选型。CDC（Canal/Debezium）→ MQ → 读模型（ES/宽表）；事件驱动冗余。

第五步：一致性。读模型最终一致（秒级）；关键字段（金额）以领域库为准，冗余仅展示。

第六步：高可用。冗余解耦，单域挂读视图仍可用；聚合降级。

第七步：优化。宽表减少 JOIN；缓存热点聚合；冗余字段最小化。

为什么冗余？跨服务实时 JOIN 既破坏封装又耦合可用性。冗余以空间换解耦+性能。CQRS：读写模型分离，写侧重规范一致，读侧重性能与聚合。一致性妥协：展示字段允许秒级延迟（昵称改了订单页稍后更新），金额等强一致字段不走冗余。

// 监听用户改名事件，更新订单读模型冗余字段
@RocketMQMessageListener(topic = "user-updated")
public void on(UserUpdatedEvent e) {
  orderReadMapper.updateNickname(e.uid(), e.nick()); // 幂等按 eventId
}
// 读：直接查宽表，不跨服务
OrderDetail d = orderReadMapper.selectWide(orderId);

1. 怎么保证接口变更不破坏调用方？2. 兼容性原则？3. 契约测试怎么做？4. 版本怎么管（URL/Header）？5. 破坏性变更怎么平滑？

第一步：分析。微服务接口是契约，变更需向后兼容或显式版本演进，靠规范 + 契约测试兜住。

第二步：挑战。隐式变更、多调用方、破坏性升级。

第三步：架构。①兼容性规则：只增字段（不删不改名不缩类型），老调用方忽略新字段；②契约测试：Pact 等 consumer-driven，CI 中校验 provider 满足 consumer 期望；③版本：优先「加字段兼容」，必须破坏性变更才升主版本（/v2 或 header），双版本并存过渡；④变更评审：接口变更走评审+影响面扫描。

第四步：选型。Pact（契约测试）+ OpenAPI（规范）+ CI 卡点 + 网关版本路由。

第五步：一致性。契约即接口事实标准；测试保证 provider/consumer 对齐。

第六步：高可用。兼容变更零停机；破坏性变更双版本平滑。

第七步：优化。接口文档自动化（Swagger）；影响面工具扫描调用方。

为什么 consumer-driven？provider 不知道所有 consumer 怎么用，让 consumer 定义期望，provider 在 CI 校验，才能防「改了不知谁挂」。兼容性：JSON/Protobuf 对「加 optional 字段」天然兼容；改名/改类型是破坏性的，必须版本化。

// Consumer 定义契约期望（Pact JVM）
@Pact(consumer = "order-web") RequestResponsePact p(PactDslWithProvider b){
  return b.given("order exists").uponReceiving("get")
    .path("/orders/1").willRespondWith().status(200)
    .body("{\"id\":1,\"amount\":100}").toPact(); // amount 为新增兼容字段
}
// CI: provider 校验满足该契约，否则发布失败

1. 三种隔离模式怎么选？2. 共享库怎么防越权？3. 大租户独占怎么切？4. 租户路由怎么做？5. 成本怎么平衡？

第一步：分析。多租户核心矛盾：隔离性 vs 成本。三种模式：独立库（隔离最强最贵）、共享库+租户ID（最省但易串）、混合（大独占小共享）。

第二步：挑战。越权、成本、弹性、路由。

第三步：架构。①混合隔离：小租户共享库（行级 tenant_id 隔离+强制过滤），大租户独立 schema/库；②租户路由：登录后 tenant_id 写入上下文，MyBatis 拦截器自动拼 tenant_id（防漏写）；③资源配额：按套餐限流/配额；④大租户迁移：达到阈值自动迁独立库。

第四步：选型。共享 MySQL+tenant_id 行隔离；独立库按租户；MyBatis 拦截器强制租户过滤；连接池按租户分组。

第五步：一致性。租户上下文全程透传；所有查询强制带 tenant_id，防越权。

第六步：高可用。大租户独立资源防「吵闹邻居」；共享池配额隔离。

第七步：优化。按租户数据量自动升降级隔离级别；冷热分离降本。

三种模式权衡：独立库运维/成本高但合规强；共享库省但靠纪律（一行漏写 tenant_id 就串数据）；混合最务实。防越权关键：别指望业务代码每次写对，用拦截器在 SQL 层强制注入 tenant_id，业务无感知且不可绕过。

// MyBatis 拦截器：所有查询自动注入 tenant_id（防漏写越权）
@Intercepts({@Signature(type=Executor.class, method="query", args={...})})
public class TenantInterceptor implements Interceptor {
  public Object intercept(Invocation i){
    BoundSql sql = ...; String newSql = appendTenant(sql, TenantContext.get());
    return i.proceed(); // 用 newSql 替换
  }
}

1. Mesh 解决什么问题、代价是什么？2. Sidecar 性能损耗？3. 什么时候不该用 Mesh？4. 与 SDK 治理怎么过渡？5. 多语言收益怎么算？

第一步：分析。Mesh 把治理从 SDK 下沉到 Sidecar（Envoy），统一多语言治理、独立演进。代价是复杂度+延迟+资源。

第二步：挑战。性能损耗、运维复杂度、迁移成本、价值论证。

第三步：架构。①控制面（Istio）下发规则，数据面（Envoy Sidecar）透明拦截流量做熔断/限流/mTLS/追踪；②渐进落地：先非核心域，用 SDK+Mesh 双模共存，治理规则统一抽象；③性能：Sidecar 增 ~1-3ms RT、每实例多 0.5-1 vCPU，需容量评估。

第四步：选型。Istio（K8s 原生）+ Envoy；或轻量（如 MOSN/自研 sidecar）。单语言纯 Java 可考虑 SDK（Spring Cloud）更省。

第五步：一致性。治理规则统一下发；mTLS 保证服务间零信任。

第六步：高可用。Sidecar 故障本地降级（passthrough）；控制面 HA。

第七步：优化。Sidecar 资源限额；协议优化（HTTP/2、gRPC）；只注入需要的服务。

为什么上 Mesh？多语言+治理统一演进是核心收益；纯 Java 单栈用 Spring Cloud SDK 更轻。代价：Sidecar 每实例常驻资源、RT +1~3ms、运维门槛高（需 K8s 熟练）。过渡：双模，规则抽象层兼容 SDK 与 Mesh，逐步切。

// 治理规则统一抽象（SDK/Mesh 皆可驱动）
interface TrafficPolicy { // 限流/熔断规则，Mesh 与 SDK 共用语义
  void apply(CircuitBreaker cb, RateLimit rl);
}
// K8s VirtualService 示例（Istio）：
// apiVersion: networking.istio.io/v1beta1  kind: VirtualService
// 限流/熔断在控制面配置，应用无感知