高流量攻击期间业务限速与核心功能保留策略，重点不是把请求一概挡住，而是先找出被挤占的资源，再优先保住用户必须完成的操作。登录、提交订单、保存资料等流程通常比搜索、推荐或报表刷新更重要；具体优先级要按实际业务确认。
新手容易直接按单个来源地址设置严格上限，但大量正常用户可能共享出口地址，攻击流量也可能分散到多个来源。更稳妥的做法是结合接口、账号、来源和系统负载判断，并从较温和的限制开始。
先分清哪些请求必须保留
把接口按业务影响分成三类：核心写操作、必要查询、可延迟或可关闭的非核心功能。核心写操作也要防重复提交，可采用幂等校验；必要查询可以缩短返回内容或限制刷新频率；统计导出、个性化推荐等则可暂缓处理。
不要只看请求数量。资源消耗不同：一次轻量查询与一次复杂搜索可能对数据库造成完全不同的压力。可同时观察延迟、错误比例、队列积压和数据库连接使用情况，按实际瓶颈调整限流阈值。
用分层规则限流，避免误伤
从宽到严逐级处理
- 建立基线：查看近期正常高峰中各接口的请求量、延迟和失败情况。按接口分别设定初始上限，不要套用一个全站数字。若缺少历史数据，先在低风险时段观测，再逐步调整。
- 选择合适算法：令牌桶允许短时突发，适合用户操作存在自然波峰的场景；固定窗口容易在窗口交界处出现流量集中，适用时要留意边界效应。选型应结合突发容忍度和实现复杂度。
- 按多个维度判断：可组合接口、账号、来源及整体资源状态。单一来源触发限制时，不必连带封禁该来源访问所有功能；对共享网络环境，可更多参考账号行为与接口负载。
- 按等级减载：先限制高成本、可延迟的请求，再对非核心功能做熔断降级；核心操作尽量保留有限处理能力，并为它们设置优先级队列。系统资源紧张时，优先让关键请求完成，不代表取消其自身的安全校验。
- 小步发布并留回滚：先对少量流量或部分接口启用规则，核对拦截量、正常用户失败率和关键操作完成率，再扩大范围。每次调整后观察一段与业务波动相匹配的时间；出现正常请求明显受阻时，立即放宽规则或关闭新策略。
监控应回答两个问题
一是攻击是否受到控制：系统延迟、排队和资源压力有没有下降？二是核心业务是否仍可用：登录、提交、保存等操作的成功比例是否异常下滑？建议把这两类指标放在同一张监控视图中。只看拦截数量，无法判断规则是否误伤。
限速策略还需明确责任人、变更时间和回滚条件。若攻击强度超过应用自身承受能力，应结合上游流量清洗或云平台防护能力；应用层限速可以保护业务资源，但不能替代网络层防护。
常见问题
所有接口能共用一个限速值吗？
不建议。不同接口的计算成本和业务重要性不同，应分别制定规则，并用整体资源指标补充判断。
只按来源地址限速够吗？
通常不够。共享出口会让正常用户受影响，分散来源也可能绕过限制；宜结合账号、接口和系统负载。
怎样确认规则没有误伤？
对比启用前后的正常请求失败率与核心操作完成率，并抽查触发规则的请求特征；异常时先回滚，再修正规则。
归根结底，高流量攻击期间业务限速与核心功能保留策略要围绕业务优先级、实际瓶颈和可回滚的渐进调整来设计，而不是追求拦截越多越好。