部署
部署是游戏服务器构建的单个运行实例，创建用于托管比赛，并在比赛结束时销毁。它有一个地址、一个以分钟为单位衡量的寿命以及一个定义的容量。计算部署次数而不是机器数量是基于会话的托管的衡量和计费方式。
又称
游戏服务器部署，服务器部署
，
游戏服务器部署包含哪些内容？
部署是构建版本与比赛相遇的地方。无论是由匹配系统、服务器浏览器还是游戏自身的后端启动，其结果都包含相同的几点，并且每一点都是后端、服务器和玩家客户端必须达成一致的：
构建版本。 运行的确切镜像，以便比赛中的每个玩家都连接到相同版本的游戏。
规格大小。 它能获得多少 CPU 和内存，对于轻量级服务器，通常是 vCPU 的一小部分。
位置。 它在何处运行，理想情况下应靠近比赛中的玩家。
地址和端口。 玩家连接的公共地址和端口。外部端口通常与服务器在其容器内部监听的端口不同，这是首次连接失败的常见原因（端口映射）。
比赛数据。 服务器在启动时需要知道的信息，例如哪些玩家要加入、模式和地图，通常作为环境变量传入。
标签。 用于稍后在日志、仪表板和支持工单中查找该部署的标记。
当其中一个环节出现问题时，症状通常会体现在其他地方：玩家无法连接、服务器运行的是旧构建版本，或者出现无人能追踪的崩溃。
部署是如何开始和结束的？
启动通常是自动的。一旦玩家需要服务器，匹配系统或服务器浏览器就会请求部署，基础设施会选择其运行位置，然后容器启动。这所需的时间称为冷启动，而将一组玩家绑定到特定服务器称为服务器分配。
结束则需要更多考虑。部署通常以以下五种方式之一停止：
当比赛结束时，服务器通过调用停止端点来自行停止。
游戏的后端停止它，例如在所有玩家都离开之后。
达到最大持续时间。
服务器崩溃，并根据其重启策略，重启或保持停止状态。
底层机器停止服务。
第一种通常是最可靠的，因为服务器知道其比赛何时结束。最后两种情况也是为什么比赛结果和日志最好在发生时就发送，而不是保存到最后的原因，正如容器页面所描述的那样。
无人停止的部署将保持运行，并且在按使用付费的模型下，会持续产生费用。只要最大持续时间比最长的比赛还要长，它就是一个有用的保障机制。
会话或持久。大多数部署只持续单场比赛。持久世界、社交枢纽或 MMO 分片会让一个部署运行数天。云平台通常会限制运行时间，因此寿命较长的服务器通常运行在专用主机上，状态保存在容器外部，并按计划进行更换，而不是永远保留。
游戏服务器如何在无需停机的情况下进行更新？
“部署”（Deployment）有第二种含义：推出新构建。这是搜索蓝绿部署和零停机部署的目的所在。
对于基于比赛的游戏，单场比赛部署使这一过程几乎成为了内置功能。一旦发布了新构建，新的比赛就会在其中启动，而正在运行的比赛则在旧构建上结束。没有服务器会在原处进行更新，因此比赛不会受到干扰。使其发挥作用有两个条件：旧构建和新构建的并存时间可以与最长的比赛时间一样长，并且仍在使用旧客户端 solid 玩家会保留在旧版本服务器上或被要求更新。服务器分配涵盖了补丁发布日可能出现的问题。
蓝绿部署将同样的概念应用于整个环境：新版本与旧版本并存运行，流量进行迁移，而旧版本保持就绪状态以便回滚。持久化服务器是更难处理的情况。它们需要进行排空（将玩家迁移到新部署中），或者在最安静的时刻进行重启。
在 Edgegap 上，仅针对服务器的修复遵循单场比赛模式：新的应用版本指向新的镜像，一旦其上线，新比赛将使用它，而正在运行的比赛则在旧镜像上结束（撮合系统/匹配机制文档）。我们的自动滚动更新指南涵盖了更广泛的流水线。在容器中涵盖了唯一镜像标签，它能将回滚转变为指针更改。
为什么游戏服务器托管是用部署量来衡量的？
在基于用量的托管中，账单跟随部署而定，而非机器。每个部署在其运行期间根据其规模进行计费，这就是无服务器游戏服务器背后的模式。有两个因素决定了成本：每个部署的规模有多大，以及它存活了多长时间。在游戏允许的情况下，使用几分之一的 vCPU 来合理调整构建，或在一个多房间服务器中进行多场比赛，并按时停止部署，这通常比每小时费率更重要。当前的费率和计算器可在我们的定价页面上找到。
计算部署次数还可以衡量规模和速度。自 2019 年 2 月以来，Edgegap 已运行了 1.35 亿次游戏服务器部署，这一计数包括启动失败的部署。在滚动 30 天内，其从冷启动到容器就绪的中位部署时间为 2 秒，并在 2023 年 11 月的基准测试中维持了每秒 40 次部署（平台数据，2026 年 9 月 18 日）。启动失败的部署不会被收费（部署文档）。
来自我们的赞助商（其实就是我们自己！）的寄语
预热池（Warm pools）能实现快速分配，但您需要为处于闲置状态的服务器付费。Edgegap 从冷启动到容器就绪（在游戏引擎启动前测得）的中位时间仅为 2 秒，从而能即时开辟全新的游戏服务器，因此只有在比赛需要时才会存在服务器。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
让每一次部署都实现自我停止
很大一部分可避免的托管成本通常来自那些生命周期超过了游戏对局的部署：一个从未察觉到最后一名玩家已离开 solvent 的服务器、一个在周末一直运行测试部署、一个在循环中不断重启的损坏构建。只有当每次部署在其工作结束时也随之结束，按分钟计费才具有成本效益。
将停止机制内置到服务器中，而不仅仅是后端：当对局结束时，服务器自行关闭。然后进行检查。每周列出运行时间超过最长可能对局时间的部署。每一个部署要么是您打算保留的持久服务器，要么是需要修复的泄漏。
在 Edgegap 上，每个部署在启动时都会收到自己的停止 URL 和令牌，每个应用版本都可以设置最大持续时间作为保障，并且标签使测试部署易于查找和清理。
，
