DDoS攻击防护业务降级保护核心接口

DDoS攻击防护里最容易被忽视但实际最救命的一项配置，是业务降级策略。很多团队把预算和精力都放在扩容带宽、上高防IP、调清洗设备规则上，结果真遇到大流量攻击或者CC攻击时，核心接口还是被打挂。原因不是防护设备没生效，而是后端业务系统根本扛不住清洗后残存的请求压力，或者大量非核心接口占满了连接池、数据库连接和CPU资源，导致核心交易接口跟着一起超时。所谓业务降级保护核心接口，就是在攻击发生或者系统负载达到阈值时，主动关闭、限制或简化非核心功能，把有限的计算资源、带宽资源和数据库连接优先留给核心业务接口。

先明确一个基本事实：DDoS防护不是万能的。无论是流量型攻击还是应用层攻击，清洗设备能做的只是把明显恶意的流量丢掉，但攻击者完全可以用大量真实协议请求、慢速连接、模拟正常用户行为的CC攻击来消耗你的后端资源。这些请求单个看都不大，但数量一上来，登录、搜索、商品列表、评论、推荐这些非核心接口会先被拖垮。如果这些接口和核心下单、支付接口共用同一套服务、同一个数据库、同一个连接池，那么核心接口必然受到牵连。降级保护的核心思路就是把故障隔离在非核心模块内部，不让它蔓延到核心链路。

业务降级的前提是你清楚自己系统里哪些功能是必须保住的，哪些是可以暂时牺牲的。这个梳理不能拍脑袋，要按业务收入和用户影响来排序。一般来说，下单、支付、订单查询、库存扣减、账号登录态校验属于核心接口，这些接口一旦不可用，直接造成资金损失和用户流失。而商品推荐、热门榜单、用户评论、站内消息、积分查询、个性化广告、搜索结果里的非核心排序功能，这些都属于可以降级的范围。降级方式可以是直接返回静态数据、返回缓存内容、返回默认值、关闭某个模块的入口，或者直接返回一个友好的提示页面。

很多系统里，一个页面会同时调用十几个后端接口，其中真正影响成交的可能只有两三个。攻击者往往就是盯着那些调用链长、计算量大、容易产生缓存穿透的接口打。比如搜索建议接口、模糊搜索接口、复杂报表接口、实时统计接口，这些接口平时看起来没问题，一旦被高频请求，数据库和缓存压力会瞬间飙升。把这类接口在攻击期间直接降级成简单模式或者关闭，能释放出大量资源。

DDoS攻击往往是突发性的，从流量开始上涨到业务完全不可用，可能只有几分钟。如果你没有提前配置好降级开关，等运维人员发现告警、登录系统、找到配置项、再逐个手动关闭接口，业务早就被打挂了。降级保护必须提前做好两件事：一是把降级开关做成配置中心里的动态配置，二是设定好自动触发条件。

动态配置的意思是，每个非核心接口的调用入口都包一层降级判断逻辑，这个逻辑会读取配置中心里的开关状态。开关可以是全局的，比如“攻击模式开启”，也可以是分级的，比如“一级降级只关推荐和评论，二级降级再关搜索和列表页，三级降级只保留下单和支付”。配置中心里的开关一旦修改，所有服务实例在几秒内就能生效，不需要重启服务。这样在攻击发生时，运维人员只需要改一个配置项，整个集群的降级策略就统一生效了。

自动触发条件则更关键。人工响应再快也有延迟，而且大半夜攻击来了，值班人员可能还在登录VPN、找监控面板。自动降级可以基于系统负载、错误率、响应时间、连接数等指标来触发。比如当核心接口的P99响应时间超过2秒，或者数据库连接池使用率超过90%，或者网关层每秒请求数超过预设阈值的1.5倍，就自动把非核心接口的开关关掉。自动触发逻辑可以放在网关层，也可以放在服务治理框架里，比如通过Sentinel、Hystrix这类组件来实现。

降级保护最合适的执行位置是API网关。所有外部请求都经过网关，网关可以在路由转发之前就根据当前系统状态和接口优先级来决定是否放行。对于已经降级的接口，网关可以直接返回预设的降级响应，比如HTTP 200加上一个静态JSON，里面写“系统繁忙，请稍后再试”，或者返回缓存里的兜底数据。这样做的好处是请求根本不会打到后端服务，后端服务的压力立刻降下来。

网关层的降级规则可以设计得很灵活。比如按URL路径匹配，/api/recommend、/api/comments、/api/search/suggest这些路径在降级期间直接返回静态数据；按用户身份匹配，未登录用户的非核心请求直接拒绝，登录用户的核心请求正常放行；按请求来源匹配，来自特定渠道或者特定App版本的请求执行不同的降级策略。网关层还可以做限流和熔断，当某个接口的QPS超过阈值时，自动把超出的部分拒绝掉，而不是让它们排队等待后端响应。

这里有一个常见的误区：很多人以为限流就是降级。其实限流只是控制请求速率，降级是改变请求的处理方式。限流可以保护系统不被冲垮，但被限流的用户还是会收到错误提示，体验很差。降级则是让用户仍然能得到一个可用的响应，哪怕是降级后的简化内容。两者要配合使用，限流负责挡住极端流量，降级负责在系统承压时保住核心体验。

降级非核心接口只是第一步，核心接口本身也需要做防护加固。攻击者如果发现非核心接口打不动了，会直接把火力集中到核心接口上。核心接口的保护主要靠几层：第一层是网关层的严格限流和IP信誉过滤，把明显异常的请求拦截掉；第二层是业务层的参数校验和幂等控制，防止攻击者用构造的请求绕过限流；第三层是缓存和异步化，核心接口能走缓存的就不要直接查数据库，能异步处理的就不要同步阻塞。

比如下单接口，攻击者可能会用大量不存在的商品ID或者非法参数来请求，如果下单接口不做参数校验，每个请求都会穿透到数据库查询商品信息，数据库很快就会被拖垮。正确的做法是在网关层就做基础参数格式校验，在业务层做商品存在性校验，并且把商品信息缓存在Redis里，查询缓存失败后再回源数据库，同时加上布隆过滤器防止缓存穿透。支付接口则要严格控制并发，同一个订单号只能有一个支付请求在处理，其他重复请求直接返回“处理中”。

核心接口的降级还有一个特殊场景：当后端依赖的服务出现故障时，核心接口本身也需要做局部降级。比如下单接口依赖库存服务，如果库存服务响应变慢或者不可用，下单接口不能无限等待，要设置超时时间和熔断机制，超时后返回一个明确的错误码，让前端提示用户稍后重试，而不是让请求一直挂着占用连接资源。这种局部降级和整体业务降级要结合起来设计。

降级不是简单地把接口关掉就完事了，还要考虑数据一致性和用户体验。比如你关闭了评论接口，用户看到的页面里评论区域是空的，这没问题，但你不能让用户以为自己的评论丢失了。可以在前端展示一个“评论功能暂时不可用”的提示，并且把用户提交的评论请求暂存到消息队列里，等攻击结束后再异步处理。如果直接丢弃用户请求，攻击过后用户发现自己的评论没发出去，会投诉。

对于核心接口的降级，数据一致性要求更高。比如支付接口在降级模式下可能只处理已有订单的支付，不接受新订单创建，这时候要保证订单状态的一致性。如果支付请求已经到达后端但处理超时了，不能简单地返回失败，要有一个对账机制来确认这笔支付到底成功没有。降级期间产生的数据要能追溯，攻击结束后可以补处理或者人工核对。

用户体验方面，降级响应要设计得友好。不要返回一堆技术错误码或者空白页面，要返回一个明确的提示，比如“当前访问人数较多，部分功能暂时受限，请稍后再试”。如果是App端，可以在降级时展示缓存的静态内容，让用户感觉App还在正常工作，只是某些动态内容加载不出来。这种体验上的细节往往决定了用户在攻击期间是留下来等待还是直接流失。

降级策略配置好之后，如果不测试，等于没做。很多团队的降级开关只在文档里存在，从来没真正触发过，真到攻击来了，一开开关发现逻辑有bug，核心接口跟着一起被降级了，或者降级响应格式不对导致前端崩溃。降级策略必须定期做演练，模拟攻击场景，逐个触发降级开关，验证核心接口是否正常、非核心接口是否正确降级、降级响应是否符合预期、自动触发条件是否准确。

演练可以在测试环境做，也可以在生产环境低峰期做。生产环境演练要谨慎，可以先从一个影响最小的非核心接口开始，比如关闭推荐接口，观察几分钟，确认核心接口不受影响，再逐步扩大范围。演练过程中要记录每个降级动作对系统资源的影响，比如关闭搜索建议接口后，数据库连接数下降了多少，CPU使用率下降了多少，这些数据可以用来优化降级策略的触发阈值。

自动降级的触发条件也要测试。可以人为制造一些压力，比如用压测工具把某个接口的QPS打到阈值以上，观察自动降级是否按预期触发，触发后系统是否恢复稳定，压力解除后是否自动恢复。自动恢复也要谨慎设计，不能压力一降下来就立刻把所有接口都恢复，要设置一个冷却时间，避免攻击流量波动导致降级开关频繁切换，反而造成系统不稳定。

业务降级策略要和DDoS防护设备联动起来，才能发挥最大效果。高防IP或者清洗设备检测到攻击时，通常会发送告警通知，这个告警可以触发业务系统的降级动作。比如通过Webhook或者API调用，让配置中心自动把降级开关打开。这样从攻击发生到业务降级生效，整个过程可以在几十秒内完成，不需要人工介入。

联动时要注意一个细节：清洗设备的告警可能误报，也可能攻击流量并不大但应用层攻击已经开始了。所以联动策略不能只依赖清洗设备的告警，还要结合业务系统自身的监控指标。比如网关层的QPS、错误率、响应时间，这些指标更能反映业务系统真实承受的压力。可以设计一个综合判断逻辑：当清洗设备告警并且网关层QPS超过阈值时，才触发自动降级；如果只有清洗设备告警但业务指标正常，就只记录日志不降级。

另外，降级策略要和清洗设备的防护策略配合。清洗设备可以针对非核心接口的URL做更严格的限速，比如对/api/recommend路径设置很低的QPS阈值，超过就直接丢弃，这样非核心接口的流量在到达业务系统之前就被清洗设备拦截了大部分。核心接口的URL则设置相对宽松的阈值，保证正常用户能访问。这种基于URL的差异化防护策略，配合业务层的降级开关，可以形成多层防护体系。

下面给一个简单的网关层降级配置示例，以常见的Nginx+Lua或者OpenResty环境为例，展示如何根据配置中心里的开关来决定是否降级某个接口：

-- 从配置中心读取降级开关状态
local degrade_level = ngx.shared.config:get("degrade_level") or "0"

-- 判断当前请求路径是否需要降级
local path = ngx.var.uri
local is_degraded = false

if degrade_level == "1" then
    -- 一级降级：关闭推荐和评论
    if path:find("/api/recommend") or path:find("/api/comments") then
        is_degraded = true
    end
elseif degrade_level == "2" then
    -- 二级降级：关闭搜索建议、列表页非核心接口
    if path:find("/api/recommend") or path:find("/api/comments") 
        or path:find("/api/search/suggest") or path:find("/api/list/extra") then
        is_degraded = true
    end
elseif degrade_level == "3" then
    -- 三级降级：只保留核心接口
    if not path:find("/api/order") and not path:find("/api/pay") 
        and not path:find("/api/stock") then
        is_degraded = true
    end
end

if is_degraded then
    ngx.status = 200
    ngx.header["Content-Type"] = "application/json"
    ngx.say('{"code":-1,"msg":"系统繁忙，请稍后再试"}')
    return ngx.exit(ngx.OK)
end

这个示例的逻辑很直接：配置中心里有一个degrade_level的值，0表示正常，1到3表示降级级别。网关在转发请求之前先检查这个值，根据请求路径判断是否命中降级规则，命中就直接返回一个JSON响应，不转发到后端。实际生产环境中的降级逻辑会更复杂，比如要结合用户身份、请求参数、限流计数等，但核心思路就是这样。

对于Java技术栈的系统，可以用Sentinel来做类似的事情。Sentinel支持基于资源的降级规则，可以配置当某个接口的RT或者异常比例超过阈值时，自动执行降级处理逻辑，返回兜底数据。Sentinel的规则可以动态修改，配合配置中心使用，效果和上面的网关层降级类似，但粒度更细，可以精确到方法级别。

业务降级保护核心接口这件事，成本其实不高。主要投入在前期梳理接口优先级、开发降级开关逻辑、配置自动触发规则和做演练测试上。一旦做好，收益是长期的。攻击发生时，核心接口的可用性会显著提升，用户能正常下单支付，业务损失降到最低。即使没有攻击，日常大促、突发流量、后端服务故障时，降级策略也能发挥作用，避免系统被非核心流量拖垮。

很多团队在DDoS防护上花了几十万甚至上百万买高防带宽和清洗服务，但业务系统本身没有做降级保护，结果攻击流量被清洗掉一部分后，剩下的请求还是把后端打挂了。这就像给房子装了很贵的防盗门，但窗户没关。降级保护就是关窗户的动作，它不贵，但能堵住最容易被忽视的漏洞。对于任何有一定业务规模、核心接口直接产生收入的系统，业务降级保护核心接口都应该作为DDoS防护体系里的标配，而不是可选项。

最后强调一点：降级策略不是一成不变的。业务在迭代，接口在变化，核心接口的定义也可能调整。每次大版本上线后，要重新审视降级策略，确认新增的非核心接口是否纳入了降级范围，核心接口的依赖关系是否发生了变化。降级保护是一个持续维护的过程，不是配置一次就一劳永逸的事情。