香港独服跑Docker容器够用吗

机器买回来之后第一件事往往就是装容器环境，然后一个接一个把服务塞进去，等到某天发现容器互相拖着走、日志把盘写满、重启一次整站掉线，才开始想是不是一开始就该规划。一台机器能装多少个容器这个问题没有标准答案，装得下和跑得住完全是两件事。这篇按真实用下来的顺序往下讲：资源该怎么分、磁盘怎么防爆、网络怎么选，以及什么时候该承认一台不够用。

一台独服塞十几个容器会不会打架

容器本身并不吃多少资源，真正吃资源的是里面跑的进程。十几个容器如果都是轻量服务，一台机器带得动；如果里面有两三个吃内存的大户，互相拖就开始了，表现是大家都变慢而不是某一个变慢，这种集体变慢最难定位，因为每个服务的指标看起来都还正常。

最先出问题的通常是内存。容器不设上限，某个进程内存慢慢涨，把整机的可用内存吃光，其余容器开始被系统挑着杀，日志里一堆莫名其妙的退出码，重启之后又恢复正常，问题很难复现。

第二个是磁盘读写。多个容器同时写日志、同时读数据文件，机械盘上的队列长度会迅速堆起来，响应时间成倍恶化，看起来像 CPU 不够其实是盘在等。

CPU 反而是最不急的那一项。核数多的机器能容忍好几个容器同时跑满单核，除非某个容器开多线程把所有核都吃满，才会影响到其他人。判断方式很简单，看负载高但 CPU 使用率不高，就是 IO 卡住了，磁盘队列长而核多半在空转，这是典型特征。

装之前先列一张表，写清每个容器的内存上限、磁盘写入量和峰值核占用。八百元档那台 8163 二十四核 32GB 适合十来个轻量容器，内存重的服务别往里塞；九百元档同款处理器但内存 128GB，容器数量能翻几倍，数据库和缓存放这里从容得多。两台都能从这条渠道入口翻到。

容器内存上限怎么设才不会互相踩

每个容器都要显式写内存上限，别指望默认值。默认不限制等于给了某一个容器吃掉整台机器内存的权限，出事的时候没人拦得住，机器一多，这种事故就从偶然变成必然，提前设定上限是唯一成本最低的办法，改配置文件比半夜起来重启服务轻松太多，这一步做在部署之前，成本几乎为零。

上限按实测峰值的一点二倍设，留两成余量应对突发流量。设得太紧会频繁触发内存溢出，设得太松等于没设，两者都让排查变得困难，建议先在测试环境压一轮再定数，不过测试环境的数据量通常比生产小，别照搬测试结果直接上线，留出余量之后再看实际运行曲线。

所有容器上限的总和不要超过物理内存的八成。剩下两成留给页缓存和系统本身，页缓存对数据库类容器的性能影响非常大，被挤掉之后查询会慢得很明显，内存宽裕的机器页缓存命中率高，同样的查询能快上一截，这也解释了为什么同样的机器换个内存规格体验完全不同，配置表上差几行字，实际用起来差很远。

配一个内存监控，连续几天接近上限就说明该调整或者该拆机器了。等到进程被杀才动手，代价是一次业务中断加上一段时间的排查，远不如提前看曲线划算，告警阈值设在八成左右比较合适，太敏感会天天响，太钝又起不到提醒作用，试运行一周再定阈值比较靠谱。

镜像和日志把盘写满怎么办

镜像层是最容易被忽略的占用。每次构建都留下一层，几个月下来几百 G 很正常，盘满了之后第一个报错的往往不是构建而是数据库，清理之前先确认有没有镜像还被容器引用着。

定期清理无用镜像和悬空层，但别在生产高峰跑清理命令，删除动作会带来大量磁盘写入，和正在跑的业务抢 IO，安排在凌晨或者业务低峰时段更稳妥。

日志要限大小。容器默认的日志文件不轮转，一个话多的服务一天能写几十 G，出问题时想看日志反而打不开，日志级别的设置也直接影响写入量，生产环境别开调试级别。

给每个容器配日志轮转，按大小和份数限制，超出自动删。这一步在部署时就配好，比事后翻目录删文件省太多事，也避免误删还在用的日志，轮转之后按文件名模式检索即可，不影响排查。

数据文件单独挂卷，别放在容器的可写层里。容器重建一次数据全丢这种事故见过不止一次，重建命令执行得越顺手，损失越大，挂卷之后记得给卷做定期快照。

挂卷之后容量规划要按数据算，不能按镜像算。镜像大小基本固定，数据是一直在长的，两者的增长速度差一个量级，按增长速度留三成余量比较安全。

大容量机型在这个环节更从容。六 TB 机械盘那类配置适合放日志和历史归档，固态留给数据库和高频读写，分工清楚之后不会出现一边写满一边空着的情况，存储分层之后成本也更可控，具体配置在这条入口里能看到。

容器网络用什么模式更省心

单机多容器用桥接加自定义网络最直接，容器之间按服务名互访，端口只对外暴露真正需要的那几个，内部服务干脆不暴露，攻击面小很多。自定义网络里容器名就是主机名，换机器换 IP 都不用改配置，迁移时只需要重建网络再挂上卷，比记 IP 的老办法可靠得多，容器重启之后地址变化也不影响相互调用，排查时看到的也是名字而不是一串地址。

需要统一入口的挂一层反向代理，按域名分流到不同容器，比让每个容器去抢宿主机端口干净得多。证书和限流也集中在一处配，改起来不用逐个容器动，证书续期也只需要在一个地方处理，省掉不少重复劳动，限流和灰度也能在代理层统一做，改规则只动一处配置，不用挨个容器改参数，出了问题也只需要查这一层的日志。

直接占用宿主网络能省一层转发，延迟略低，但端口冲突会非常难排，除非整台机器只有一个服务要跑满网卡，否则不建议这么干，省下的一点延迟换来一堆排障时间不值，网卡队列和中断绑定这些细节还得单独调才能压到最低延迟，调完还得压测确认，工作量不小。单机场景里桥接模式已经够用，没必要为了几毫秒的差异折腾一整套网络调优，先把稳定性做上去，延迟优化留到真的有瓶颈时再谈，大多数业务先要解决的是稳定而不是快那几毫秒，等业务量上来、真出现延迟瓶颈时，再针对具体环节做优化才有意义。

什么时候该从一台拆成两台

拆机的信号之一是重启成本。一台机器重启，上面十几个服务同时中断，维护窗口越来越难约，一个小的系统更新要等到周末深夜才能做，业务方也开始抱怨维护通知太频繁，这个信号往往比监控告警更早出现。

信号之二是故障面。一个容器把内存吃爆，牵连的是整台机器上的所有服务，风险集中到这个程度已经不合理，本来互不相关的业务被绑在一起，一次内存泄漏能带走半条业务线，隔离的价值在出事的那一刻才体现出来。

信号之三是争抢变成常态。监控上长期看到 IO 等待或者内存贴着上限走，说明已经在硬撑，只是还没崩，这种状态下任何一次流量波动都可能成为压垮的那一次，这时候加配置也只是延后崩溃的时间点，不如直接按业务拆开。

拆的时候按业务分组，互相调用频繁的放一起，跨机调用少的放另一台，别按容器数量平均分。分错了等于把内网调用变成了跨机调用，延迟反而上去，分组的依据应该是调用链而不是机器规格，画一张调用关系图比翻配置更快看明白。

两台之间的数据同步和配置一致性要提前想。拆完才发现两边配置漂移、版本不一致，问题比合在一起时更多，事先写一份部署清单能省很多返工，用配置管理工具同步能省掉大量手工核对，改一处再分发比逐台登进去改安全。

预算允许的情况下宁可早拆。八百和九百这两档各买一台，等于同时买到隔离和冗余，比一台顶配硬撑更实际，这条入口里把两档放在一起对比，选型会快很多，早拆的代价只是多一份月付，换回来的是隔离和可维护性，这两样在业务长起来之后会越来越值钱。

预算八百和九百差在哪

这两档的处理器是同款 8163，二十四核四十八线程，真正的区别在内存容量和每月价格，同样的核心数跑起来手感是一样的。

八百那台 32GB，跑轻量容器和中小站点够用，适合起步阶段，压力主要来自单个服务而不是容器数量本身，容器数量控制在十个以内会比较舒服，超过这个数量就该开始看内存曲线了，曲线一旦往上走，多半是某个服务在悄悄泄漏，早点定位比扩容便宜。

九百那台 128GB，多出来的内存能放数据库缓冲池、缓存服务和更多容器，不用一上来就琢磨拆机，扩容的余地大得多，跑数据库时缓冲池能设得更宽裕，查询波动也小，缓存服务和消息队列也能一起放进来，一台机器承担多个角色时，内存是最先要够的那一项。

选哪个看现有服务的峰值内存总和。总和在物理内存一半以内选 32GB，超过一半直接上 128GB，省得半年后再迁移一次，迁移的时间成本通常比省下的钱更贵，算峰值内存时把缓存和连接池一起算进去，只看进程本身容易漏掉一大块。

价格差一百元，但迁移一次的成本远不止一百元，停机、验证、回滚预案加起来是几天的工作量，下单时很少有人把这笔账算进去，账算清楚之后选择其实并不难，难的是愿不愿意花半小时把这张表列出来，列完之后很多纠结自然就消失了。