Global Edge Cloud locations
Distinct deployment targets where a game server container can be scheduled on demand.

迁移
/
PlayFab
保留 PlayFab。您的匹配系统、经济系统、身份验证和玩家数据都保留在原处:只有服务器移动,随之移动的还有您为在高峰期之间闲置等待的备用容量所支付的 Azure VM 账单。
移除 GSDK,将您已有的构建进行容器化,并让 Cloud Script 函数在找到匹配的瞬间部署到 Edgegap。私有车队(Private Fleets)在专用硬件上承载您的基础流量,而超出车队的需求则会爆发到 615+ 个边缘云节点,这些节点在请求时放置,并根据匹配中玩家的数据进行测量。
哪些发生了变化(以及哪些没有变化)
PlayFab Multiplayer Servers 的迁移是托管服务的变更,而非后端的变更。以下是您在迁移过程中可以期待的事项。
具体的逐项特征分析请参见下文的步骤 3:识别并替换特征。
保持不变的是什么
您的网络代码和传输层
Edgegap 绝不干涉您的传输、序列化或 Tick 循环。容器运行的正是您今天构建的同一服务器二进制文件。
您的 PlayFab 后端
對局配對 队列和规则、玩家数据、经济系统、身份验证、排行榜以及 CloudScript 都将保留在 PlayFab 中。此次迁移仅涉及 Multiplay 服务器,不会影响您游戏中的其他任何内容。
您的客户端连接流程
您的客户端仍然会获取一个地址和端口并连接到它。在文档记录的桥接中,它仍然像现在一样从 PlayFab 玩家数据(Player Data)中读取这些信息。
引擎、版本与持续集成
相同的引擎、相同的版本、相同的构建流水线。除了推送镜像之外,您的 CI 不需要任何新步骤。
有哪些变化
GSDK 发布了
PlayFab 游戏服务器 SDK 保留了您的二进制文件:代理启动、就绪和会话回调,以及它在循环中运行的健康和状态报告。而 Edgegap 不需要服务器 SDK。您的服务器在部署时直接从环境变量中读取其公网 IP 和端口。
一次部署调用即可替换备用池
PlayFab Cloud Script 函数无需从您提前预配的容量中请求服务器,而是在找到匹配项时向部署终结点发布一次,并为该匹配项创建部署。
区域不再是购买决策的限制因素
您不再需要逐个区域规划虚拟机容量。在请求发起时,每次部署都将根据匹配中的玩家进行测算,并放置在边缘云网络中最佳的可用位置。
备用计算不复存在
无需计算备用目标,无需针对每个区域调整百分比阈值和乘数,没有缩容窗口,也无需在高峰期之间保持池的温备。容量不再是您需要操心的工作:专用舰队(Private Fleets)会随着您流量曲线的变化而与我们一同自动调整大小,而边缘云(Edge Cloud)则完全不需要进行任何预配置。
预期时间表
步骤 1
移除 PlayFab 游戏服务器 SDK:代理启动、就绪和会话回调,以及健康和状态报告循环。
~2 小时
步骤 2
如果您已经交付了 Linux 容器构建版本,该制品将保持不变。仅限 Windows 的构建需要先进行 Linux 服务器构建,这是本次迁移中唯一真正艰巨的任务。
~30分钟至2小时
步骤 3
Edgegap 的镜像仓库可免费使用,或者您也可以继续使用 ACR、DockerHub、GitLab 等。
~30 分钟
步骤 4
match_found 规则上的 Cloud Script 函数会发布到部署终结点,然后您的服务器将该地址写回玩家数据。
约1天
第 5 步
在全球边缘云(Edge Cloud)上进行部署,还可选择通过专属机群(Private Fleets)免流量费托管来进一步降低成本。
即时部署
详细迁移步骤
如果您希望将游戏服务器从 PlayFab Multiplayer Servers 迁移出来,同时保留 PlayFab 的其他功能,只需按照以下简单步骤操作即可立即运行。完整指南(包括一个可运行的 Unity 示例)请参阅:PlayFab Bridge。
在开始之前,弄清楚什么是移动的、什么是不移动的会很有帮助。
仅移动 Multiplayer Servers:PlayFab 保留您的联机匹配器、玩家数据、经济系统和身份验证,而 Edgegap 成为运行匹配服务器的地方。Edgegap 是一个 API,没有服务器 SDK。
我们希望:您当前正在使用 PlayFab Multiplayer Servers,您拥有一个可以工作的游戏服务器版本,并且您可以在您的游戏标题中编辑 CloudScript。
Edgegap 不需要 SDK 即可进行集成。第一步是移除游戏服务器中初始化 PlayFab Game Server SDK 的代码:代理启动调用、您为服务器激活和会话分配注册的回调、关机和维护处理程序,以及代理在循环中期望的健康和玩家状态报告。没有任何东西能替代它们。在 Edgegap 上,您的服务器从部署时注入的环境变量中读取它所需的内容,包括其公网 IP 和端口映射,并且一旦开始监听,它就可以随时为玩家提供服务。如果您使用的是 GSDK 包装器而不是直接集成,那么它也会被移除,并且 PlayFab 的官方文档也指出该包装器“不适用于生产环境”。
如果您已经在 PlayFab 上运行 Linux 容器构建,那么此步骤只是一项检查,而不是重新构建:确认镜像在本地构建并启动,然后将其推送到 Edgegap 的免费注册表,或者保留 ACR、DockerHub、GitLab 或任何其他兼容 OCI 的注册表。
如果您的游戏运行的是 Windows 虚拟机构建,则首先需要一个 Linux 服务器构建。这是一项切实的工作,但 Edgegap 针对 Unity、Unreal Engine 和 Godot 的专用插件可帮助您在拥有 Linux 服务器目标后自动构建镜像。
GSDK 功能 | Edgegap 替代方案 |
|---|---|
游戏服务器 SDK (GSDK) | |
构建版本和虚拟机大小 | 应用和版本。 为每个版本选择 vCPU 和内存,可从 0.25 vCPU 起进行细分。 |
构建区域 | 无需配置区域。在请求时跨 615 多个边缘云位置进行布置以实现按需计算,可使用 专属机队 (Private Fleets) 获得预留容量。 |
备用服务器和目标备用算法 | 按需计算(边缘云)的自动扩缩容。使用 专属机队 (Private Fleets) 维持持续的基准,每月进行合理调整。 |
动态和计划备用 | 不需要。突发流量至边缘云是自动完成的。 |
RequestMultiplayerServer | 只需向部署端点发送一个 POST 请求,可来自 CloudScript 或 您的后端。 |
PlayFab 匹配系统 | 保持不变。match_found 规则会触发部署。 |
服务器连接详情 | 由您的服务器写入 PlayFab 玩家数据 (PlayFab Player Data),并由您的客户端读取,这与已发布的桥接示例完全一致。 |
服务器日志和归档服务器 | 部署日志、部署状态 API (Deployment Status API) 和部署 Webhook (Deployment Webhook)。 |
Game Manager 中的服务器管理 |
专属舰队是与您目前管理的容量最接近的选择:持久、专用的主机,且提供免流出费用的托管服务。
不同之处在于围绕它们的工作。无需计算备用目标,无需调整每个区域的阈值或乘数,也没有缩容窗口。您只需每月调整舰队规模,超出部分的流量会自动分流到边缘云(Edge Cloud)。
定价
了解与您目前的 PlayFab Multiplayer Servers 账单相比,Edgegap 的编排服务如何具有成本效益。
PlayFab 官方指南建议根据准备时间(propping time)和分配率来确定备用池的大小,并指出处于准备和备用状态的服务器费用将记入您的游戏项目。
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
空闲容量 | 计费。备用和准备中的服务器在峰值之间运行并计费 | 在边缘云(Edge Cloud)上不计费。零活跃部署的成本为 $0 |
尺寸估算方法 | 根据每个地区的准备时间和目标分配率计算备用目标 | 边缘云上无需估算尺寸。私有舰队(Private Fleets)每月调整至合适尺寸 |
故障模式 | 备用池枯竭:当需求超过预配速度时,服务器请求将失败 | 部署按每场比赛创建,从中位数来看,从零开始预配到容器就绪仅需 2 秒 |
您在 PlayFab 上购买的是机器配置。您在 Edgegap 上购买的是算力。
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
单位 | 每个构建区域根据核心数、内存和存储选择虚拟机尺寸 | vCPU-分钟,可从 0.25 vCPU 起分拆 |
细粒度 | 整台机器,外加由您管理的单机服务器打包组合 | 按部署计费,无需做打包组合决策 |
费率 | 根据 PlayFab 公布的价格表,按虚拟机尺寸和区域计费 | 全球统一价格,每 vCPU 每分钟 $0.00115 |
为峰值估算尺寸的舰队在周中的大部分时间都是空闲的。而为谷值估算尺寸并在需要时弹性扩容的舰队则不然。
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
基准 | 您按区域规划的备用池,通过阈值和乘数进行调整 | 私有舰队(Private Fleets),随着流量曲线的变化每月调整至合适尺寸 |
弹性扩容(Burst) | 动态备用会乘以您配置的目标备用,最高可达您的最大服务器限制 | 自动扩容到边缘云(Edge Cloud),拥有超过 615 个节点,在发起请求时进行部署 |
数千 CCU(同时在线用户)下的净效应 | 容量规划成为一项持续的运营任务 | 通过合理优化的分流,比纯云端降低 25% 至 35% 的成本。在价格计算器中进行模拟 |

客户
共有 15 个从其他平台迁移到 Edgegap 的工作室案例研究可供参考。

迁移现场运维多人游戏到Edgegap以解决DevOps工作负载
发现为什么#1 VR提取射手游戏是由Edgegap的游戏服务器托管和 orchestration提供支持的。
Case Study

能够即时扩展并改善最终用户体验的持久服务器
了解《岛屿》如何通过Edgegap的全球持续服务器部署提升玩家体验。
Case Study

借助 Edgegap 的游戏服务器编排,几天内迁移了一款轻松治愈的 MMO
Qloud Games 如何在不到 24 小时内将 Loftia 的游戏服务器托管迁移到 Edgegap,并成功举办了一场拥有数千名同时在线玩家的完美封闭测试
Case Study

大规模VR战争:Triangle Factory在Edgegap上发布Forefront 1.0
Triangle Factory 如何将其雄心勃勃的 VR 射击游戏迁移到 Edgegap,并充满信心发布了完整的 1.0 版本。
Case Study

从点对点到公平对决:《Bloody Bastards》启用专属服务器
了解 Tibith Ltd 如何将拥有 4000 万次下载的热门手游《Bloody Bastards》从 P2P 迁移至 Edgegap 的专用服务器和匹配系统,从而确保每场比赛都由服务器端进行权威判定。
Case Study

Noodlecake 如何实现多玩家游戏并让人忘却服务器的存在
Noodlecake 如何将 《Super Flappy Golf》 迁移至 Edgegap 的自动编排系统,并重新专注于游戏开发。
Case Study

竞争激烈的VR游戏需要与之匹配的基础设施:Breachers 迁移至 Edgegap
了解 Triangle Factory 如何将其竞争激烈的 5v5 VR 射击游戏引入专为该类型游戏所需精度而构建的基础设施。
Case Study

使用 Edgegap 的 Fleet 实现完全自动化的服务器管理流程
了解蓝鸭工作室如何使用Edgegap的Fleets API来协调其足球游戏的服务器。
Case Study

Edgegap 上的 1047 Games:平稳的迁移与发布
了解 1047 Games 如何将《Splitgate: Arena Reloaded》迁移到 Edgegap,并在其编排服务上发布 Empulse,同时在整个过程中保持托管服务的稳定可靠。
Case Study

从自制编排到一夜之间达到五万名玩家
Slipstream Games 如何将服务器成本降低 50%,将其延迟从 200-250 毫秒减少到 100-110 毫秒,并在 CrazyGames 上发布,24 小时内达到了 50,000 名玩家。
Case Study

从车队到按需:为一款独立滑板车游戏提供专用服务器
iScoot 如何从基于整批服务器的托管迁移到按需、基于实例的编排,从而将专用服务器缩小到原来的 1/10,并构建出适合独立游戏的成本模型。
Case Study

按需、按预算:Triangle Factory 将 Hyper Dash 引入 Edgegap
一款免费 VR 射击游戏如何利用随玩家规模缩放的按需基础设施,保持快速运行、全球覆盖和高成本效益。
Case Study
了解 Edgegap 自动化游戏服务器编排如何带来无缝的多人游戏体验。
研究方法
每个指标都说明了测量的内容、时间窗口以及排除的内容。基准测试结果的日期可追溯到产生这些结果的测试,并且不会重述为当前数据。
Where servers can run, and how many we have run.
Distinct deployment targets where a game server container can be scheduled on demand.
Locations where a studio can reserve dedicated bare-metal or VM hosts for its exclusive use.
Total game server deployments orchestrated since February 2019, including deployments that failed to start, the same basis our competitors use.
How fast our orchestration delivers a server, and what it sustains under test.
From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Started deployments per second, averaged over a continuous 60-minute benchmark. Available to each game from confirmed studios with live traffic.
Concurrent sessions reached on real game server containers, at 100 players per server.
What we commit to contractually for our orchestration, and what the monitors record.
Committed under our SLA. Trailing 90-day measured uptime: 99.999%.
Cloud and bare-metal providers under contract and carrying production traffic. Failover is automatic.
Live component status is published at status.edgegap.com.
One entry per metric: what is measured, how, and over what window.
A location is a distinct deployment target: one datacenter site at one of our infrastructure providers, in which a game server container can be scheduled on demand. Sites are counted once each regardless of how many providers operate in the same metro, and count only while accepting deployments.
Back to the metric ↑The subset of the 615+ where a studio can reserve dedicated bare-metal or VM hosts for its exclusive use rather than deploying into shared on-demand capacity. Published live on the Fleet Manager page. This is also the number that carries the included-egress allowance.
Back to the metric ↑Counted as total deployment records since February 2019, including deployments that failed to start, the same basis our competitors use.
Back to the metric ↑From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Back to the metric ↑The orchestrator started real game server containers continuously for 60 minutes, averaging 40 started deployments per second over the full hour, counted at deployment start rather than at ready state. Measured across 550+ locations and 17 providers in November 2023. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑In November 2023, the platform sustained 40 game server deployments per second for 60 minutes across 550+ locations and 17 providers, reaching 14 million concurrent sessions at 100 players per server. Game servers were real containers; player clients were simulated. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑Availability is committed at 99.99% under our SLA and measured continuously against five independently monitored components: Container Registry, Dashboard, Public API, Public Documentation and Website. Trailing 90-day measured uptime: 99.999%. The live figure is published on status.edgegap.com.
Back to the metric ↑Distinct suppliers under contract and carrying production traffic, counted at corporate-entity level. Failover across providers is automatic; it is the premise of the multi-cloud architecture.
Back to the metric ↑What gets reviewed, on what cadence, and what carries its own date.
Platform figures on this page are reviewed and refreshed quarterly. Metrics drawn from live sources (availability and game server deployments) carry their own as-of dates and are updated as measured. Benchmark results are dated to the test that produced them and are not restated as current figures.
Edgegap 是托管和编排方面的专家。我们的平台专为帮助您加速开发流程而构建,让您可以专注于自己擅长的事情——开发。
不需要。本次迁移仅移动 Multiplayer 游戏服务器。您的 matchmaking 队列和规则、玩家数据、经济系统、身份验证、排行榜以及 CloudScript 都将保留在 PlayFab 中,并像现在一样正常工作。该集成是 match_found 规则上的一个 CloudScript 函数,用于在 Edgegap 上部署服务器,以及在您的服务器中写入几行代码,将地址和端口写回玩家数据中以供客户端读取。我们在 PlayFab Bridge 指南中发布了完整的内容,包括一个 Unity 示例。
它被移除后,并没有任何专有技术来替代它。代理启动、就绪和会话回调、关闭处理程序以及健康报告循环都将不复存在。在 Edgegap 上,您的服务器在部署时从环境变量中读取其公网 IP 和端口映射,并且一旦开始监听即处于就绪状态。如果您是通过 PlayFab 的 GSDK 包装器而不是直接进行集成,该包装器也需要移除;他们自己的文档也指出,该包装器“不适用于生产环境”。
今天,您需要根据支撑时间和分配率来计算备用目标,设置每个区域的最大服务器数量,并调整动态备用阈值和系数以防止资源池枯竭,而处于支撑和备用状态的服务器费用将一直计入您的账单。在 Edge Cloud 上,没有资源池的概念:每次匹配都会获得一次部署,从零开始配置,中位数时间为 2 秒(测量至容器就绪,在游戏引擎启动之前)。如果您想要已经属于自己的容量,Private Fleets 可以为您提供,且按月调整大小,无需按区域进行微调。
这是此页面上唯一可能需要实际工作的部分,所以在这里坦白地说:Edgegap 运行 Linux 容器,因此仅支持 Windows 的服务器在进行其他任何操作之前,都需要先构建一个 Linux 版本。对于大多数 Unity 和 Unreal 项目,这只是一个构建目标以及对特定平台代码的检查。如果您的服务器依赖于仅支持 Windows 的库,那它就是一个项目,需要诚实地评估这对您的架构意味着什么。我们非常乐意与您探讨这一问题:请与我们的工程师联系,我们将与您一起完成向 Linux 游戏服务器实例的迁移。如果您已经在 PlayFab 上交付了 Linux 容器构建版本,则不适用以上任何内容,您的构件也将保持不变。
是的。您的玩家体验到的队列、规则、工单和匹配行为都保持不变,因为 PlayFab 仍在进行匹配。改变的是最后发生的事情:match_found 规则不会从您预配的容量中请求服务器,而是运行一个 CloudScript 函数,向 Edgegap 的部署端点发送一次包含玩家位置的请求,从而为实际参与该场比赛的玩家部署服务器。如果您以后想进行整合,可以使用 Edgegap 的无代码匹配器,但此次迁移完全不需要它。
这主要源于当您在等待时,为您已停止付费的容量买单。PlayFab 会对处于“准备中”和“待命”状态的服务器进行计费,因此,一个为您的峰值分配率而设计的服务器池,在每个闲置的时间里也依然会运行并产生费用。而在 Edge Cloud 上,零活跃部署的成本为 $0,计算费用为每 vCPU 每分钟 $0.00115,且可从 0.25 vCPU 起进行细分,而不是您在每个区域中选择的固定虚拟机大小。在数千个并发用户(CCU)的情况下,对私有集群和 Edge Cloud 进行合理优化的拆分,其成本将比纯云端降低 25% 到 35%。您可以在我们的价格计算器中模拟您自己的流量,而无需盲目相信这个范围。