使用MagicOnion开展实时通信(后续)

2020年Happy Elements《快乐元素》圣诞倒数日历活动,第八天内容。

继《第7天的日志》之后,我是”梦境传说”的工程师,岸本。

在之前的文章中,我介绍了MagicOnion的基本部分以及服务器配置的思路。

这次,我想介绍一些关于基础架构的话题,比如Kubernetes和Agones,以及具体的流程。

本内容所述为当前正在开发中的内容,实际规格可能会有所不同!

Kubernetes / Agones:容器编排系统与游戏服务器托管

现在,为了实现之前讨论的内容,我们面临着基础设施方面的问题。

通过使用Kubernetes和Agones来解决这个问题。
(不会详细解释Kubernetes和Agones!)

容器编排

Kubernetes是一个容器编排系统,可以负责部署和扩展容器化应用程序的工作。

对于像服务发现和实时通信服务器这样由多个服务器组成的微服务,它非常适合本次这样的场景,并且是一个非常强大的系统。然而,如果要在状态为全局的配置下实现实时通信,可能会出现一些问题。

    • サーバーを直接外部に公開できない。

 

    • Kubernetes では、サーバー (Pod) を直接外部に公開することはできず、

 

    • Service というロードバランサーのような仕組みを経由させて公開する必要があり、

 

    • 特定のユーザーを特定のサーバーに接続させたい場合、若干不向きな仕組みになっています。

 

    • スケーリングからの保護ができない。

 

    • ユーザーの常時接続が必要なリアルタイム通信サーバーが、

 

    • Kubernetes の スケーリング の対象となって、

 

    意図しないタイミングでシャットダウンされると困るので、やはり若干不向きな仕組みになっています。

为了解决这个问题,我们将使用Agones。

比赛

Agones 是一个用于在 Kubernetes 上运行有状态实时通信服务器的扩展系统。

    • サーバーを直接外部に公開できる!

 

    • Agones では、公開可能な IPアドレス を サーバー (Pod) に割当することで、

 

    • Service を介さず、直接外部に公開できるようになります。

 

    • スケーリングから保護できる!

 

    • Agones では、サーバー (Pod) のステータスを管理できるようになっていて、

 

    使用中 (Allocated) なサーバーは、Kubernetes の スケーリング から保護されるようになります。

由於這些特點,Kubernetes 使得處理有狀態的即時通訊服務器變得更加方便,成為適合運營即時通訊服務器的系統。

整体构图

1208_01.png

通过组合这些机制,云平台的大致结构如下。
(请注意,由于运营上可能还需要其他组件,因此这并不是全部!)

服务发现和实时通信服务器

1208_02.png

从软件上来看,它被构建成这样的形式。

Service Discovery 是在 Kubernetes 上运行的服务器,使用 MagicOnion 的 Service。

实时通信服务器是在Kubernetes上运行的服务器,使用MagicOnion的StreamingHub。

在一个服务器上,我们通过多个端口托管了多个主机。除了供客户端使用的公开API外,我们还单独设置了专用于服务器间通信的内部API,并进行了分割。

此外,您可以通过查询Kubernetes和Agones的API来了解Kubernetes内部的各种信息,例如其他服务器的信息。

以下是一个基于命令的简单示例,该示例可以获取正在运行的实时通信服务器(游戏服务器)在Agones中的列表,并获取可以公开的外部IP地址和端口信息。(这是在Minikube环境下的结果。)

$ kubectl get gameserver
NAME                    STATE   ADDRESS          PORT   NODE       AGE
real-time-xhxkn-8szj7   Ready   192.168.99.100   7400   minikube   24m
real-time-xhxkn-ff4rp   Ready   192.168.99.100   7101   minikube   24m

在包括C#在内的多种语言中,Kubernetes和Agones的SDK已经公开发布,通过它们,您可以从应用程序内部获取类似的信息。

处理流程

以聊天作为例子,我们来考虑具体的处理流程。

我們前提是參與特定群組專用的聊天室,如派對或公會,而不是完全隨機的聊天室。

1208_03.png
    1. 因为用户(客户端)不知道聊天室(实时通信服务器)的连接地址,

 

    1. 所以向服务发现(API服务器)查询聊天室的连接地址。

服务发现想要获取运行在Kubernetes上的聊天室列表,
所以向Kubernetes查询。

服务发现根据聊天室列表检查分配情况等,
保证用户请求的聊天室能够被分配。
此时,聊天室声明为已分配给Agones,
并受到Kubernetes的扩展保护。

服务发现将聊天室的连接地址返回给用户。

用户连接到从服务发现得到的聊天室。
然后,双向通信能够在客户端和服务器之间一直建立,
从而能够自由地进行聊天。
当所有用户离开聊天室并且不再需要时,
聊天室将宣告为可关闭给Agones,
并重新成为扩展的目标。

虽然走了一段长路,
但是如果能够到达这一步,
那么就可以建立一个以状态为基础的实时通信环境,
并且能够运行得差不多了。

我认为只需根据要求进行定制化,就可以实现想要的功能!

额外的附赠品

部署机制

我們的設計基於使用AWS運作,以下是我們建立的部署流程機制。

1208_04.png

通过更改容器镜像的版本来解决问题,这是 Kubernetes 中最基本的部署方法之一,需要在目标服务器的 Deployment(或 Agones 的 Fleet)中指定。

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: hoge
        image: hoge:v1.0 → hoge:v2.0

在Merクストーリア中,我们构建了从管理界面上可以部署的机制,并且可以通过应用程序内部进行Deployment和Fleet的补丁操作,即使可以通过自动化实现对该yaml定义的更新。

如果将源代码提交到GitHub,CodeBuild将会自动构建容器,并将其推送到ECR。
您可以通过管理界面访问ECR仓库,并选择要部署的图像版本,以进行部署。

此外,由于在Agones管理下使用的实时通信服务器,需要实现优雅关闭功能,例如保持连接的切断,这个问题可以通过运行部署批处理来解决。

通过这样做,我们尽可能地消除了手动操作,并确保了安全的部署。

保密事项的处理

以下也基于AWS运行
为了能够处理秘密信息,我们采用了以下流程。

1208_05.png

在Kubernetes中,有一种机制可以处理名为”Secret”的敏感信息,但是,如果要在Secret中处理例如私钥之类的东西,则需要注意管理方面的问题。

因此,我们决定使用 AWS 的 SecretsManager 来管理机密信息,并通过应用程序内部与 SecretsManager 进行交互,以使其能够反映到 Kubernetes 的 Secret 中。

通过这样做,可以避免将机密信息嵌入到代码中,避免将其提交到Git中或在本地进行管理。

总结一下

以下是关于使用MagicOnion进行实时通信机制的介绍!

由于它仍处于开发阶段,我们只能提供很少的具体实例,包括必要的技术介绍在内,因此内容相对较为繁琐,不知道您觉得如何?

目前在日本国内,选择采用魔术洋葱(MagicOnion)和C#作为游戏服务器端的情况还相对较少。在我们的卡卡利亚工作室,客户端普遍使用Unity(C#),而服务器端主要采用Ruby on Rails(Ruby)。

在这样的环境下,使用MagicOnion、Kubernetes和Agones等进行开发可能会变得相当具有挑战性。希望这对于对实时通信和服务器端C#等感兴趣的人有所帮助!

招募团队成员

在Happy Elements株式会社的卡卡力工作室,我们正在大力招募能共同创造受到热情喜爱的内容的成员!

如果您对我们公司感兴趣的话,一定要前往下面的招聘网站查看。
Happy Elements株式会社招聘专用网站。

请继续享受Happy Elements Advent Calendar 2020!谢谢!

广告
将在 10 秒后关闭
bannerAds