子单元 2：微服务架构设计与服务治理（深化考点：DDD 拆分、服务容错策略、网关限流）
一、剧情核心冲突与细节
微服务拆分阶段，团队出现严重分歧：后端工程师小赵主张 “按功能模块拆分”，将 “用户注册、登录、信息管理” 合并为 “用户服务”，开发效率高；但架构师助理小林坚持 “按领域模型拆分”，认为应将 “用户认证” 独立为 “身份服务”，“用户信息管理” 归属 “用户中心服务”，理由是未来可能对接第三方认证平台（如微信、支付宝登录）。双方各执一词时，测试团队反馈：模拟 “库存服务宕机” 场景，发现预约服务持续重试调用，导致线程池耗尽，整个预约功能瘫痪，服务容错机制亟待完善。
二、知识点融入与解决路径（深化技术细节）
DDD 驱动的微服务拆分实操：林悦带领团队开展 “事件风暴” 工作坊，通过 4 步完成拆分：①识别领域事件（如 “用户注册成功”“订单支付完成”）；②梳理聚合根（如 “用户”“订单”“商品”）；③划分限界上下文（按 “用户域、订单域、商品域、客流域、数据域、营销域”）；④确定微服务边界。最终拆分出 12 个微服务，其中 “身份服务” 独立负责认证授权，通过 OAuth2.0 协议对接微信、支付宝登录，未来扩展第三方认证无需修改其他服务；“用户中心服务” 专注用户信息管理，两者通过 REST API 通信，接口定义遵循 OpenAPI 3.0 规范。
服务容错的 “三级防护” 策略：
一级防护：超时控制：所有服务间调用设置超时时间（同步调用 1 秒，Feign 客户端配置 readTimeout=1000ms），避免线程阻塞；
二级防护：熔断降级：Sentinel 配置 “熔断策略 = 慢调用比例”，慢调用阈值 = 500ms，比例阈值 = 0.5，熔断时长 = 5 秒 —— 当库存服务慢调用比例超 50% 时，触发熔断，预约服务立即返回 “当前库存查询繁忙，请稍后再试” 的降级响应；同时为降级响应配置 “静态化处理”，提前缓存降级提示语到本地，避免熔断时频繁创建响应对象；
三级防护：舱壁模式：采用线程池隔离，为调用库存服务、支付服务的请求分配独立线程池（核心线程数 = 20，最大线程数 = 50），即使库存服务线程池耗尽，也不影响预约服务调用其他服务的线程资源。
API 网关的 “精细化限流” 设计：Spring Cloud Gateway 配置多维度限流：①按 IP 限流：单 IP 每分钟最多 100 次请求，防止恶意攻击；②按接口限流：预约接口 QPS=2000，商品查询接口 QPS=5000，差异化分配流量；③按用户等级限流：VIP 用户预约接口 QPS=50，普通用户 QPS=10，保障高价值用户体验。限流算法采用 “令牌桶算法”，支持突发流量处理（令牌桶容量 = 2 倍 QPS 阈值），同时配置限流响应页面，避免返回默认错误码。
三、考点深度关联
本单元重点深化了 “DDD 拆分的事件风暴方法”“服务容错的三级防护体系”“网关的多维度限流策略”，这些是案例分析题中 “微服务架构设计与问题排查” 的核心考点。例如真题中常出现 “服务调用超时导致系统崩溃” 的场景，需结合熔断、线程池隔离等策略作答；而 DDD 拆分方法也是论文 “微服务架构设计” 章节的加分亮点。
