明确服务资源硬上限是阻断雪崩的第一道防线，CPU和内存必须设硬限制（如Docker的--memory=1g、K8s的resources.limits），不设limit将导致OOM Killer随机终止关键服务；同时配置软限制（如--memory-reservation=512m或requests.memory）保障核心链路最低资源，辅以线程池隔离、超时与熔断机制实现分级防护。
明确服务资源硬上限
给每个服务设定不可突破的资源天花板，是阻断雪崩的第一道防线。CPU和内存必须设硬限制，避免某个服务突发占用全部资源。比如用 Docker 启动时加上 --memory=1g --cpus=1.5，Kubernetes 中则在 Pod 的 resources.limits 字段里配置。不设 limit 就等于把调度权交给内核 OOM Killer，故障时它可能随机杀掉关键服务。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
引入软性资源保障机制
硬限制防崩溃，软限制保体验。通过 --memory-reservation=512m（Docker）或 requests.memory（K8s）声明服务“期望获得”的最低资源。这不会预占内存，但在宿主机资源紧张时，调度器会优先保障这些服务拿到承诺资源，降低被挤出的风险。对核心链路服务（如订单、支付），软限制应设为平均用量的 1.2 倍，体现服务质量分级。
实施调用方资源隔离
服务消费者要为自己调用下游的行为负责。不能共用一个线程池或连接池——否则一个慢接口拖垮整个服务。推荐做法：
- 为每个下游服务分配独立线程池（如 Hystrix 或 Resilience4j 的隔离策略）
- 设置池大小上限，例如最多 20 个线程专用于调用用户中心
- 拒绝新请求而非排队等待，防止线程耗尽后自身也变成故障源
叠加超时与熔断控制
资源限制管“量”，超时和熔断管“时”与“态”。两者必须配合：
- 所有远程调用强制设置超时，建议 80 分位响应时间 × 2，不超过 3 秒
- 当错误率连续 10 次达 50% 以上，自动触发熔断，暂停调用 30 秒
- 熔断期间返回降级结果（如缓存数据、静态提示），不穿透到下游
- 熔断恢复后仅放行 1 个探针请求，成功才全量恢复
