在过往的文章，我们介绍了Agones的网络、生命周期以及弹性扩缩的特性。在本篇文章，我们将介绍Agones的一些其他特性，并对Agones的定位和使用进行一定程度的总结。最后，谈一谈游戏云原生的展望。
其他特性
- 玩家追踪。在之前介绍SDK时，有提到与Player相关的方法，其实在GameServer的Spec中可以定义player的相关字段，比如
initialCapacity，将gs的初始容量设置为10，随着游戏的运行，游戏服也可以通过SDK.Alpha().SetPlayerCapacity(count)调用实现容量的改变。之前提到过可以使用SDK调用SDK.Alpha().GetPlayerCount()实现当前玩家数目的获取，游戏本身可以通过容量和当前数目的对比实现玩家管理，而Agones仅提供追踪作用，不会影响玩家连接行为。 - 本地模式。在开发测试的场景下，需要通过Agones GameServer暴露服务，可以指定
agones.dev/dev-address开发机IP，使用StaticportPolicy，创建一个gs但不创建pod。快速的进行调试。 - 多集群分配。为了允许从多个集群进行分配，Agones 提供了一种机制来为分配请求设置重定向规则到正确的集群。
GameServerAllocationPolicy是 Agones 定义的用于设置多集群分配规则的 CRD。除了集群优先级，它还描述了目标集群的连接信息，包括游戏服务器命名空间、agones-allocator 端点和用于重定向分配请求的客户端 K8s secrets名称。游戏服务器将从priority数量最少的集群中分配。如果编号最小的集群中没有可用的游戏服务器priority，它们将从priority编号次之的集群中分配。对于具有相同优先级的集群，选择集群的概率相对于其权重。 - 延迟测试。在全球部署服务时，客户端会需要根据延迟决定要连接到哪个集群。Agones默认安装并暴露了这样的测试服务，支持http/udp两种协议。
总结
首先，我们要清楚看到Agones是针对Delicated Game Server而设计的云原生负载，比较适合MOBA/FPS/TCG等有对局概念、需要匹配的游戏类型。这类游戏的特点就是生命周期短，更偏向无状态，可以快速地构建、删除Pod，实现资源的最大程度利用。所以，Agones的核心是提供了动态伸缩的能力，然而想要最大程度利用Agones伸缩性，需要配合OpenMatch使用。
OpenMatch是Google开源的另一项目，它提供了一种匹配机制，用户可自定义匹配方法在这套框架下实现对局的匹配。从实现逻辑上来看，Agones这部分是比较轻量的，重头部分在于OpenMatch提供的匹配能力，OpenMatch相对与Agones显得非常厚重，用户要想接入需要进行相对复杂的工作，也有不少公司在这部分做文章提供Saas服务，简化客户端接入。
如上文所述，Agones最佳实践的方式是通过每个Fleet配置一个FleetAutoscaler，定义buffer量，压缩高峰期的游戏服启动时间对用户的延迟体感，allocator会发现ready状态的gs服务，将其置为allocated，等待玩家匹配连接，而MatchMaker会做一系列匹配工作，找到这样的allocated gs，让其与玩家建立连接，等到对局结束，gs销毁或复用，旧pod（或新pod）又进入到ready状态。这里buffer定义的是allocated和ready的差值，如果现在的匹配需求并没有那么多，也就是allocated数量没有那么多，总体要创建的pod数量也会下降，这样一来弹性功能得以实现，资源的利用率将会得到提升。
展望
虽然Agones作为云原生游戏负载简化了游戏上云的复杂度、并提供了弹性扩缩的能力，但它依然有一些不可忽视的问题
- 它并不适合生命周期长的游戏服，类似pve大世界类型游戏。这种游戏每个副本的状态差异是非常大的，提供水平伸缩的Fleet不适合管理这类游戏。
- 它通过SDK实现状态感知，增加了改造成本，提高了游戏开发者接入的难度。
- 它的网络模式是固定的，hostPort的方式并不能适用于所有场景。比如，对于一些IP端口固定的场景就无法满足。
其实，在实际的游戏市场中，MMO/MMORPG这类游戏的比重是非常大的，对于这类游戏的云原生化是不可忽视的需求。这类游戏重状态、弱弹性，目前在K8s中运维管理是非常复杂的，如何对这类游戏进行云原生改造是业界需要关注的问题。那么你觉得如何游戏云原生的痛点在哪？要如何做呢？
