子单元 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 拆分方法也是论文 “微服务架构设计” 章节的加分亮点。