第4章 微服务架构设计与服务治理：服务拆分、限流熔断、服务网格
面试问题：你如何设计微服务的服务拆分？请结合项目经验说明。
面试官考察点：是否掌握领域驱动设计（DDD）；能否平衡粒度与复杂度；是否考虑数据一致性代价。
回答框架：① 业务领域建模（限界上下文）→ ② 按功能内聚拆分，每个服务职责单一 → ③ 明确数据边界，每个服务独享数据库 → ④ 匹配团队规模（2-8人）→ ⑤ 预留演进空间，先粗后细。
示例回答：采用DDD进行限界上下文划分，比如将订单服务与支付服务分离。每个服务独立数据库，粒度控制在两周可完成迭代的范围。初期避免拆分过细，后续根据业务增长逐步细化。
可能追问：拆分后如何保证数据最终一致性？如何解决跨服务事务？
面试问题：请描述你如何设计微服务的限流与熔断机制？
面试官考察点：算法选型依据（令牌桶/滑动窗口）；熔断恢复策略；降级兜底方案。
回答框架：① 确定限流维度（接口、用户、IP）→ ② 选择算法：高并发用令牌桶，平滑用滑动窗口 → ③ 熔断采用断路器模式，设置失败阈值和半开恢复时间 → ④ 降级返回默认值/缓存 → ⑤ 支持动态配置调整阈值。
示例回答：使用Redis实现令牌桶做接口级限流，QPS峰值5000时单接口限流2000。熔断采用Sentinel，错误率超50%则开启断路器，半开后先放行少量请求测试恢复。
可能追问：如何实现分布式场景下的全局限流？熔断恢复时间如何设置避免雪崩？
面试问题：服务网格相比传统微服务治理有哪些优势？你在实际项目中如何评估是否引入？
面试官考察点：对Istio/Sidecar的理解；能否辩证看服务网格的代价与收益。
回答框架：① 治理能力下沉到基础设施层，业务无侵入 → ② 统一流量管理、安全、可观测性 → ③ 降低多语言治理成本 → ④ 代价：增加运维复杂度、延迟开销 → ⑤ 评估：仅当微服务超过20个或强治理需求时才推荐。
示例回答：服务网格通过Sidecar代理实现服务间通讯，业务代码无需修改即可进行流量控制。我们在电商订单域引入Istio后，灰度发布和故障注入效率提升50%。但小规模项目不建议，运维成本较高。
可能追问：Istio控制面包含哪些组件？Sidecar劫持流量时如何避免性能损耗？
知识速查表：限流算法对比
| 算法 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 令牌桶 | 固定速率放入令牌，取令牌通过 | 允许突发流量 | 实现稍复杂 | 高QPS接口、突发型业务 |
| 滑动窗口 | 窗口内计数，滑动重置 | 精准平滑 | 内存开销大 | 秒杀、严格控制速率 |
| 漏桶 | 请求进入桶，固定速率流出 | 整形效果强 | 不能应对突发 | 流量整形、保护下游 |
| 计数器 | 固定时间窗口计数 | 实现简单 | 有毛刺问题 | 低要求、快速接入 |
真实项目案例：电商订单服务微服务改造
项目名称：电商订单平台微服务化与治理升级
业务背景：原单体订单系统月均100万订单，大促时QPS飙升导致经常超时；需拆分为独立订单、支付、库存服务，并建设限流熔断能力。
规模指标：日均订单100万，峰值QPS 5000；服务数从1个拆至8个；部署节点50+。
技术栈：Go 1.21 + gRPC + Redis + Sentinel + Istio + Kafka (事件驱动)
核心难点：订单创建与库存扣减的最终一致性、大促秒杀时限流阈值动态调整、熔断恢复后避免流量冲击。
面试高频追问：
Q: 如何保证订单创建与库存扣减的最终一致性？
回答：采用本地消息表+Kafka事件驱动，订单服务创建订单后写入本地消息表，消费端异步扣减库存并回写状态，配合定时任务补偿失败消息。
Q: 限流阈值如何动态调整？
回答：通过配置中心（Nacos）动态下发限流规则，Sentinel支持实时修改，每次发布前模拟压测验证新阈值。
可迁移回答话术：
“在订单服务改造中，我们遵循DDD限界上下文拆分，每个服务独立数据库。限流采用令牌桶+滑动窗口组合，熔断使用Sentinel断路器配合指数退避恢复。对于一致性，通过事件驱动和本地事务表实现最终一致性。这套方案后来也被推广到公司其他业务线。”