高并发系统用docker搭建的关键在于精准控资源、合理分流量、提前防瓶颈。需调优宿主机（关闭selinux、增大连接与句柄上限、启用bbr）、容器加资源限制（cpu/内存/pid限制、host网络）、精简镜像（multi-stage、alpine）、配合负载均衡与健康检查。
一、宿主机系统层必须调优
CentOS 7.9 或类似内核系统上，不调参数，Docker 再怎么配也扛不住真实高并发。
-
关闭 SELinux 或设为 permissive：默认 enforcing 模式会对容器网络和文件访问做额外检查，增加延迟；执行
setenforce 0并修改/etc/selinux/config中的SELINUX=permissive -
加大内核连接与文件句柄上限：写入
/etc/sysctl.conf后运行sysctl -pnet.core.somaxconn=65535<br>net.ipv4.tcp_tw_reuse=1<br>fs.file-max=1000000<br>net.ipv4.ip_local_port_range="1024 65535"<br>net.nf_conntrack_max=1048576
-
启用 TCP BBR 拥塞控制：提升高并发下的网络吞吐，执行
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf && sysctl -p
二、容器启动时必须加资源限制
不设限 = 不可控。单个容器吃光 CPU 或内存，会连累整个节点。
-
CPU 控制优先用
--cpus，不是--cpu-quota：比如--cpus="2.5"表示最多用 2.5 个逻辑核，更直观、更稳定 -
内存必须双保险：既用
--memory="2g"硬限制，又在应用内（如 Java 加-Xmx1800m）设上限，避免 OOM Killer 杀错进程 -
限制进程数防 fork 炸弹：加
--pids-limit=150，尤其对 Python/Node.js 这类易生成子进程的服务很关键 -
高并发 Web 服务建议用 host 网络模式：
--network=host跳过 Docker 的 NAT 层，实测比 bridge 模式吞吐高 45% 以上（注意端口冲突问题）
三、镜像和应用层要轻且稳
大镜像拉取慢、启动慢、内存占用高，天然不适合高并发场景。
- 用 Multi-stage 构建：例如 Node.js 项目，构建阶段用完整镜像装依赖，运行阶段只 COPY 编译产物到 Alpine 镜像，体积减少 50%+
- 基础镜像选 Alpine 或 distroless：避免带一堆没用的工具和库，减小攻击面和内存 footprint
- 应用自身要支持并发模型：Flask 配 Gunicorn（worker 数 ≈ CPU 核数 × 2～4），Nginx 做反向代理并开启 keepalive；Java 应用调优 GC 和线程池大小
四、多实例必须配负载均衡和服务发现
单容器再强也有限，靠横向扩展 + 流量分发才是正解。
-
本地测试可用 Nginx 做 upstream：配置多个
server container-ip:port，加least_conn或ip_hash策略 -
生产环境强烈推荐 Kubernetes：用 Deployment 管理副本数（如
replicas: 5），Service 做集群内服务发现，Ingress 统一入口，再配 HPA（CPU 70% 触发扩容，3~20 副本区间） -
别忘了加健康检查：在 Dockerfile 或 k8s yaml 中定义
HEALTHCHECK或livenessProbe，自动剔除不可用实例
