容灾降级：分流限流之后的最后防线，优先牺牲非强依赖服务保住主流程

即使做了充分的分流和限流，系统在极端高压下依然可能出现问题，这时就需要容灾降级这道最后防线，降级不是单一手段，而是要在多个方向上都提前准备好预案：机房级容灾（当某个机房整体出问题时能否切换）、网络容灾（网络链路层面的互备，比如ISP进入机房后经过核心交换机、柜顶交换机，交互网络本身要做共享互备）、应用容灾（应用层面的多活或快速切换），以及作为最后兜底的托底容器（保证在其他手段都失效时至少能给用户一个可接受的降级响应），这些手段的共同前提是必须先确保最基础的服务本身是正常的。在应用层面，业务降级的核心原则是清楚区分主流程和非核心流程：以购物车结算页为例，延保服务、预约服务这类不属于”完成一次购买”这个核心动作必须依赖的功能（非强依赖服务）一旦出现问题，可以直接被降级掉（暂时不可用或返回简化结果），以此保证购物车加购、结算这类真正决定订单能否顺利提交的主流程不受影响、能够继续顺畅运转。这个原则背后的逻辑很直接：在系统资源和处理能力有限、又处在极端压力下的时刻，必须有一套清晰的优先级排序，把有限的资源和容错空间优先分配给真正影响核心业务目标（订单能不能提交成功）的部分，而不是眉毛胡子一把抓地想保住所有功能——降级设计的关键不在于”降级机制本身多么精巧”，而在于团队是否已经提前、清楚地梳理出了”哪些是真正的强依赖、哪些可以被牺牲”这份优先级清单，这份清单往往需要每次大促之后结合业务实际情况反复调整。