微服务突发流量下容器资源争抢最直接后果是响应延迟、OOM崩溃或关键服务被挤占；解决需启动设配额、运行时调优、编排层协同：CPU用--cpus硬限防霸占，内存设--memory与--memory-swap禁用swap，IO按角色分级控速，K8s/Docker Compose中配置requests与limits双约束。
微服务遇到突发流量时，容器间资源争抢最直接的后果是响应延迟、OOM崩溃或关键服务被挤占。解决思路不是“等扩容”，而是让每个容器“守好自己的资源边界”，同时留出弹性空间——靠的是启动时设好配额 + 运行时动态调优 + 编排层协同。
CPU配额：用--cpus硬限防计算型服务霸占核心
突发流量常伴随CPU密集操作（如JSON解析、加解密、实时聚合）。若不设限，一个服务可能吃满所有逻辑核，拖慢其他微服务：
- --cpus=1.5比--cpu-shares更可靠：它在内核CFS层强制限制平均使用率，不依赖竞争场景，适合API网关、订单处理等延迟敏感服务
- 对批处理类微服务（如异步报表生成），可搭配--cpu-quota=50000 --cpu-period=100000实现“每100ms最多跑50ms”，既保底线又不抢资源
- Java微服务要特别注意：-Xmx堆内存需比--memory值小30%以上，否则GC压力会触发宿主机OOM Killer误杀其他容器
内存限制：硬限+swap禁用，避免雪崩式终止
内存争抢最危险——超限直接触发OOM Killer，可能连带干掉数据库连接池或配置中心客户端：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 必须设置--memory=1g（不可省略），并显式加--memory-swap=1g（允许1g总内存）或--memory-swap=0（彻底禁用swap，防I/O抖动）
- Spring Boot微服务建议：在application.yml里配management.endpoint.metrics.show-details=never，减少Micrometer指标采集的内存开销
- 用docker stats --no-stream持续盯住MEM USAGE %，超过85%就该预警扩容或限流
磁盘与网络IO：按服务角色分级控速
日志服务、文件上传微服务容易打满I/O，间接卡住数据库和API：
- 高优先级服务（如MySQL容器）挂载时加--device-read-bps=/dev/sda:20mb --device-write-bps=/dev/sda:10mb
- 低优先级服务（如ELK日志收集器）用--blkio-weight=200（范围10–1000），降低其磁盘调度权重
- 网络限速推荐macvlan网络+tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms，比bridge模式更精准
编排层联动：Docker Compose/K8s中预留+限制双配置
单靠运行时参数不够，得让调度器也“心里有数”：
- Docker Compose v3.8+写法：reservations.cpus=0.3（保证最低0.3核不被抢占）+ limits.cpus=1.0（峰值不超1核）
- Kubernetes中必须填resources.requests（调度依据）和resources.limits（运行约束），两者比值建议控制在1:1.5以内，避免资源碎片
- 配合Prometheus监控container_cpu_usage_seconds_total和container_memory_usage_bytes，触发告警后自动执行docker update --cpus=2.0 --memory=2g container-name
