资源限制是微服务高可用的底层防线，通过memory和cpus等硬性限制防止服务失控引发雪崩，结合reservations保障调度底线，并支撑弹性扩缩与容量规划，需与限流熔断协同构建分层防护体系。
资源限制不是“加个参数就完事”的配置项，而是微服务集群高可用的底层防线。它直接决定单个服务失控时，是否波及整个系统——没有合理限制，一个内存泄漏的订单服务可能拖垮支付、用户、库存所有模块。
防止资源雪崩，守住故障边界
微服务集群里，服务间物理隔离弱、网络调用密集。若某服务因流量突增或代码缺陷持续申请内存，又无硬性上限，Linux OOM Killer 会强制杀掉进程，但往往选错目标（比如先杀掉健康但内存占用稍高的网关）。通过 memory:512M 或 --memory=512m 设置内存硬限制，容器到达阈值后直接被 cgroups 截断分配，不会触发全局 OOM；CPU 同理，cpus:0.8 可确保它最多吃掉 80% 单核算力，留出余量给心跳、日志、监控等保底任务。
保障多服务公平调度，避免“邻居效应”
同一台宿主机上常运行网关、认证、配置中心等多个关键组件。若网关没设 CPU 上限，大促时它可能占满 2 个核心，导致配置中心响应延迟飙升，继而引发全链路配置失效。Docker Compose 中的 deploy.resources.limits 配合 reservations 能双管齐下：
- limits 是红线：绝不允许突破，如 memory:768M、cpus:'1.2'
- reservations 是底线：调度器启动前就预留，如 memory:256M、cpus:'0.3'，确保服务总有基本资源可依赖
支撑弹性扩缩与容量规划
资源限制是自动扩缩容（如 K8s HPA 或 Swarm 基于 CPU 的伸缩）的前提。没有明确的 limits，指标就失去参照系——“CPU 使用率 90%”毫无意义，因为不知道上限是多少。同时，运维能基于各服务的 limits 总和，精准计算单机可部署实例数，例如：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 一台 8C/16G 机器
- 订单服务：limits.memory=1G, cpus='0.5' → 单机最多部署 14 个（受内存约束）
- 用户服务：limits.memory=512M, cpus='0.3' → 单机最多部署 30 个（受 CPU 约束）
这种可计算性，是集群长期稳定运行的基础。
配合限流熔断，构建分层防护体系
资源限制属于基础设施层防护，它不关心业务逻辑，只管“别把机器搞挂”；而应用层限流（如 Nginx 的 limit_req、Go 的 rate.Limiter）负责“别让请求积压”。两者必须协同：
- 当 API 层限流已满，但后端数据库连接池仍在疯涨 → 内存限制会及时截断，避免堆溢出
- 当突发流量打穿网关限流，大量线程创建 → PID 限制（--pids-limit=200）可阻止 fork 爆炸，保护内核稳定性
- 磁盘 I/O 过载拖慢日志写入 → 通过 blkio_config 限制读写带宽，保底保障主业务 I/O 响应
