配置防护时，不能只按访问量给所有服务分配相同资源。在线业务防护资源按业务等级分层配置，关键是先判断服务中断的影响，再决定防护能力、容量余量和告警优先级。业务等级描述的是服务的重要程度，不等同于服务器规格，也不意味着普通服务可以不做基础防护。
先按影响划分档位，而不是按部门或名称
可以从三个问题开始：服务不可用会不会阻断核心流程？是否涉及重要数据处理或外部承诺？故障后能否通过人工或其他路径暂时替代？答案越偏向“不能中断、难以替代”，越适合列入高优先级。判断时要看实际依赖关系：某个看似普通的查询接口，如果是多个关键流程共同依赖的入口，也可能需要提高等级。
| 档位 | 适用情况 | 资源与防护重点 |
|---|---|---|
| 核心业务 | 中断会明显阻塞主要服务，恢复时限较短 | 优先保障计算、连接和带宽；设置较高的容量余量、严格的访问控制、关键告警和可执行的恢复方案 |
| 重要支撑服务 | 本身不是主要入口，但故障会影响多个功能 | 保障依赖链容量；配置健康检查、限流和冗余，明确故障时可降级的功能 |
| 普通服务 | 短时延迟或暂停影响较小，存在替代方式 | 采用基础防护和合理配额；用排队、缓存或延迟处理吸收短时峰值，避免挤占核心资源 |
把档位落实到可执行的资源配置
资源不只指计算实例。还要盘点网络带宽、数据库连接、缓存容量、队列处理能力，以及防火墙或 Web 应用防火墙（WAF）的规则处理能力。核心业务若只增加应用实例，却被数据库连接数或出口带宽卡住，实际可用能力仍不会提高。相反，普通服务也不宜无限共享核心业务的资源池，否则突发任务可能形成资源争抢。
按这个顺序实施
- 列出服务和依赖。为每项服务记录负责人、上游与下游依赖、峰值时段、可接受的中断时间和降级方式。依赖多个核心流程的服务应单独评估。
- 采集基线。观察覆盖常见高峰的运行数据，包括请求量、响应时间、错误率、CPU 与内存使用、带宽、连接池和队列长度。没有可信的历史基线时，先做受控压测；不要把一次测试结果当作长期容量结论。
- 先保障瓶颈资源。依据压测和生产监测结果确定扩容位置。可从当前高峰负载上方预留余量作为起点，但余量要结合流量波动、扩容速度和故障场景验证，不应把某个固定百分比套用于所有服务。
- 设置隔离和降级。为核心业务设独立配额或资源池；为普通任务设并发上限、队列容量或较低优先级。对非必要功能设置降级路径，避免它们在高峰期拖慢主要请求。
- 验证并复盘。用接近预期峰值的压测检查延迟、错误和资源瓶颈；再核对告警是否能指向具体服务。业务变化、架构调整或流量明显上升后，重新评估档位。
避免两种常见的配置偏差
第一种是所有服务套用同一规格。它看似方便，却可能让核心业务在突发流量下缺少余量，也可能让低优先级任务长期占用昂贵资源。第二种是只看业务标签，不看依赖和容量数据。更稳妥的做法是把业务影响等级与实测负载结合：等级决定保护优先级，数据决定资源数量。
此外，防护策略也要分层。核心业务适合设置更及时的容量告警、明确的值班升级路径和经过验证的恢复步骤；普通服务可采用更宽松的延迟目标，并优先通过限流、排队或暂停非关键任务保护整体系统。在线业务防护资源按业务等级分层配置，不是一次性划定永不变化的档位，而是持续校准的资源管理方法。
常见问题
普通服务是否可以不配置防护？
不可以。至少应具备基础访问控制、容量限制、监控和故障恢复措施；区别在于资源优先级及恢复要求。
没有历史流量数据，怎样确定资源档位？
先结合依赖关系和中断影响定业务等级，再通过受控压测、逐步上线和实时监测补足容量依据，避免一次性配置过大。
业务等级多久复核一次？
没有适用于所有系统的固定周期。服务依赖、用户规模或运行架构发生变化时应及时复核；稳定服务也可纳入常规容量评审。
最终目标不是让每项服务都拥有最高规格，而是让关键路径在压力下优先保持可用，同时让普通服务有边界、可降级、可恢复。按业务影响持续检验在线业务防护资源按业务等级分层配置，才能兼顾韧性与资源效率。
