被DDoS攻击时保持核心API可用的降级方案

面对大流量DDoS攻击，很多团队的第一反应是把所有资源都堆在防火墙和黑洞路由上，结果往往是连正常用户一起挡在门外。更致命的是，当你的核心业务依赖API对外提供服务时，一旦入口被堵死，整个商业闭环就断了。真正成熟的架构不是追求“不被攻破”，而是追求“即使在被攻击时，核心交易或关键数据通道依然能保持可用”。这里说的降级，不是简单的关闭服务，而是一套从网关层、服务层到数据层的纵深防御与分流机制。

绝大多数中小型服务为了管理方便，会把官网、静态资源、管理后台和核心API挂在同一个反向代理或负载均衡后面。这在平时没问题，但在DDoS攻击下就是灾难。攻击流量往往是无差别的，如果核心API和那些消耗资源较大的页面、搜索接口、动态渲染服务混在一起，网关层的连接池和线程资源会被迅速耗尽。第一步要做的就是物理隔离：为核心API分配独立的域名或独立IP，使用独立的入口网关集群。这个网关集群的配置要极度精简，去掉任何非必要的模块，比如多余的Lua脚本、复杂的正则匹配规则、大体积的证书链处理。让它只做两件事：极速TLS终止和基于HMAC的轻量级鉴权。这样即使主站入口被流量打满，核心API的入口资源仍然是干净的，至少能保证握手和验签成功。

流量到了网关之后，不能直接全量透传给后端服务。传统的基于IP限流在DDoS面前作用有限，因为攻击者会使用海量肉鸡IP，每个IP的请求频率看起来都很正常。更有效的方法是在网关层植入基于用户身份的令牌桶算法。每个经过鉴权的合法API Key或Token对应一个独立的令牌桶，桶的容量和填充速率根据该用户的订阅等级或业务重要性动态调整。关键点在于，即使攻击者伪造了大量合法账号，只要你的业务系统能区分VIP客户和普通试用账号，就能在网关层把VIP客户的请求放进高优先级队列，普通请求放进低优先级队列。当后端服务出现积压时，直接丢弃低优先级队列的请求，返回HTTP 503并附带Retry-After头，而高优先级队列里的核心交易请求依然能获得处理资源。这种机制不依赖识别攻击特征，而是依赖保障核心用户的资源独占。

很多DDoS攻击会伪装成正常的API请求，比如模拟登录、查询订单、发送验证码。这些请求在协议层面完全合法，但业务逻辑上可能是非法的。在网关层或BFF层，可以插入一层极薄的业务验证。例如，对于需要发送短信验证码的接口，可以要求客户端先提交一个由服务端下发的、时效性极短的计算难题，比如要求客户端计算一个特定参数的哈希前几位。正常客户端在页面加载时会自动完成这个计算，而简单的脚本攻击往往不会执行这段JS逻辑，或者无法在短时间内完成大量计算。更进一步的，对于核心交易接口，可以强制要求请求携带一个由上次成功响应下发的会话令牌，这个令牌在服务端存储了上下文信息。如果请求没有携带有效令牌，直接在最外层拒绝，连数据库查询都不触发。这种基于业务语义的校验，比单纯看IP和请求频率准确得多，能有效过滤掉大量不具备完整业务上下文的攻击流量。

如果你的核心API中有大量读操作，比如商品详情查询、价格查询、库存查询，这些接口在攻击时最容易被打垮，因为每次查询都可能穿透到数据库。必须提前做好静态化预案。在正常时期，可以将这些核心数据以JSON格式预先生成为静态文件，推送到CDN边缘节点或对象存储上。当攻击发生时，通过DNS或网关层一键切换，让读请求直接走静态文件响应，完全绕过应用服务器和数据库。如果数据时效性要求较高，可以采用“静态底座+动态补丁”的模式：静态文件包含90%不常变的基础数据，客户端拿到静态数据后，再异步请求一个极轻量的动态补丁接口获取剩余10%的实时数据，比如实时库存或实时价格。这个动态补丁接口要设计得极其简单，只返回变化量，不执行复杂的数据库联表查询，最好直接从内存或Redis中获取。这样即使动态补丁接口被攻击，也只是影响实时数据的更新，基础数据依然可用，用户至少能看到商品信息和大致状态。

对于核心的写操作，比如下单、支付确认，这是绝对不能丢失的数据。传统的同步写库模式在DDoS攻击下会迅速耗尽数据库连接池。必须将写操作异步化。在API网关或应用层收到写请求后，完成基本校验，立即将请求序列化写入本地磁盘的日志文件或嵌入式消息队列中，然后直接返回客户端“已受理”。后端由一个独立的、限速的消费者进程从本地日志中拉取任务，慢慢写入数据库。这种设计的关键在于本地持久化，不能只放在内存里，因为机器随时可能被攻击宕机。使用RocksDB或直接写预写日志文件，确保请求不丢失。消费者进程的处理速度可以人为控制得很慢，比如每秒处理100条，这样无论前面有多少攻击流量，对数据库的压力始终是恒定的。正常用户的写请求混杂在其中，虽然响应时间可能从毫秒级变成秒级，但绝不会丢失，也不会把数据库压垮。攻击者伪造的写请求也会被写入日志，但可以在消费者端进行二次业务校验后丢弃，不影响正常订单的处理。

DDoS攻击通常会瞄准一个固定的IP地址。如果你的核心API入口只有一个IP，那这个IP被精准打击后，再好的架构也无能为力。需要建立一套快速切换入口的能力。在DNS层面，为你的核心API域名配置多条A记录，指向不同网段、甚至不同服务商的IP地址。当主IP遭受攻击时，可以利用健康检查自动摘除该IP，或者通过API调用DNS服务商的接口快速修改解析。这里有一个容易被忽视的技巧：对于核心API的客户端，在应用启动时预埋多个备用域名或直接使用IP列表作为最终兜底。当主域名解析失败或连接超时，客户端自动尝试备用地址。这些备用地址可以是你提前购买并配置好的其他服务商的弹性IP，平时处于静默状态，不承载任何流量，只在攻击时启用。更进一步，可以在客户端实现一套简单的连接策略：同时向多个入口发起连接，谁先完成TLS握手就用谁，其他连接立即断开。这种赛马机制能有效对抗针对特定链路的拥塞攻击。

攻击期间，集中式的缓存集群也可能成为瓶颈。如果核心API强依赖Redis或Memcached，而缓存集群所在的网段被攻击流量波及，即使应用层扛住了，缓存不可用也会导致请求全部击穿到数据库。需要为核心数据建立本地二级缓存。在应用服务器本地内存中，使用Caffeine或Guava Cache维护一份热点数据的只读副本，设置较短的过期时间。当远程缓存不可用时，自动降级为读取本地缓存。这会带来数据一致性问题，但在攻击场景下，提供稍微过时的数据远比完全不提供服务要好。对于写操作，如果远程缓存写入失败，可以将失效事件写入本地队列，待缓存恢复后重放。这种设计本质上是在可用性和一致性之间做了明确取舍：攻击期间优先保证可用性，攻击结束后通过重放机制修复一致性。

核心API的降级方案不能只停留在服务端，必须延伸到客户端SDK。SDK中要内置熔断器、自动重试、备用入口切换、本地缓存等全套逻辑。当SDK检测到服务端返回503或连接超时比例超过阈值时，自动进入降级模式。在降级模式下，SDK可以返回本地缓存的上一次成功数据，或者返回一个业务上可接受的默认值，而不是直接报错给用户。例如，支付状态查询接口降级时，SDK可以返回“处理中”状态，并启动一个指数退避的轮询，而不是直接告诉用户支付失败。SDK还需要实现请求合并功能：在攻击期间，将高频的相同查询请求在客户端本地合并，只发出一个请求，拿到结果后分发给所有等待的回调。这能成倍减少发出请求的数量，减轻服务端压力。SDK的这些行为要对业务代码透明，让上层开发者无感知地获得抗攻击能力。

再完善的降级方案，如果只是写在文档里，真正攻击来临时大概率会失效。必须定期进行红蓝对抗演练，在真实生产流量中注入模拟攻击。演练的关键不是测试防火墙能挡多少流量，而是验证核心API的降级路径是否真的能走通。具体做法是：在网关层通过流量染色，给测试请求打上特殊标记，这些标记会一直传递到后端服务和数据库。然后人为触发限流、熔断、静态化切换等降级动作，观察核心交易的成功率、响应时间、数据一致性是否符合预期。演练中要特别关注降级后的用户体验：客户端SDK是否正确处理了降级响应，UI是否给出了恰当的提示，而不是白屏或崩溃。每次演练后输出一份降级路径的可用性报告，把发现的问题固化为自动化测试用例，集成到CI/CD流水线中。这样每次代码发布前，都能自动验证降级逻辑是否仍然有效。

最终，防御DDoS的本质是成本对抗。攻击者发起流量需要消耗资源，防御者消耗资源应对。如果防御方的成本远高于攻击方，就不可持续。上述所有方案的核心思想都是让攻击者的成本远高于防御者。静态文件响应、异步写日志、本地缓存这些机制，都是让服务端用极低成本处理海量请求。而客户端计算难题、业务语义校验、令牌桶排队这些机制，则是抬高攻击者的请求成本。一个有效的降级架构，应该让攻击者发现：要打垮你的核心API，需要模拟完整的业务逻辑、维护会话状态、完成计算挑战，甚至要持有合法的VIP账号才能占用资源。当攻击成本上升到这个程度时，绝大多数攻击者会选择转向更容易的目标。