服务雪崩

引言：一场真实的雪崩事故 2018年某电商平台的双11大促，凌晨2点，一场噩梦开始了： 2:00 - 商品详情服务的MySQL数据库出现慢查询，响应时间从10ms飙升到5秒 2:02 - 商品服务的Tomcat线程池被耗尽（200个线程全部阻塞在数据库查询上） 2:03 - 订单服务调用商品服务超时，订单服务的线程池也被耗尽 2:04 - 用户服务调用订单服务超时，用户服务也挂了 2:05 - 整个系统瘫痪，首页无法访问，交易全部失败 损失：10分钟内损失订单超过5000万元 这就是微服务雪崩效应的真实案例。 一个数据库的慢查询，像多米诺骨牌一样，导致整个系统崩溃。 今天我们就来学习如何用Sentinel防止这种雪崩的发生。 场景描述：一个典型的调用链路 系统架构 我们有一个典型的微服务架构： 用户请求 ↓ [用户服务 User-Service] ↓ 调用 [订单服务 Order-Service] ↓ 调用 [商品服务 Product-Service] ↓ 查询 [MySQL数据库] 调用关系： 用户服务 → 订单服务：查询用户的订单列表 订单服务 → 商品服务：查询订单中的商品详情 商品服务 → MySQL：查询商品信息 正常流程 用户访问"我的订单"页面 用户服务调用订单服务的/order/list接口 订单服务返回订单ID列表 订单服务调用商品服务的/product/detail接口，批量查询商品信息 商品服务查询MySQL数据库 层层返回，用户看到订单列表 正常情况下的响应时间： 商品服务查询数据库：10ms 订单服务调用商品服务：50ms 用户服务调用订单服务：100ms 用户看到页面：200ms 问题分析：雪崩是如何发生的？ 故障起点：商品服务的数据库慢查询 某天凌晨，商品服务的MySQL数据库出现了慢查询： -- 慢查询：全表扫描，耗时5秒 SELECT * FROM product WHERE category = 'phone' AND price > 5000 ORDER BY sales DESC; 直接影响：商品服务的响应时间从10ms飙升到5秒。 ...

引言：从单体到微服务的演进之痛 2015年，Netflix宣布他们的微服务架构已经包含超过1000个微服务，每天处理数十亿次API调用。这标志着微服务架构从理论走向了大规模生产实践。 但微服务不是银弹。在享受它带来的灵活性、可扩展性的同时，我们也必须面对新的挑战。 上一篇我们讲了流量控制的本质，这篇我们深入微服务场景，看看现代分布式系统面临的三大稳定性威胁：流量洪峰、服务雪崩、资源耗尽。这三个问题如果不妥善处理，任何一个都足以让整个系统在几分钟内瘫痪。 一、挑战1：流量洪峰——当10倍流量来袭 1.1 真实案例：2019年双11零点的惊险时刻 2019年双11，阿里云技术团队事后复盘了一个惊险瞬间： 零点前1秒： 系统QPS：50万/秒 服务器CPU：60% 数据库连接：5000个 零点后1秒： 系统QPS：680万/秒（13.6倍） 服务器CPU：95%（濒临极限） 数据库连接：10000个（已达上限） 零点后2秒： 部分慢查询开始出现 RT从50ms上升到200ms 用户开始疯狂刷新（雪上加霜） 如果没有流量控制和弹性扩容，这个洪峰足以在10秒内压垮整个系统。 1.2 流量洪峰的特征 流量洪峰不是均匀的，而是呈现尖刺特征： QPS | | ╱╲ | ╱ ╲ | ╱ ╲ |─────────────────╱ ╲──────────── | 时间 └─────────────────────────────────────> 平时 活动开始 高峰 回落 关键问题： 短时极高：可能在1秒内达到10倍甚至100倍 难以预测：用户行为受心理因素影响（从众效应） 恢复困难：系统崩溃后，重启需要时间，流量会继续堆积 1.3 微服务架构下的放大效应 单体应用时代，1个用户请求 = 1次数据库查询。 微服务时代： 1个用户请求 → 网关（1次调用） → 订单服务（1次调用） → 用户服务（查询用户信息） → 商品服务（查询商品信息） → 库存服务（检查库存） → 优惠券服务（计算优惠） → 积分服务（计算积分） ↓ 5次下游调用 × 3次数据库查询 = 15次数据库操作 放大效应： ...