谈腾讯精品游戏的基础技术体系

9月23日，首届“梦想·匠心”腾讯游戏开发者大会于深圳举行，在技术分论坛上，腾讯互动娱乐研发部技术总监艾风于会上详谈了腾讯精品游戏的基础技术体系。艾风于07年加入BG公共技术的开发，先后参与负责腾讯游戏基础框架TSF4G、Tcaplus数据存储平台、Apollo手有框架等多个游戏解决方案的研发工作。本次演讲主要讲述游戏基础技术从端游到手游的发展和应用情况，重点讲述了基础框架、游戏存储、下载分发等基础技术的演进优化情况。

以下内容为演讲实录

艾风：大家下午好！我今天跟大家分享一下互娱基础公共技术建设的整体情况。由于一些技术我们在持续做一些探索和优化，今天将会选取其中几个典型的技术，详细讲这里其中的设计思路，希望给大家将来的设计做一些参考。

优先简单介绍腾讯游戏研发的组织架构：自研工作室群的游戏开发团队，聚焦在整个游戏玩法的实现上。在此之外有比较庞大的平台支撑团队，比如运营支撑、业务安全，市场等等，其中我所在的团队——负责游戏公共技术的研发。我们团队成立之初到现在，一直在坚持的核心价值观是希望加速整个工作室群研发游戏的效率，所有公共的模块系统不需要重复开发，让游戏开发团队只需专注于核心玩法的开发上。此外腾讯游戏拥有海量的用户，在设计公共技术时必须考虑高性能和高可用，基本上这三点是我们做设计的核心设计考虑因素。

做公共技术的发展历程

我们是2007年开始做公共技术。当时的背景是，从2003年开始做《QQ幻想》这款大型MMORG游戏，到2006年成功发布，已经把MMORPG游戏的大多基础挑战基本摸了一遍。有了《QQ幻想》的成功，2007年开始考虑成立更多团队，研发多款大型游戏，但这类游戏研发周期长（通常要两三年），团队设计人员庞大（几十到上百人），为降低团队研发风险和提升研发效率，自然就想到复用《QQ幻想》的技术体系，于是就成立了研发部架构组和基础研发组，启动对游戏公共技术的研发。我们在《QQ幻想》的基础上，前前后后花了3年时间，做出TSF4G（Tencent Software Framework for Game）的产品，它是一个比较完成的游戏后台基础开发框架。

到2010年前后，那时候QQ空间很火，带动基于SNS互动页游的火爆，整个互娱很多团队开始考虑怎么做页游，我们的团队也开始建设页游基础技术体系，其中最重要的产出是研发自己的分布式存储系统tcaplus。2012年的时候移动终端快速发展，互娱启动了移动游戏的研发，自从《天天酷跑》发行非常火爆之后，互娱很多团队迅速切入了移动游戏的研发，因此我们研发了手游基础解决方案Apollo。近两年很多手游项目开始考虑海外发行，同时互娱也希望和投资的海外游戏公司及合作伙伴有更精密的合作，我们团队启动公共技术云化和全球化支持体系的建设。

我们的公共技术服务体系到现在积累了9年，基本上从前台和后台尽可能多的把可复用的功能提炼出来做成组件和服务。我们得益于各个工作室群的信任，中间件大概接入上百款游戏，依赖于游戏的成功，现在有上亿的用户。

典型基础技术演进之一：分布式开发框架

下面讲分布式基础框架的优化演进，我们在TSF4G里研发基础框架，当时来自端游的体验，端游的整体架构基本上是分区分服，整个基础架构是相对固定的，中间各种进程之间的协作也是偏固定的，所以形成了相对静态的分布式系统。到页游和手游时代，有更多的新创意进来，整体架构不是简单分区分服的游戏。比如全区全服，全服分服等等各种丰富的玩法，整个后台架构更动态：SNS互动玩法的引入，某些模块性能压力也有显著的变化，很多逻辑系统是一个进程搞不定，需要对等的一组进程。另外用户量的动态变化也需要很多进程去动态的去扩容；同时服务进程所在机器会出现故障，从服务访问的角度看我们需要屏蔽这些机器故障，提升服务可用性。此外物理部署也带来一些变化，现在全区分服的游戏，刚开服的时候人多，随着运营节奏，慢慢单个服人变少，需要考虑合服的逻辑，以及怎么把物理资源利用起来，有些物理机器上运行几个服。总体而言不管是逻辑上还是部署上都更偏动态，我们也希望将这些变化集中的基础框架层面统一解决，从抽象层面看，每个对等逻辑的进程组可以看成一个服务，整个后台系统是由一组不同逻辑功能的服务组成，类似业界的微服务编程模式。如果把动态的伸缩放到基础框架设施里面，更像云化的服务。所以我们做框架提炼的时候，整个后台的基础架构应该是分布式云服务体系。

我们思考新pebble框架的时候，首先要解决的是整个编程理念往服务的方式做思考，任何系统，比如帮派、家族都是服务，你不需要太关心到底由几个实例组成。像服务的注册、注销和可用性探测，服务调度与负载均衡都希望在这个基础框架层完成。

因为服务能够提供动态伸缩的能力，故障屏蔽的能力，服务通信也需要提供动态的通信能力。

同时后台逻辑系统通常比较复杂，考虑到性能，很多逻辑都是异步处理的，通常我们会设计一些异步编程框架来简化这种复杂度。现在我们发现游戏后台开发节奏更快，希望进一步降低这些复杂性，比如没有丰富后台经验的同事不需要理解这个复杂异步编程，用人类更习惯的顺序性编程思路，因此新的pebble框架引入了协程的支持。服务管理与调度、动态分布式通信系统、协程是新框架体系三个核心思考和实现的模块。

典型基础技术演进之二：分布式存储系统

关于存储系统在互娱一直有两条路，使用传统数据库系统和自研存储解决方案，我们团队一直探索自研存储解决方案。

最开始在TSF4G端游时我们做了Tormsvr的存储组件ORM即参考业界对象关系映射理念。这个组件设计主要考虑到游戏数据有一个特点，游戏数据是变化的，随着不断的运营，存储的数据结构不断变化，系统存在不同时期的异构数据，数据存取时需要考虑这种异构数据的兼容，而这个处理是重复并且消耗开发时间的，在我们看来是占用工程师宝贵的研发时间。前面也提到我们公共技术研发的核心价值观是让游戏研发更简单一点，因此我们希望把这块数据处理做成组件，从数据存储建表、改表等数据库表维护到数据读写的SQL代码处理，都在tormsvr组件层接管。程序员通过简单的API即可完成数据存取。

数据与SQL编程的映射用到另外一个数据表示TDR组件，类似google的PB，它的基本思想是把数据是什么描述出来，除了描述数据之外还要把它的操作语义也描述出来。有数据的描述和操作语义之后，我就可以写出一些自动化数据处理的算法，比如我们把内存的数据打印成各种格式，包括配置文件的读取，策划各种设定表格的读取等等都可以实现通用化处理。

到页游和手游的时候，刚才的tormsvr方案碰到了一些挑战。由于游戏互动性更强时对后台数据存取压力也会更大，比如我们会碰到有的游戏业务每秒对数据后台的读取超过100万次。到目前为止我们新的存储平台，每天的数据读写次数超过了4000亿次。

其次因为移动游戏的用户导入速度比以前更快，配合一些运营活动，可能一天就会有上千万的用户活跃，后台系统容量规模更难预测，要求更快的伸缩能力来应变用户的快速增长。

第三个挑战是早期手游研发开发节奏非常快，大家都在抢时间，早一两个月发布就比别人先成功。考虑到上面提到数据存储的高性能要求以前程序员考虑做数据存取的时候，都会考虑数据缓存设计，考虑缓冲与数据持久化层的数据同步，这些代码设计也是挺枯燥和重复的，我们希望让游戏开发者尽可能少地关心这些东西，这些都放到存储系统中去解决。基于这一系列的考虑，我们自己开始了新的存储系统设计。

其中几个设计思路是这样的，我们希望优先提供无损动态伸缩的能力，即存储前端感知存储系统扩缩容和节点故障，因此我们在存储API层实现了节点动态探测和故障屏蔽。其次API层我们用负载一致性的Hash对接入层进行负载均衡，以尽量保证会话数据读写的一致性，即从客户端角度看，同一个会话、数据读写顺序性是有保障的。

我们设计了一个接入层，主要考虑是希望屏蔽后面存储节点的变化，由于数据的搬迁是有状态的搬迁，通过接入层协调把这些数据的变化对外来看是透明的。

存储层的关键设计点，主要考虑是怎么样使性能更高。我们把数据热点管理考虑进来，相当于把原来在游戏逻辑层做的热点cache管理移到这一层。同时我们采用了数据核心管理数据和业务数据分离，热点多级淘汰队列等多种设计来提升性能。

典型基础技术演进之三：下载式分发技术

下载分发粗看是很简单的，从CDN里面拉回更新文件就完事了。但当把整个BG的游戏更新综合起来时会发现有两个核心诉求需要通过技术手段去不断平衡：一个核心诉求是快速下载，玩家希望尽可能快的拿到新版本，最理想的情况是玩家不需要感觉有更新的过程；另外一个核心诉求是下载带宽成本的控制，整个BG游戏的更新需要上T的带宽。游戏更新的特点是下载带宽和登录是相关的，一般在线高峰，也是下载的高峰，发布版本初期带宽通常又是平时的好几倍，而带宽是按照峰值付费的，从带宽使用成本角度看按峰值付费不合算，为控制成本希望尽量把这个峰值降下来。这方面我们做了很多优化尝试，比如不断优化提高P2P下载的带宽占比，包括研发预下载技术，还包括动态调节CDN下载带宽等等。通过这些技术手段以优化玩家的下载事件和CDN带宽成本。

为优化玩家下载体验，特别是优化下载时间，我们也做了一些其他技术探索，首先探索的是微端IIPS技术，其核心设计是，对应每个版本更新，构建一个精简版本，玩家下载这个精简版本就可以开启游戏体验。我们把程序版本分成两块，比如基于刚进游戏会有10-15分钟会玩到的场景和体验，尽可能把这块提炼出来做成微端的包，其他场景和体验，在游戏过程中用到的时候在动态下载。当时典型案例是给轩辕传奇做了300M的安装包，通过下载这个精简更新包绝大部分用户的游戏体验和下载上G的完整游戏安装包体验是没有差异的。

手游的微端技术：代码通常没有办法切分，所以微端技术更多在资源上做切分，除了游戏开始体验阶段必须要下载一部分资源，其他都是动态下载，这就是手游微端的思路。

至于手游代码切分技术，我们研发的XLua组件提供了一种选择。XLua组件本质上是一种可以在Unity中动态执行的lua游戏脚本的技术，如果逻辑用lua实现，可以将这些逻辑按照资源文件的方式进行更新，从而达到逻辑程序切分更新的效果。

相对业界其他unity lua插件技术，我们的设计实现了几个相对更优的特性。首先是更完成的反射支持，能够比较好的支持lua补丁技术，可以不在编译阶段生成代码，节省构建时间。lua补丁优势在于移动程序构建的时候可以通过xlua工具打一些标记。当程序发布后，如果万一有问题，我们只需将有问题的地方用XLua重写发布即可。另外XLua在C#和lua层之间传递数据的时候做了特别的处理，可以尽量减少对对GC的调用。

上面提到的都是通过优化客户端程序大小来优化下载体验的思路，业界还在探索的另一中思路是将整个客户端云化，这就是所谓的云游戏技术。

云游戏，它核心的想法是客户端的计算都在服务器，这样就可以实现即点即玩。此外还有很多其他优势，比如提升防外挂等安全保障能力，支持多终端等等。有很多公司和团队在这一领域做了探索，包括我们的团队。

传统云游戏方案采用视频流方案，会在服务器端把每帧游戏图像计算出来，传递到客户端，客户端就直接做展示，这很像看电影的方式。但这种方案最大的问题是成本非常高，服务器方面需要安装GPU芯片卡，目前GPU芯片比CPU芯片贵很多。对视频云游戏的成本，用一个不太准确的对比是：拿互娱能够支撑传统1万人在线的服务器的相同成本，来购买支持视频云游戏的服务器，可能只能支持到十来个玩家。

我们团队这两年在云游戏技术上做的探索，主要集中在探索服务器成本更低并发更好的方案上。我们的想法是服务器不生成画面，但是把生成画面需要的指令和数据提炼出来，把数据发到客户端，这样可以把客户端的计算能力利用起来。我们在端游和手游上，已经把整个技术方案跑通了。最后的结论是，因为所有的计算都是用CPU完成的，基本上可以比传统的视频方案在并发能力上提高5-10倍。但整体对于传统模式服务器上万的并发量来说，整个云游戏技术的未来还要依赖将来硬件和带宽的发展，还有很长的路要走。

腾讯游戏服务

在这两年有一个比较大的变化。因为很多游戏开始往海外走，所以我们要支持整个基础技术架构在全球能够部署运营起来；同时，近些年腾讯开放的策略，我们也希望积累这些基础技术输出给公司投资的游戏公司和合作伙伴，为游戏生态改善出一份力。我们基本思路是公共技术拥抱云计算，将技术向云上迁移，因此我们逐步建立游戏技术服务平台Gcloud（gcloud.qq.com）,目前这个云服务平台发布了Gvoice语音、存储Tcaplus、下载和区服导航服务。同时我们也把pebble框架、Xlua在Github上做了开源。