如何快速开发微信小游戏 性能并实现性能监控

微信小游戏 性能新增分包加载功能运用分包功能后,或微信小游戏 性能代码包总上限可提升至 8M运维中心新增加载性能监控,帮助开发者了解并优化小程序加载性能

1、分包加载功能升级开发者可以将微信小游戏 性能代码分成多个包,每个包不超过 4M从而根据用户需要,在合适时机下载指定包而非全部

随着微信小游戏 性能的玩法越来越丰富,开发者对于扩大包大小的需求越来越强烈所以我们推出了微信小游戏 性能分包加载这一个功能。 所谓的分包加载即把游戏内容按一定规则拆分这几包,在首次启动时先下载必要的包这个必要的包我们称为「主包」,开发者可鉯在主包内触发其它分包的下载从而把首次启动的下载耗时分散到游戏运行中。

分包加载包大小的限制目前微信小游戏 性能分包大小有鉯下限制:

  • 整个微信小游戏 性能所有分包大小不超过 8M
  • 单个分包/主包大小不能超过 4M
使用方法1. 分包配置需要先在 game.json 配置分包信息

假设游戏的目錄结构如下:

root: 'stage1/' // 可以指定一个目录,目录根目录下的 game.js 会作为入口文件目录下所有资源将会统一打包 }配置在 subpackages 字段内的目录或 js 文件,将按照配置打包成一个个「分包」没有配置在 subpackages 中的目录和 js,将会被打包到主包中
// 分包加载失败通过 fail 回调
运用分包功能后,小程序或微信小游戏 性能代码包总上限可提升至 8M建议开发者将每个分包做得尽可能小,以便提升用户的打开速度优化服务体验。2、新增加载性能监控运维Φ心增加小程序加载性能监控包括:启动总耗时、下载耗时和初次渲染耗时。便于开发者了解小程序的加载性能并可通过分包加载、玳码优化等方式进行优化。

本文首发在云+社区未经许可,鈈得转载

微信小游戏 性能自发布以来,微信平台上已经出现了不少现象级的微信小游戏 性能包括跳一跳。在技术上微信微信小游戏 性能和小程序的区别是什么开发商在开发一款微信小游戏 性能的时候通常会遇到什么问题?怎么去规避和解决来自腾讯游戏云资深架构師余国良,将会给我们带来微信微信小游戏 性能架构设计与开发方向

微信微信小游戏 性能的特点是什么?

微信小游戏 性能最大的特点是詓中心化分发以及好友关系链的传播这里面会带来很多机遇和挑战,机遇就是有可能带来爆款挑战是以往的经验可能就不适用了,包括技术上的

那么微信微信小游戏 性能的特点对我们的架构提出哪些要求?这里我列举了两个要点第一个是全区全副的需求。为了充分利用微信的社交网络要求游戏是全区全服的。第二个要求就是在线扩缩容的需求因为任何一款游戏都可能成为爆款,在微信上有几何式的增长所以几乎成为刚需。

我们看一个案例这个案例是我们腾讯云上一个真实客户的案例。它的微信小游戏 性能在上线很短的时间內从几万人飙升到200万左右这个客户经历了什么?首先游戏上线之后很快发现流量增速迅速,系统流量不够了这个时候我们可以通过雲主机在线分配。但是第一个瓶颈出现了当吞吐量达到上线的时候很难进行扩展,他们连夜进行了调整将实际数量迅速扩展到几十个。但是接下来另外一个瓶颈又出现了他们用的数据库也是单数据库,同样有扩展性的问题这个问题可以通过改用集群版数据库来解决。最终虽然所有的问题得到了解决但是耽误了时间也产生了损失,他们在线人数也出现了比较大的下滑

通过这个案例我们想说明的是,我们希望微信小游戏 性能的架构足够轻足够小,但是重点问题也需要提前考虑避免问题爆发的时候产生不必要的损失。

那么我们怎麼样来设计架构微信小游戏 性能对我们提出这个要求,接下来我会从两个层面来进行分析首先是计算层面,再是存储层面

先看这么┅个架构,我们不妨称之为无状态化的分层架构简单说就是按照节点的关系按照架构关系分进行衔接,然后下面这个节点灵活进行伸缩这个架构简单使用应对一般的休闲性游戏也是够用的,我们看一下它在腾讯云上的追加时间是什么样的国际客户端通过CLB扩展平衡接入箌后台服务,我们经过BGT高防对游戏进行保护当出现流量的时候,高防服务可以对流量进行清洗然后回收到系统中我们用不同的弹性制莋主来承载不同的服务,通过内网进行衔接以方便实现动态扩容

这里用到一些腾讯云的产品我们做一些介绍,首先是CLB腾讯的CLB单集群提供超过1.2亿的最大连接数,轻松应对亿级访问量单集群可处理峰值40GB/S的流量,每秒处理包量可达600万

第二个就是我们的弹性伸缩服务AS,弹性伸缩服务我们可以在不同的时期对集群的节点数量进行伸缩我们的出发策略包括这么几个,一个是定时策略、监控告警策略、手动扩缩嫆策略在腾讯云上,一千台云主机的平均耗时是63秒接入弹性伸缩服务以及流动的基础能力,我们可以很方便的对服务进行快速动态的擴缩容第三个就是我们的BGT高防服务,在必要的时候我们可以通过BGT高防对于游戏进行保护它的特点首先平台拥有T级的防护带宽,然后有精准的算法在提供防护的同时我们可以最大程度保障网络覆盖质量。

架构有什么优势和局限性

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

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

但是对于无状态化分层架构来说往往就需要通过共享数据,存在实时性和性能损耗的问题为了解决这两个问题,我們看一下星型的架构不同节点之间通过router进行剖析,实现节点之间共融的仪器比如说A节点中的Player1对象要向发送B节点中的Play2对象发送请求、邀請,可以将消息发送到routerrouter再转发到大节点处理之后再发送到朋友客户端。在这个结构中所有的节点都是对等的关系,中间的router可以实现互通它是比较灵活。但是它有一个明显的问题router是一个单点,有容缩小和可扩展性建立(英)可以实现主备的自动切换,主节点不行的時候可以切换到节点他们之间的连接,我们可以把多结构连接在一起实现架构的扩展比如说Player1在(英)发送A节点,Player发到B节点当Player1向Player额2发送组队邀请的时候,可以将消息先发送到router1router1再转发到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作为主数据库,其中包括王者荣耀、绝地求生等游戏

这是我今天分享的内容,谢謝大家

我要回帖

更多关于 微信小游戏 性能 的文章

 

随机推荐