关于我们

质量为本、客户为根、勇于拼搏、务实创新

新闻公告

< 返回新闻公共列表

使用云服务器作为微信小游戏开发架构服务器的优劣势分析

发布时间:2019-11-27 10:26:09

优势就是可靠性高,单节点鼓掌不影响整体可用性,以及另好扩展和收缩。局限性,无状态化要求对存储层补写数据。对于这个问题我们往往把比较高的对象缓存到节点内存中,这对 LB 就提出一些要求。因为扩展中需要知道发送给某个对象的发送到哪个节点,它是要建立对象到节点的流动性关系,显然通用的 LB 是没有办法做到这一点的。

另外一个问题在这个架构中同时节点没有办法发送请求,但是对于游戏来说,我们很多时候希望同时的节点之间发送请求。比如说我们向好友发送组队邀请的时候,好友的对象和我的对象不在同一个节点,那么就需要将请求发送到好友的节点,然后再转发到好友的客户端。

但是对于无状态化分层架构来说往往就需要通过共享数据,存在实时性和性能损耗的问题。为了解决这两个问题,我们看一下星型的架构。不同节点之间通过 router 进行剖析,实现节点之间共融的仪器。比如说 A 节点中的 Player1 对象要向发送 B 节点中的 Play2 对象发送请求、邀请,可以将消息发送到 router,router 再转发到大节点处理之后再发送到朋友客户端。在这个结构中,所有的节点都是对等的关系,中间的 router 可以实现互通,它是比较灵活。但是它有一个明显的问题,router 是一个单点,有容缩小和可扩展性。建立(英)可以实现主备的自动切换,主节点不行的时候可以切换到节点。他们之间的连接,我们可以把多结构连接在一起实现架构的扩展。比如说 Player1 在(英)发送 A 节点,Player 发到 B 节点。当 Player1 向 Player 额 2 发送组队邀请的时候,可以将消息先发送到 router1,router1 再转发到 router2,最终到达 B 节点。router 能够将消息发到对象,它就要保持全局的这样一个装。

我们看一下 router 做了哪些事情?收敛链接,简化内部通信管理,建立通用的对象陆游机制,简化游戏开发。第三通过 router 我们也可以实现负载均衡和广播,router 具有通用性,可以作为通用的游戏界面。

在扩展性方面,我们可以在两个层面进行扩展,比如说可以发现节点不够的时候可以进行添加,分散相应的 router,然后加入到系统中来。当一个达到极限的时候,我们可以通过副机来进一步做扩展,添加新的。假设我们有 0 和 1,需要添加 2 的时候这个流程可以是这样的。我们先对 2 进行部署,当 2 起来的时候,router1 和 router2 可以发现新节点,并且建立到它的连接。连接之后 router2 会向 router1 或者 router0 并且将自己的信息同步给 router1 和 router0,这样就建立了。当 play2 登录到 router2 的时候,router2 会将信息同步给 router2 和 router0,这是架构的扩展过程。

扩展的信息结构在云服务器的实践,像比较高的游戏,比如说坦克大战游戏我们实行多点布局,比如说华南的玩家可以加入到华东,广州的 UPC 和上海的 UPC 可以实现内网连接。

下面我们看一下存储层的设计,我们的目标是建立一个大存储层以满足动态扩容的问题。我们要满足数据库水平扩展的问题,如果自己做的话有三种方法。第一种基于增量区间的分配,它的由点是可以实现动态扩容,但是存在性能热点的问题。因为永远都是访问量最大,而老分片随着流失出现性能限制的情况;第二种方法,根据 ID 的闪电池分散到不同的分片,没有性能热点的问题,但是加新的节点的时候,往往对数据进行单切,比较难以实现快速自动扩容。第三种方法就是将两者结合,可以同时解决两个问题,需要增加中间的数据路由。

为了简化大存储的设计,我们可以用一些分布式数据库产品,比如说云服务器的 DCDB,它的原理是通过增加中间的代理层,到多个物理感,像复杂性完全封装在代理层,。这两个图是我们对 DCDB 做性能测试,第一个图是单分片对比 MYSQL 的性能,随着 CPU 的核和现存数的增加呈线性增长。DCDB 支持新发现的扩容和现有的扩容。扩容池系统会自动进行搬迁并且切换相应的流量,可以做到对业务层进行感知。我要做的只要在页面中点击几下按钮。

第二个产品是 TCaplus,特点有三个支持 Protobuf 接口访问,接口友好,适合游戏开发,第二个,将 Cache 与硬盘结合,第三村塾空间无上线,单表最大支持 sotb。TCaplus 目前在腾讯内部得到最广泛的应用,数百款游戏都是以 TCaplus 作为主数据库,其中包括王者荣耀、绝地求生等游戏。


/template/Home/Zkeys/PC/Static