部署
了解部署及其生命周期——更深入理解的概念与最佳实践。
🗺️ 编排
在几秒内启动新服务器，以满足容量需求，采用我们的云原生边缘计算方法。我们把服务器视为 牲畜而非宠物 ——直接替换故障实例，而不是逐个手动维护。
在 Discord 联系我们 ，了解混合编排选项并优化你的托管成本。
要全面了解所有优缺点，让我们比较各种编排方法。根据游戏循环设计，有些游戏会使用多种编排方式。
匹配绑定
短生命周期（限时）服务器会在比赛结束时缩减，提供 最佳成本性能比.
会话通常通过一个自动化 匹配 服务来处理，该服务根据严格规则即时部署服务器，并可选择填充正在进行的服务器以 提升比赛填充率.
👍 优势
最佳成本效率——实时扩缩以逐分钟满足玩家需求。
由于无区域托管，DevOps 成本最低，Edgegap 自动化了 99% 的任务。
由于 Edgegap 公有云基础设施中有 615+ 个站点，延迟最低。
在出现意外流量激增时，扩容速度最快（爆发能力）。
最高标准的安全性和玩家作弊防护（服务器权威）。
意外服务器崩溃对玩家的影响最小，仅影响单场比赛。
👎 缺点
采用新的编排思维模型，初期需要一些上手努力。
运行超过 24 小时的服务器将自动终止。
🧩 最适合
对延迟敏感的游戏—— 当网络代码优化无法克服高延迟时：
第一人称射击、格斗游戏、VR 和 XR（虚拟与扩展现实），……
具有 按设计限制比赛时长上限的游戏,
大逃杀、 PvPvE、合作射击、MOBA、体育游戏、ARPG 和地下城爬行类，……
区域待机
持久世界和社交型 MMO 游戏 服务器生命周期通常超过单个玩家会话.
会话通常通过一个 服务器浏览器 基于玩家偏好（按区域自动分配或自定义搜索），并根据区域容量进行横向部署预扩容。
👍 优势
对于饱经战火的老兵来说，这是熟悉且易于理解的老派方式。
最高标准的安全性和玩家作弊防护（服务器权威）。
基于每月承诺，成本易于预测。
👎 缺点
托管成本更高——每个区域都需要一个或多个空闲待机服务器（突发容量）。
DevOps 成本更高——每个区域都要重复扩缩容、运维和维护。
玩家基数较小的区域因加入远处服务器而延迟较高。
🧩 最适合
即使玩家离线，服务器上仍保存用户生成内容的持久世界。
MMO、带基地建设或物体放置的沙盒、撤离射击游戏，...
对延迟容忍的游戏—— 当不需要服务器权威的实时物理时:
移动游戏、合作游戏、TCG/CCG、回合制策略，……
异步多人游戏， 服务器崩溃对玩家体验影响最小时：
与幽灵竞速、掠夺敌方基地、基于计时的建造/农场游戏，……
初始化过程繁重的应用——准备服务器需要几分钟。
点对点
将开发精力从 专用服务器 转移到 面向非竞技游戏的中继网络代码.
相关主题：监听服务器、玩家主机权威、NAT 穿透。
👍 优势
最低托管成本，只需中继服务器即可解决 NAT 穿透。
最低 DevOps 成本——只需维护客户端构建和分发渠道。
意外服务器崩溃对玩家的影响最小，仅影响单场比赛。
实现简单、原型开发速度快，无需任何后端开发。
👎 缺点
点对点网络代码开发工作量增加，需要并发编程技能。
延迟最差，也最容易受不利网络条件影响（例如移动网络）。
安全性最弱，容易受到中间人攻击和会话劫持。
如果你没有实现自定义主机迁移，主机离开时会有会话丢失风险。
🧩 最适合
合作与休闲游戏—— 当作弊不会削弱乐趣或破坏游戏时,
儿童游戏、探索游戏、冒险，……
查看我们的 分布式中继 该服务可使点对点连接具备同类最佳的延迟和安全性。
📍 服务器部署位置
无论你选择哪种编排方式，为一组玩家选择合适的服务器位置对于确保尽可能低的延迟和最佳玩家体验都至关重要。了解不同的服务器部署策略，以及它们如何影响你的玩家。
Edgegap 部署在 最佳可能的位置 ，并具备可用容量，以实现快速且低延迟的比赛。
服务器评分
服务器评分策略使用 Edgegap 的专利方法，该方法 会为每场比赛单独优化服务器的部署位置。通过非侵入式遥测来近似评估每位玩家与我们服务器位置的网络接近度，并选择能提供最佳以下方面的服务器：
响应性 ——为所有玩家平均提供最低延迟，
公平性 ——为所有玩家提供平衡且公平的延迟。
无响应的部署位置 ——服务器距离很远，所有玩家延迟都很高：
不公平的部署位置 ——延迟不均衡，一名玩家因更高延迟而处于劣势：
良好部署位置示例 ——所有玩家都具有响应快且公平的延迟：
地理位置
或者， 提供所需服务器位置的纬度和经度坐标：
⭐ 推荐： 找到最快的 ping 信标，并在用户字段中发送其坐标或 IP。
⚙️ 自定义：在你的游戏后端中定义区域（含坐标），通过自定义 API 获取。
👉 最适合测试： 在游戏客户端开发版本中硬编码定义区域（含坐标）。
不建议将此策略用于 部署 编排，除非应用程序对区域间数据传输有严格的监管要求，或者玩家 IP 不可用。
或者，让玩家 从列表中选择一个持久的（始终在线）服务器 带有 服务器浏览器.
区域锁定
一些工作室更喜欢锁定稳定且可预测的位置（例如 MMO，具有 持久化）。考虑 服务器浏览器 与 区域扩缩容策略 以及 自动分配预留.
不建议将此策略用于 部署 编排，除非应用程序对区域间数据传输有严格的监管要求，或者玩家 IP 不可用。
🟢 连接质量
有些游戏（和玩家）对延迟或卡顿比其他游戏更敏感。虽然玩家报告是大规模识别事故或回归 bug 的绝佳指标， 玩家可能缺乏对网络概念的深入理解 并且很快会将责任归咎于工作室、网络代码或服务器。
某些问题的根本原因可能对玩家是隐藏的，因此工作室与托管提供商的协作可能至关重要。 Edgegap 的首要任务始终是提供尽可能好的服务。
如果你收到大量玩家报告、遭遇大范围中断或反复出现的问题，请立即通过我们平台中的支持工单联系我们。
低延迟
玩家延迟是以下数据传输之间延迟的组合：
物理设备—— 物理信号跨越 互联网网络拓扑.
主机到主机 ——由协议、传输和安全措施导致。
进程到进程 ——由客户端/服务器中的数据（解）打包和处理导致。
Edgegap 通过将服务器放得更靠近你的玩家来减少物理延迟，从而缩短响应并减少网络跳数。借助横跨 17 家云和裸金属提供商的地点，你将获得 全球任何地方玩家的同类最佳延迟.
全球范围内服务器和互联网覆盖（不仅限于 Edgegap）受以下因素限制：
基础设施可用性 ——某一地区的互联网连接质量可能不足。
自然因素 ——服务器包含敏感组件，需要稳定环境（没有地震）。
高可用性
世界各地不同位置的服务器可用性会随时间变化，并在一天中多次波动。Edgegap 会自动 扩容/缩容 位置 按需，并考虑：
突发流量 ——在 15 分钟内完成的部署会影响扩缩容趋势。
资源需求 ——每个位置的总 vCPU 需求决定扩缩容速度。
提供商替代方案 ——某些偏远位置可用的提供商选项更少。
提供商容量 ——某些位置可能只提供 4 vCPU 或 8 vCPU 机器。
服务质量 ——某些提供商在同一区域内跨 ISP 提供更好的网络质量。
工作室时间安排 ——测试和 QA、封闭测试或锦标赛的特殊请求。
所有应用的部署请求都会合并，以评估各个位置的需求。默认情况下，所有组织具有相同的分配优先级。 工作室可以选择添加自定义 私有舰队.
请 联系我们以规划发布，或者如果你对位置可用性有任何请求。
玩家问题解决
玩家问题有时可能由服务器或托管 bug 引起，但往往无关——也要考虑网线/Wi‑Fi 连接、互联网服务提供商、后端服务，或客户端/服务器底层库中的 bug。
在排查玩家报告或事故时，请考虑以下因素：
区域网络和 ISP 问题：
本地互联网服务提供商（ISP）可能暂时正在处理一起事故，
某些地区（例如中国、俄罗斯）可能因当地制裁而受到限制。
缓存级别 ——没有缓存时，你的会话可能会因部署较慢而超时：
最大部署时间 ——部署可能因初始化过程缓慢且繁重而失败：
参见 应用与版本 以延长超时时间。
服务器镜像或集成问题 在自定义构建流水线的早期迭代中。
在客户端对战历史 UI 中显示部署 ID 以便在排查时追踪玩家报告。
🔄 部署生命周期
Edgegap 部署会经历几个生命周期阶段，由部署状态标示。
1. 启动部署
用于 测试目的 的部署可以通过以下方式启动：
Unreal Engine ——用于 Unreal Engine 项目的 Docker 扩展或 EGIK 插件。
Unity ——用于 Unity 项目的托管快速入门插件。
Godot ——用于 Godot 项目的托管快速入门插件。
Dashboard Web UI ——用于快速服务器测试和迭代的简易网页界面。
手动启动你的部署，复制 URL 和端口在实时游戏中行不通。
使用以下任一方式，自动化热门游戏流程，以管理会话并按需扩展：
保存 request_id （部署 ID）并为部署添加标签 以便日后识别和排查问题。
2. 正在部署
一旦启动部署，我们的系统会迅速连续执行多个步骤：
遥测——我们正在测量从可用数据中心到每位玩家的网络响应性，
部署——我们正在预留容量并准备启动你的服务器容器，
容器启动——我们正在启动容器、安装依赖并进行初始化，
后处理——我们正在添加日志存储、监控并完成部署。
启用 在您的应用版本中启用缓存 在几秒内部署服务器。
请求过多 429 ——为确保稳定并防止意外账单，我们将你的组织速率限制为 40 req/s. 联系我们 以规划发布、估算上线流量并为成功做好准备。
3. 部署就绪
一旦部署就绪，你的引擎仍有工作要做。引擎会引导子系统和框架，然后将包括地图在内的资源加载到内存中。这发生在部署变为就绪之后，通常最多需要 1 分钟，具体取决于你的优化程度。
重试玩家连接几次，直到预定义的超时时间结束，然后再退出并启动新会话。服务器通常在完全初始化之前不会接受新的玩家连接。
服务器崩溃处理取决于您的 进程重启策略. 服务器状态可能会丢失.
根据版本的 应用与版本 状态，你可能会收到：
🟢 缓存命中
已启用缓存。由于重复使用此机器上预加载的镜像，部署更快。
🟡 热启动
已禁用缓存。由于重复使用在同一机器上为上一次部署下载的镜像，部署更快。启用缓存可在全球范围内始终保持快速部署。
🔴 缓存未命中
已启用缓存。由于缓存传播完成前突然出现流量激增，部署变慢了。在你的部署请求中启用“要求缓存位置”将阻止这种情况，但在意外流量激增时可能导致更多不可处理的部署。
🔴 冷启动
已禁用缓存。部署更慢，镜像是在部署时下载的。启用缓存可加快部署。
4. 部署错误
由于意外原因，你的部署可能会在任何时间点变为不可处理状态。这种情况更可能发生在测试你的集成，或测试新的服务器构建时。
错误部署不会向你收费，它们会在 24 小时后自动停止。
故障排查步骤：
通过 我们的正常运行时间监控页面.
尝试使用 Docker Desktop 在本地测试你的服务器容器，以排除 Edgegap 问题。
寻求帮助时， 请包含你的部署 ID 和任何有用的细节 以便我们及时调查！
5. 部署停止
云部署将在运行 24 小时后终止 ，这符合我们的服务器清理政策，用于基础设施维护，并防止当部署因意外 bug 未正确关闭时累积意外成本。
对于运行超过 24 小时的长期服务器，请考虑使用 私有舰队 与 持久化.
使用以下方法优化你的成本并提前停止空闲部署：
应用版本 重启策略 ——防止在关闭或崩溃时自动重启。
游戏最长时长 ——你在 应用与版本 中分配的时间
通过 DELETE_URL ——玩家离开且比赛结束后，部署自行停止。
查看 Unreal Engine 以及 Unity SDK 工具和简易集成指南，或使用 API。
从自定义后端停止 ——你的自定义会话编排可能会使用 部署 API.
私有舰队 承载你部署的主机已通过计划任务被删除。
👀 可观测性
让游戏服务器能够与第三方互操作并获得运维洞察。
可发现性
一旦就绪，部署将被分配一个 URL（fqdn）以及每个内部端口对应的外部端口。
使用 部署标签（最多 40 个字符）来轻松标记你的部署 以便日后查找。
WebSocket（WS）和安全 WebSocket（WSS）
要在 Edgegap 中使用基于 websocket 的网络代码，你有两个选择：
托管证书，无需编写任何代码即可在 1 分钟内完成设置：
配置你的 应用与版本 转移到 使用 WebSocket（WS）并启用 TLS 升级，
使用 Edgegap URL 连接客户端（例如
https://5fa53fa00a57.pr.edgegap.net/)
自主管理证书，如果你想使用自己的自定义域名：
配置你的 应用与版本 转移到 使用安全 WebSocket（WSS）,
使用自定义 DNS 记录配置你自己的 TLS 证书流程（例如在 Cloudflare).
未捕获的服务器异常会导致部署容器重启并使 TLS 安全失效。在这种情况下， 停止你的服务器 以及 将玩家重新匹配到新的部署. 服务器状态可能会丢失.
注入变量
游戏服务器通常需要额外信息，例如服务器 IP、内部端口值或其他信息。注入只读环境变量是一种可靠、与云无关的方式来传递参数。
使用以下方式获取变量值： Unity SDK, Unreal EGIK，或者使用你运行时的环境变量方法。
自定义变量
为每个部署定义最多 20 个自定义变量，每个变量最多包含 4KB 的字符串数据。
避免使用下面的保留名称，否则你的自定义变量会被覆盖！
通过读取 Edgegap 注入到你服务器中的变量获取重要信息：
标识符
ARBITRIUM_REQUEST_ID- 例如：f68e011bfb01.唯一部署 ID，也称为 request ID。用于获取更多信息。
部署 URL 始终采用以下格式：
{ARBITRIUM_REQUEST_ID}.pr.edgegap.net.
ARBITRIUM_PUBLIC_IP- 例如：162.254.141.66.此主机的公网 IP 地址，可用于连接而不是使用 URL。
ARBITRIUM_HOST_ID- 例如：alpha-north-america-70364ef8.承载你部署的机器的唯一标识符，与其他部署共享。
ARBITRIUM_DEPLOYMENT_TAGS- 例如：tag1,tag2.以逗号分隔的用户自定义部署标签， 便于搜索和筛选.
ARBITRIUM_PRIVATE_FLEET_ID- 例如：PUBLIC_CLOUD，如果托管在其上则为舰队 ID 私有舰队.
资源规格
ARBITRIUM_HOST_IN_PRIVATE_FLEET- 例如：false，表示是否托管在其上 私有舰队.ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY- 例如：2300，处理器频率，单位 MHz。ARBITRIUM_DEPLOYMENT_VCPU_UNITS- 例如：256，分配的 vCPU 单位（1024 = 1 vCPU）。ARBITRIUM_DEPLOYMENT_MEMORY_MB- 例如：512，分配的 RAM，单位 MB（1024 = 1 GB）。
生命周期管理
ARBITRIUM_DELETE_URL- 例如：https://api.edgegap.com/v1/self/stop/9f511e17/660.可从部署中调用， 部署将优雅停止.
需要唯一的一次性
ARBITRIUM_DELETE_TOKEN位于Authorization头中。
ARBITRIUM_DELETE_TOKEN- 例如：7df4cd933df87084b34ae80d8abde293.ARBITRIUM_CONTEXT_URL- 例如：https://api.edgegap.com/v1/context/9170f5211e17/17.只能从部署中调用，返回更多部署详情。
需要唯一的
ARBITRIUM_CONTEXT_TOKEN位于Authorization头中。
ARBITRIUM_CONTEXT_TOKEN- 例如：dfaf50b9333b9ee07b22ed247e4a17e6.
可发现性
ARBITRIUM_PORT_GAMEPORT_INTERNAL- 例如：7777，服务器监听器的内部端口。ARBITRIUM_PORT_GAMEPORT_EXTERNAL- 例如：31504，客户端连接的外部端口。出于安全考虑，每个部署的外部端口值都会随机生成。
ARBITRIUM_PORT_GAMEPORT_PROTOCOL- 例如：UDP，你的网络代码传输协议。
以下示例假设你已将端口命名为 gameport （默认）。 每个端口都会额外添加一组已清理的 应用与版本 变量： @Super Port! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .
ARBITRIUM_HOST_BEACON_PUBLIC_IP- 例如：139.177.198.69，最近信标的公网 IP。ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL- 例如：30199，用于通过 UDP 测量延迟。ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL- 例如：30456，用于通过 TCP 测量延迟。
结构化信息（以字符串形式的 JSON）
仪表板监控
我们的 仪表板 提供用于监控服务器可扩展性并辅助运维的工具。
分析
查找 侧边栏菜单中的分析仪表板 位于“服务器托管与编排”类别下。
🌟 升级到按需付费套餐 以解锁详细的服务器性能指标和洞察：
常规洞察： 监控发布版本的实时服务器数量 + 资源使用概览，
CPU 洞察：排查因处理器密集型操作导致的服务器卡顿，
内存洞察：缓解因超出分配内存而导致的服务器重启，
网络洞察： 检测低效的网络模式并优化网络代码。
部署地图
在以下位置查找部署地图： 仪表板上的部署详情页.
在地图上预览部署位置、可用位置和估计的玩家位置：
部署平衡点
在以下位置查找部署平衡点热图： 仪表板上的应用详情页.
预览部署平衡点热图并按以下条件筛选 应用与版本。平衡点是近似位置，在给定部署中到每位玩家的网络距离相同：
部署日志
在以下位置查找部署日志： 仪表板上的部署详情页.
部署日志显示有关以下内容的信息： 部署:
容器日志
在以下位置查找容器日志： 仪表板上的部署详情页.
在出现问题或调试时检查你的游戏服务器日志：
一旦部署停止，容器日志将被删除。 设置 第三方 S3 日志存储 以保存日志。
容器指标
在以下位置查找容器指标： 仪表板上的部署详情页.
查看容器指标（处理器、内存、网络），以：
识别以下情况下的常见连接问题 部署,
检测导致资源使用激增的低效实现模式，
在特定场景下精确定位低效的资源使用，
验证优化过程中服务器资源使用的变化，
对服务器初始化的资源消耗和时长进行基准测试。
历史指标以 1 分钟时间间隔显示平均值，免费套餐可用。
🌟 升级到按需付费套餐 以解锁 1 秒时间间隔的精确指标。
上下文与状态
可通过 JSON 格式检索其他部署信息：
请求过多 429 - Context 和 Status API 的速率限制为每个组织 20 req/s。 这些 API 旨在用于特殊操作，而非自动化会话编排。
使用 Webhooks 用于自定义会话编排，以避免速率限制并确保可扩展性。
筛选部署
若要在所有部署中快速搜索，你可以 使用我们的仪表板:
或者，让玩家 从列表中选择一个持久的（始终在线）服务器 带有 服务器浏览器.
使用 API 列出部署 并通过后端集成应用筛选条件：
位于 或 不在数组中
[ "7e709a0d8efd", "4ba353100b4b" ]
位于 或 不在数组中
[ "tagA", "tagB" ]
位于 或 不在数组中
[ "my-app", "my-other-app" ]
位于 或 不在数组中
[ "1.0.0", "prod" ]
位于 或 不在数组中
[ "fleet-eu", "fleet-us" ]
ilike
"%-eu%"
位于 或 不在数组中
[ "alpha-north-america-95fab093" ]
ilike
"%north-america%"
按请求中字段出现的顺序对结果按多个字段排序：
升序 或 降序
available_session_sockets
升序 或 降序
示例筛选查询：
别忘了添加 Authorization 请求中的头部，并携带你的 Edgegap API 令牌。
Webhooks
在你的游戏后端接收关于以下内容变更的简单 HTTP 通知： 部署 通过在你的 部署 API 请求中指定 webhook URL。适用于：
同一部署绝不会同时触发 Ready 和 Error webhook。
Webhook 是自定义后端部署集成的主要推荐方式。
Webhook 不会被重试，如果你的后端由于限流或错误而未处理该请求，可能会丢失。如果在预期时间内未收到 webhook，请改用 Status API。
🚨 故障排查
排查部署问题时：
在本地运行你的服务器，以排除集成错误，
查看本页上的故障排查步骤，
请通过 社区 Discord 并附上你的部署 ID。
最后更新于
这有帮助吗？