
容器
容器是一个正在运行的、隔离的打包应用程序实例,包含了它执行所需的一切。对于多人游戏,它通常为一场比赛保存一个游戏服务器进程:在比赛开始时启动,在比赛结束时销毁。隔离意味着一个服务器的崩溃会保留在其容器内部,而其宿主机上的其他容器则能保持运行。
又称
容器化
,
为什么每场比赛都会有专属的容器?
因为一场比赛是游戏服务器生命周期的自然单位。對局配對会组成一场比赛,容器从服务器镜像启动,玩家进行连接,比赛进行,然后容器被销毁。下一场比赛会获得一个从相同镜像启动的新容器。
这让每场比赛都拥有相同的起点:没有上一场比赛遗留的任何东西,没有内存泄漏,没有陈旧的状态,没有未完成的存档。一个只在服务器运行六小时后才会出现的漏洞,在 20 分钟的比赛中几乎没有机会出现。
它也改变了您付费的对象。仅在比赛运行期间存在的服务器仅在比赛运行期间计费,而不是为了应对最繁忙的时间而一直保持机器开机。一个运行时间长、接连进行比赛的服务器进程也可以工作,但它会将状态从一场比赛带到下一场比赛,并且需要提前规划其容量。
并非所有游戏都适合这种模式。持久性世界以及在一个进程中承载多场比赛的多房间服务器运行时间要长得多。下面的最后一节将介绍它们如何保持健康。
容器隔离了什么,又共享了什么?
容器可以将服务器的进程、文件和资源配额与旁边的其他容器隔离开来。如果一个服务器崩溃或发生内存泄漏,问题会被限制在其容器内,而相邻的其他比赛则会继续运行。
限制是确保安全共享主机的关键。每个容器都会分配到 CPU 和内存配额,并且主机会严格执行这一限制。这正是避免喧闹邻居(noisy neighbour)干扰的有效手段:隔壁繁忙的比赛无法夺取分配给另一台服务器的 CPU 或内存,因此与其他比赛或与其他工作室的服务器共享主机,不会改变您比赛的运行状况。不过也存在反向的隐患:如果服务器超出了其内存限制,主机会在比赛中途将其终止。请在您的目标玩家数量下测量峰值内存,并将限制设置在峰值之上,以此适应比赛中最繁忙的时刻,而非平均水平。
容器还共享主机的网络,这也是许多首次部署时常遇到障碍的地方。游戏服务器在其容器内部监听一个端口(通常是 UDP),而主机会将其映射到外部的不同端口。玩家需要的是外部端口。如果服务器报告其内部端口,或者客户端假定了一个固定端口,将无法建立连接。编排器(orchestrator)知晓这一映射关系,并将外部地址和端口传递给向玩家提供连接详情的任何组件。
关于容器与虚拟机的对比,请参见 Docker。
容器销毁后,匹配数据去了哪里?
哪儿也不会去,除非你先把它发送到某个地方。容器的文件系统会随着容器的消失而消失,因此任何值得保留的东西都必须在比赛结束前移出。
比赛结果和玩家进度。 在比赛结束时将它们写入你的后端(例如数据库或玩家数据服务),而不是写入可能被关机中断 class="" 的定时器中。
日志。 将它们传输到外部存储。在 Edgegap 上,容器日志会在部署停止后被删除,官方文档建议使用第三方 S3 存储桶来保留这些日志,并通过端点存储(Endpoint Storage)(文档)进行注册。请在第一次真正的游戏测试之前设置好该存储桶,而不是在遇到第一次无法解释的崩溃之后。
崩溃转储和回放。 如果你以后需要它们,规则与日志相同。
持久化世界是个例外,因为它们的状态必须比任何单个容器存活得更久。世界状态会以固定时间间隔保存到容器外部的存储中,新容器在启动时会加载该状态。该时间间隔决定了崩溃可能会造成多少进度损失。
游戏工作室是如何保持游戏服务器容器健康的?
两种习惯可以解决大部分问题。
定期回收。即使是永远不打算停止的服务器,也能从替换中受益,因为进程运行的时间越长,内存泄漏和漂移就会积累得越多。Edgegap 的 Edge Cloud 将容器的连续运行时间限制在 24 小时以内(定价),这有助于培养这种习惯。对于持久性服务器,通常的方法是在最闲暇的时间启动一个新容器,将玩家转移过去或等待旧容器排空,然后将其停止。
为每个镜像赋予唯一标签。每次构建都会生成一个带有绝不重复使用的标签的镜像,例如带有计数器的日期或提交哈希值。这样,测试分支和正式环境就可以通过不同的标签并存运行,而回滚只需将正式环境重新指向之前的标签,而不是重新构建。避免在标签中包含环境名称,这样通过测试的构建就是最终发布的完全相同的构建。
来自我们的赞助商(其实就是我们自己!)的寄语
预热池(Warm pools)能实现快速分配,但您需要为处于闲置状态的服务器付费。Edgegap 从冷启动到容器就绪(在游戏引擎启动前测得)的中位时间仅为 2 秒,从而能即时开辟全新的游戏服务器,因此只有在比赛需要时才会存在服务器。
Edgegap 的观点(仅代表个人意见,姑且听之即可!)
视每个容器为可丢弃的
容器的设计初衷就是为了被停止。那些会带来麻烦的服务器,往往在设计时被假定为永远不会停机。
设计时应确保丢失一个容器不会造成任何损失:比赛结束时写入结果,日志存入存储桶,按计划进行回收。然后进行测试。在游戏测试中,在比赛中途停止一个容器,并列出丢失的内容。该列表中的每一项都是一个 Bug,而且通过这种方式发现 Bug 通常比通过玩家报告发现要更省钱。
只有在快速更换容器的情况下,一次性容器才起作用。在 Edgegap 上,根据滚动 30 天的数据计算,在游戏引擎启动前,从冷启动到容器就绪的服务器部署时间中位数为 2 秒(平台数据,2026年9月18日)。
,










