游戏服务端

问题形容咱们国内的华为联运游戏集成华为游戏服务SDK 之后，被审核驳回：在未装置或须要更新华为挪动服务（HMS Core）的手机上，提醒装置华为挪动服务，点击勾销，未再次提醒装置HMS Core。 问题解决我分割了华为技术反对（在此提单），对方让我先复现问题并取日志看报错信息，我复现后看日志，发现这种场景下，初始化失败，会返回错误码907135003。在开发者领导文档上搜寻该错误码，能够间接疏导到游戏初始化章节。 我点进去参考发现文档和示例代码都已阐明该错误码场景的解决方案： 也就是说，初始化失败，返回错误码907135003，此时须要咱们再调用init接口，我依照这样批改了代码从新测试，提醒装置HMS Core，点击勾销后，能够再次弹出HMS Core的更新弹框了。问题失去解决，现已从新提交审核，并审核通过。 文档参考链接： https://developer.huawei.com/consumer/cn/doc/development/HMSCore-Guides/game-start-0000001050123475 PS： HMS Core装置异样问题的复现条件要求： 可用非华为手机测试：当时卸载掉HMS Core； 可用华为手机测试：要先回退HMS Core版本（在手机-设置-利用治理-HMS Core-卸载更新）

在前三篇文章中，咱们将游戏服务器托管在 Kubernetes 上，测量并限度它们的资源应用，并依据应用状况扩充集群中的节点。当初咱们须要解决更艰难的问题：当资源不再被应用时，放大集群中的节点，同时确保正在进行的游戏在节点被删除时不会中断。 从外表上看，按比例放大集群中的节点仿佛特地简单。 每个游戏服务器具备以后游戏的内存状态，并且多个游戏客户端连贯到玩游戏的单个游戏服务器。 删除任意节点可能会断开流动玩家的连贯，这会使他们怄气！ 因而，只有在节点没有专用游戏服务器的状况下，咱们能力从集群中删除节点。 这意味着，如果您运行在谷歌 Kubernetes Engine (GKE) 或相似的平台上，就不能应用托管的主动缩放零碎。援用 GKE autoscaler 的文档“ Cluster autoscaler 假如所有复制的 pod 都能够在其余节点上重新启动……” — 这在咱们的例子中相对不起作用，因为它能够很容易地删除那些有沉闷玩家的节点。 也就是说，当咱们更认真地钻研这种状况时，咱们会发现咱们能够将其合成为三个独立的策略，当这些策略联合在一起时，咱们就能够将问题缩小成一个可治理的问题，咱们能够本人执行： 将游戏服务器组合在一起，以防止整个集群的碎片化当 CPU 容量超过配置的缓冲区时，封闭节点一旦节点上的所有游戏退出，就从集群中删除被封闭的节点让咱们看一下每个细节。 在集群中将游戏服务器分组在一起咱们想要防止集群中游戏服务器的碎片化，这样咱们就不会在多个节点上运行一个任性的小游戏服务器集，这将避免这些节点被敞开和回收它们的资源。 这意味着咱们不心愿有一个调度模式在整个集群的随机节点上创立游戏服务器 Pod，如下所示：而是咱们想让咱们的游戏服务器pod安顿得尽可能紧凑，像这样:要将咱们的游戏服务器分组在一起，咱们能够利用带有 PreferredDuringSchedulingIgnoredDuringExecution 选项的 Kubernetes Pod PodAffinity 配置。 这使咱们可能通知 Pods 咱们更喜爱按它们以后所在的节点的主机名对它们进行分组，这本质上意味着 Kubernetes 将更喜爱将专用的游戏服务器 Pod 搁置在曾经具备专用游戏服务器的节点上（下面曾经有 Pod 了）。 在现实状况下，咱们心愿在领有最专用游戏服务器 Pod 的节点上调度专用游戏服务器 Pod，只有该节点还有足够的闲暇 CPU 资源。如果咱们想为 Kubernetes 编写本人的自定义调度程序，咱们当然能够这样做，但为了放弃演示简略，咱们将保持应用 PodAffinity 解决方案。也就是说，当咱们思考到咱们的游戏长度很短，并且咱们将很快增加(and explaining)封闭节点时，这种技术组合曾经足够满足咱们的需要，并且打消了咱们编写额定简单代码的须要。 当咱们将 PodAffinity 配置增加到前一篇文章的配置时，咱们失去以下内容，它通知 Kubernetes 在可能的状况下将带有标签 sessions: game 的 pod 搁置在彼此雷同的节点上。 apiVersion: v1kind: Podmetadata: generateName: "game-"spec: hostNetwork: true restartPolicy: Never nodeSelector: role: game-server containers: - name: soccer-server image: gcr.io/soccer/soccer-server:0.1 env: - name: SESSION_NAME valueFrom: fieldRef: fieldPath: metadata.name resources: limits: cpu: "0.1" affinity: podAffinity: # group game server Pods preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchLabels: sessions: game topologyKey: kubernetes.io/hostname封闭节点当初咱们曾经把咱们的游戏服务器很好地打包在一起了，咱们能够探讨“封闭节点”了。“封闭节点”到底是什么意思?很简略，Kubernetes 让咱们可能通知调度器：“嘿，调度器，不要在这个节点上调度任何新货色”。这将确保该节点上不会调度新的 pod。事实上，在 Kubernetes 文档的某些中央，这被简略地称为标记节点不可调度。在上面的代码中，如果您专一于 s.bufferCount < available，您将看到，如果以后领有的 CPU缓冲区的数量大于咱们所须要的数量，咱们将向戒备节点发出请求。 ...

你为什么要这样做？只管容器（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 应用传统的整体体系结构来进行基于会话的多人游戏： 玩家连贯到 matchmaker 服务，该服务应用 Redis 将它们配对在一起，以帮忙实现此目标。一旦两个玩家退出到一个游戏会话中，matchmaker 会与 game server manager 对话，让它在咱们的机器集群中提供一个游戏服务器。game server manager 创立一个新的游戏服务器实例，该实例在集群中的一台计算机上运行。game server manager 还获取游戏服务器运行所在的IP地址和端口，并将其传递 matchmaker 服务。matchmaker 服务将 IP 和端口传递给玩家的客户端。…最初，玩家间接连贯到游戏服务器，当初能够开始对战了。因为咱们不想本人构建这种类型的集群治理和游戏服务器编排，因而咱们能够依附容器和 Kubernetes 的弱小性能来解决尽可能多的工作。 ...

我的世界是很火的游戏，能够本人DIY剧情和倒退脉络，充沛享受发明的乐趣。 接下里就带你一分钟搭建MC私服——v1.7.10版本。 先说后果，自己做好镜像后公开这个镜像仓库，这样HCaaS用户都能够应用这个镜像： mirror.cubepaas.com/github-clz/mc-server:KCauldron1. 创立mc服务端工作负载 登入HCaaS，通过“工作负载”去“部署服务”，在Docker镜像处抉择“镜像地址”，而后填入下面的那个镜像仓库地址（dockerhub下面也有很多镜像能够尝试） 配置好容器规格（低于8X服务会起不来），端口映射，mc私服只须要关上25565端口，而后抉择客户端能够拜访的网络模式——L4层负载平衡 第一步配置完了，间接跳到第三步。在镜像中配置的默认启动参数是“-Xmx4096M -Xms512M”,如果本身有不同的配置参数，能够在“命令”栏通过sed -i命令来替换"/mc/mc-trigger-file.sh"启动脚本中的-XMmx参数和-Xms参数 点击确认，而后就等着工作负载启动和生成SLB拜访地址。 2. 下载v1.7.10的客户端（参考 HCaaS收费搭建Minecraft服务器--东阳君の博客 底部） 关上客户端，在“多人模式”下，连贯工作负载中SLB拜访地址。而后就能够自在徜徉MC的世界里了。 -----------------------------镜像制作分割线---------------------------------- 啰嗦一下制作镜像的过程 ① 筹备软件包，服务端zip包和启动脚本 目前不反对rar格局，须要本人转化为zip格局，不要带最外层文件夹。Minecraft-1.7.10-server.zip 启动脚本： #!/bin/bashjava -Xms512M -Xmx4096M -jar ./KCauldron.jar nogui② 开启镜像仓库（有帖在先这里不赘述了） ③ 疾速部署--抉择模板类型，本例用Jar模板 ④ 制作“业务镜像” 抉择镜像下拉菜单：制作镜像（再次部署就能够抉择已有镜像） 构建环境：本例中应用java8 镜像仓库凭证：第一步镜像仓库配置实现后下拉菜单中就能够抉择对应的镜像库 设置好镜像名称和tag：以自带镜像仓库为例，镜像名称后面跟着我的项目名 上传服务端压缩包和启动文件mc-trigger-file.sh 而后填写启动脚本的门路。 点击“制作镜像”就开始了制作。直到显示success ⑤ 共享镜像 进入镜像仓库，点击“公有”，变成“公开”，而后小伙伴就能够下载仓库里的镜像了 进入刚刚制作的镜像页面，获取镜像下载地址： 这样你就能够把本人做的镜像分享给小伙伴了。HCaaS让私服更自在~