业务编排器
业务排布器（Orchestrator）是决定每个游戏服务器实例在何处以及何时运行、启动它并在事后将其关闭的系统。它位于您的匹配系统和基础设施之间：匹配系统表示比赛已准备就绪，排布器则在合适的位置为此比赛提供服务器。
又称
game server orchestrator
，
What Is a Container Orchestrator?
A container orchestrator runs containers across a group of machines. You declare what should run, such as five copies of a web service, and it keeps that true: it places each container on a machine with room, restarts any that fail, and adds or removes copies as load changes. Kubernetes is the most widely used.
Inside, an orchestrator usually has an API that takes requests, a scheduler that picks where each container runs, a record of what runs where, health checks, and cleanup. The scheduler is one part of the orchestrator, not the whole of it.
Most container orchestrators treat the copies as interchangeable. Any one of them can be stopped to scale down, move to another machine or roll out an update, because another copy serves the next request just as well. A game server holding a live match isn’t interchangeable: stopping it ends the match for every player on it. A game server orchestrator starts from that difference and manages each server as a match with its own lifecycle.
What Does a Game Server Orchestrator Do That a Container Orchestrator Doesn't?
Compared with a general-purpose container orchestrator, a game server orchestrator typically:
Starts a server per match on request, and makes its address and port available, once it’s ready, to the matchmaker or backend that asked.
Doesn’t stop a server while its match runs to scale down or rebalance. The server ends when its match does, or at a set maximum runtime.
Exposes each server’s ports to players, usually UDP, often mapped to a different port outside the container (port mapping).
Places each server by where its players are, rather than wherever a machine has room.
How it knows each server’s state differs between orchestrators. Some track it through an SDK added to the server build; others manage it from outside, through an API, environment variables and a stop call the server makes when its match is over.
Do Live Matches Depend on the Orchestrator?
Not once they're running. An orchestrator is a control plane: it decides where servers run, starts them and stops them. The game server is the data plane: players connect to it directly, and match traffic doesn't pass through the orchestrator. The orchestrator matters most at the moment a match needs a server.
That makes two things worth checking in any orchestrator: how it keeps placing new servers when a provider or location has a problem, and what the game does while a request is retried. Whatever the orchestrator, a client that holds the player’s place in the queue and retries with backoff turns a slow start into a short wait.
Edgegap’s orchestrator runs as a managed service and places servers across 17+ infrastructure providers (as of 18 September 2026), so a new server can be placed with another provider if one has an outage. Hosting needs no Edgegap SDK in the game server: any container image deploys worldwide from a single API call, the server reads its ports and match details from environment variables, and it can end itself with one HTTP call when the match is over (docs). Match servers start and stop on demand on Edge Cloud, while persistent servers, such as a world that keeps its state between sessions, run on Private Fleets (fleet management).
来自我们的赞助商（其实就是我们自己！）的寄语
预热池（Warm pools）能实现快速分配，但您需要为处于闲置状态的服务器付费。Edgegap 从冷启动到容器就绪（在游戏引擎启动前测得）的中位时间仅为 2 秒，从而能即时开辟全新的游戏服务器，因此只有在比赛需要时才会存在服务器。
