你为什么要这样做?
尽管容器(containers)和 Kubernetes 是很酷的技术,但为什么我们要在此平台上运行游戏服务器?
-
游戏服务器的扩展很困难,并且通常是专有软件的工作 - 软件容器和 Kubernetes 应该使它更容易,并且编码更少。
-
容器为我们提供了一个可部署的工件,可用于运行游戏服务器。这消除了在部署过程中安装依赖项或配置机器的需要,并且极大地提高了人们对软件在开发和测试中能够像在生产环境中一样运行的信心。
-
通过将软件容器和 Kubernetes 结合使用,我们可以建立一个坚实的基础,从而基本上可以大规模运行任何类型的软件 -
从部署(deployment),运行状况检查(health checking),日志聚合(log
aggregation),扩展(scaling)等等,并使用 API 在几乎所有级别上控制这些事情。 -
从本质上讲,Kubernetes
实际上只是一个集群管理解决方案,几乎可用于任何类型的软件。大规模运行专用游戏需要我们跨机器集群管理游戏服务器进程 –
因此,我们可以利用在该领域已经完成的工作,并根据自己的特定需求对其进行定制。 -
这两个项目都是开源的,并且是积极开发的,因此我们也可以利用未来开发的任何新功能。
Paddle Soccer
为了验证我的理论,我创建了一个非常简单的基于 Unity 的游戏,称为 Paddle Soccer,该游戏实质上与描述的完全一样。这是一款两人在线游戏,其中每个玩家都是 paddle,他们踢足球,试图互相得分。它具有一个 Unity 客户端以及一个 Unity 专用服务器。它利用 Unity High Level Networking API 来在服务器和客户端之间提供游戏状态同步和 UDP 传输协议。
值得注意的是,这是一款 session-based 的游戏;
即:你玩了一段时间,然后游戏结束,你回到大厅再玩,所以我们将专注于这种扩展,并在决定何时添加或删除服务器实例时使用这种设计。
也就是说,理论上这些技巧也适用于 MMO 类型的游戏,只是需要进行一些调整。
Paddle Soccer 架构
Paddle Soccer 使用传统的整体体系结构来进行基于会话的多人游戏:
1.玩家连接到 matchmaker 服务,该服务使用 Redis 将它们配对在一起,以帮助实现此目的。
2.一旦两个玩家加入到一个游戏会话中,matchmaker 会与 game server manager 对话,让它在我们的机器集群中提供一个游戏服务器。
3.game server manager 创建一个新的游戏服务器实例,该实例在集群中的一台计算机上运行。
4.game server manager 还获取游戏服务器运行所在的IP地址和端口,并将其传递 matchmaker 服务。
5.matchmaker 服务将 IP 和端口传递给玩家的客户端。
6.…最后,玩家直接连接到游戏服务器,现在可以开始对战了。
由于我们不想自己构建这种类型的集群管理和游戏服务器编排,因此我们可以依靠容器和 Kubernetes 的强大功能来处理尽可能多的工作。
容器化游戏服务器
此过程的第一步是将游戏服务器放入软件容器中,以便 Kubernetes 可以部署它。 将游戏服务器放置在 Docker 容器中基本上与容器化其他任何软件相同。
这是用于将 Unity 专用游戏服务器放置在容器中的 Dockerfile:
FROM ubuntu:16.04
RUN