游戏技术中台调研
主要参考腾讯
从引擎中台、devops、周边、公共技术中心等方面
内容参考tgdc
2020.06.27
-
腾讯游戏开发者大会（TGDC）2019
-
引擎中台助力《使命召唤手游》技术升级
-
笔记-主要是引擎中台
- 引擎技术移动化，我们在手游上大肆的使用端游时代的技术
- 引擎与工具也在不断升级：UE4普及，Unity也升级到了2019，以Houdini与Substance为代表的美术工具被大家广泛使用
- 硬件也在进步
- 此外，各种3A大作前沿技术被手游使用
- 技术深厚的公司出现了一大堆的高质量的手游，技术竞争也会越来越激烈
- 传统游戏开发团队架构-在技术团队中会有那么一小波同学会做一些引擎的开发工作，称为“引擎工程师”，他们在负责一些面向于项目需求的特性的开发，性能优化，解决一些技术的难题，去参与攻坚一些项目
- 引擎层、基础引擎基础（性能优化、游戏框架、引擎基础技术）
- 一般游戏产品都是需求驱动。往往团队里面所使用的技术是为了满足当前需求。团队只关注单一产品，对一些前沿方向相关技术储备不足
- 国内做引擎或者做底层的开发者数量其实非常有限，需要去培养，而且要走引擎技术的全覆盖
- 已经沉淀出来的技术需要在各个项目里面不断做传承，已经沉淀出来的技术需要在各个项目里面不断做传承。另外要对外不断进行合作
- 引擎中台
- 支持项目快速创新、规模化创新；提供完整的持续交付工具链
- 根据技术前瞻提前组织资源，利用技术先发和可复用的优势，赋能业务真正做到多（同一时间支持多个项目），快（持续快速交付），好（品质保障），省（技术与人才充分复用）的逐个落地
- 中台架构
- 业务团队
- 流程支撑（目标管理、需求管理、代码管理、开发流程 PM）
- 引擎技术组（引擎技术能力、开发制作管线、工作流工具建设、技术美术能力）
- 技术美术、引擎开发、工具链开发、自动测试开发
- 提供引擎技术能力，开发制作管线，工作流工具建设，技术美术能力等全方位能力去支撑业务，同时也会从业务发展过程中反哺中台
- 和业务非常紧密结合是这个团队最大的特别，我们不会一味做很多不落地的技术。我会根据工作室未来方向定义自己的Roadmap。我们70%的需求来源于业务，然后剩余30%来源于对业界趋势的一些思考
- 同时中台支撑需要有很好的流程支撑
- 引擎中台技术全貌
- 项目前台 穿越火线手游、使命召唤手游、UE4手游
- 开发框架（UE4/Unity开发框架）+ Lua插件（unrealLua）
- AI框架、角色控制、射击手感、反外挂能力
- 任务系统、热更新、打包版本方案、FPS游戏开发套件
- 管线/workflow
- 大世界制作管线、pbr画面呈现标准/制作管线、fps动画技术管线、workflow:程序化制作/资源管线
- 工具链/平台
- DCC工具链、编辑器开发、自动化兼容性测试、技术沉淀wiki
- 引擎中台
- 过程化制作（Houdini）、烘焙器扩展、可见性剔除方案
- 角色&头发&皮肤、地形组件、prt技术
- 3D UI组件、高品质天气/昼夜技术、大世界/小世界渲染管线
- TA能力支撑
- 底层引擎
- UE4、Unity、自研引擎
- 建立画面呈现标准
- 画面品质升级。要做画面升级，首先是画面呈现标准的建立
- 要考虑性能，做性能是永远能服务于大盘用户的
- 既然我们要做PBR，就需要统一制作管线和技术管线。对于制作管线来说，美术资源需要在线性空间计算。对于技术管线来说，我们要为引擎定义并且统一渲染管线，我们渲染管线是根据硬件scaleable的HDR渲染管线
- 有了渲染管线之后，对于画面呈现来说，我们要建立一致的画面标准
- 确定了shading model,materiel model, lighting model，画面标准就基本建立
- 3A级手游制作管线
- 整个制作管线的核心因素有哪一些？我认为是有三个方面，一个是量产、一个是引擎、一个是性能
- 制作管线，需要使用流程与工具保证美术素材的正确和合理性。原则有两个：一，美术素材输入PBR标准；二，生产规格与生产环境
- 如何达到PBR资源的量产化？首先要可以验证，其次要有详尽、可追溯的文档和记载，同时还要有科学性
- 量产我们要有标准的场景验证
- 最后一个要点是正确性
- 《使命召唤手游》引擎技术沉淀
- 我们日常的引擎迭代里面都需要有一个自动化兼容性测试的框架，尽可能保证所交付的引擎是稳定的
- 我们和腾讯Wetest质量平台合作，定义了一套devops自动测试框架，每日拉起TOP200的手机做测试。测试结果和基础机器的backbuffer做对比，可以发现各种渲染异常。也可以验证游戏graphic api的兼容情况。同时可以针对Top200机器做兼容性，性能测试，同时支撑新渲染特性以及渲染管线的评估
- 我们现在的第二个管线，大世界制作管线
- 基于Houdini的工作流
- 我们还对烘焙器做了很深度的定制，烘培器使用了GPU的烘焙
- 原来我们在PVP地图里面单次烘培需要4-6个小时时间，使用这个烘培机。只需要3-5分钟时间搞定了，整个效果也是有所提升，整个计算的正确性和参考也是非常科学
- 程序化生成LightProbe
- 程序化植被制作
- 我们提供了一系列Workflow保证美术制作、引擎、性能工具一体化
- 我们日常的引擎迭代里面都需要有一个自动化兼容性测试的框架，尽可能保证所交付的引擎是稳定的
- Unity引擎特性升级
- 头发：各向异性高光
- 皮肤：SSSS
- 角色：完整的3A PBR制作标准
- 总结：引擎技术中台的能力
- 资源与经验复用
- 品质与性能保障
- 工作流与制作管线
- 引擎技术能力
- 创新赋能
- 梯队培养
-
-
5G赋能游戏行业发展
-
笔记，关注最新动向（5g + 云游戏）
- 5G，高带宽、低延迟、大连接
- 边缘计算
- 关于云游戏
- 考虑当用户对象是用5G来使用游戏的时候，怎么充分利用5G的网络，才能让你的用户感受最好
- 边缘云能够更接近你最终的终端和最终的用户
-
-
研发运营一体化，下一代企业级操作系统
-
笔记-蓝鲸
- 我们团队的职能是设计构建游戏“研发、运维、运营领域”的工具平台，并经营内部的工具文化生态
- 研运中台
- 基于PaaS的研运模式我们对外做过分享，在2016年之后对腾讯IEG投资的公司提供过私有化部署的版本，中小型公司提供易安装维护的2012版，中大型公司提供2015版，这两个版本在2017和2018年分别更名为“蓝鲸社区版”及“蓝鲸企业版”，前者免费提供给社区，后者由严格筛选的蓝鲸服务商公司为甲方提供服务
- IaaS，PaaS，SaaS 的区别
-
-
-
腾讯游戏开发者大会（TGDC）2018
-
艺术背后的技术
-
笔记-运营技术的加持
- 讲到技术，大概会分成两个方面：一是研发技术，在很早以前，大家觉得做好一款产品、做好一款游戏只需要研发技术强就行了。但是这远远不够，如果你不知道你的用户什么时候卡顿，是否下载成功，客户端或是后台程序crash了没有及时发现和修复；如果你不知道用户行为是怎样的，不分析他购买的行为，不给他推荐他想要的东西，他要翻很多页才能找到他想要的道具的话，估计他自己就放弃购买了；如果外挂横行，你的游戏也会命不久矣。所以，还需要运营技术的加持
- 腾讯游戏在十几年的发展中，在三个层面沉淀出技术能力：一是基础的运营能力，比如说我们的蓝鲸，在座的小伙伴可能听到过、用到过，我们的安全包括内部和外部的安全，传统意义上的反外挂、内部的反作弊，合起来才是安全的完整的解决方案；二是游戏开发过程中一些AI的帮助、公共组件，才会让我们的研发速度和效率更快，以及WeTest开放的测试平台；三是数据挖掘和数据应用能力，这些是腾讯经过十几年沉淀出来的能力
- 增值服务
- iData、DataMore、Pandore
- 心悦、小悦、游戏助手
- 研发技术
- 公共组件、游戏语言、AI
- WeTest
- 基础运营
- 蓝鲸智云、GEM
- TP、铁算盘、反作弊
- 基础设施
- 自建私有云、腾讯云、aws
- 增值服务
- 可参考腾讯游戏服务
-
-
实时数字人Siren渲染技术揭秘
-
笔记-UE4
- 上面的图片其实不是她的写真照，是通过UE4实时渲染出来的
- 虚拟数字人
- 我们可以借鉴电影行业的技术用到游戏开发，对我们有很多启发性的应用。关键是这个经验是经过很多皮克斯电影验证的
-
-
UE4制作多人大地型游戏的优化
-
笔记-UE4
从游戏线程、渲染线程、GPU、内存等各方面进行优化，从而提升游戏品质
-
-
手游研发运营2.0 ——潘多拉解决方案的技术实践
-
笔记-如何建设各项能力来支持游戏运营，提升游戏的营收、留存和用户活跃指标，并提出了改变产业分工的美好愿景
- 《QQ飞车》的商城，我们看到这样的商城，不管是道具的展示、交互的效果、支付购买，其实都是通过“潘多拉”完成的
- 《QQ飞车》做的视频直播，这个视频直播也是嵌入到游戏里的原生体验，具备完善的开播、交互、弹幕功能，和虎牙、斗鱼、熊猫的直播源都打通了。通过游戏内嵌入的系统可以观看到外部关于《QQ飞车》所有直播内容，这样一个方案可以在所有的游戏里进行上线、集成，开发商可以大大降低开发成本
- 《QQ飞车》做的好友和战队的匹配系统，可以帮玩家快速找到合适自己玩家，我们会分析玩家的地理信息、地理的聚群，让玩家可以相互匹配在一起。这样的一套社交系统在《王者荣耀》、《天天酷跑》都上线了
- 周边系统可以单独拿出来放在游戏建设中，可以重复应用到不同的游戏里，其实做这样的系统可能并不是游戏核心乐趣所在，但又不可或缺，这些系统影响到玩家的留存、活跃等指标
-
-
-
腾讯游戏开发者大会（TGDC）2017
-
谈腾讯精品游戏的基础技术体系
-
笔记-主要讲述游戏基础技术从端游到手游的发展和应用情况
- 其中我所在的团队——负责游戏公共技术的研发。我们团队成立之初到现在，一直在坚持的核心价值观是希望加速整个工作室群研发游戏的效率，所有公共的模块系统不需要重复开发，让游戏开发团队只需专注于核心玩法的开发上。此外腾讯游戏拥有海量的用户，在设计公共技术时必须考虑高性能和高可用，基本上这三点是我们做设计的核心设计考虑因素
- 我们是2007年开始做公共技术
- 我们在《QQ幻想》的基础上，前前后后花了3年时间，做出TSF4G（Tencent Software Framework for Game）的产品，它是一个比较完成的游戏后台基础开发框架
- 到2010年前后，那时候QQ空间很火，带动基于SNS互动页游的火爆，整个互娱很多团队开始考虑怎么做页游，我们的团队也开始建设页游基础技术体系，其中最重要的产出是研发自己的分布式存储系统tcaplus
- 自从《天天酷跑》发行非常火爆之后，互娱很多团队迅速切入了移动游戏的研发，因此我们研发了手游基础解决方案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上做了开源
-
-
王者荣耀后台分享
-
笔记-后台整体架构、网络同步技术
王者目前后台的整体架构的设计是源自产品的需求，大家玩过王者的就知道，PVP的对抗是不分区服的，你登录微信1区可以和微信2区一起PVP，甚至ios平台可以和Android平台的人一起玩PVP，但是同时又保留了分区的概念，比如战队、排行榜是基于区的概念，区在王者里面就是编号，是打在玩家新建角色上的Logo
我们最开始做架构实现的时候，服务器当时做得比较简单，从原型开始只是保留了大厅和PVP服务器这两块，是分开的。PVP服务器的使用类似CGI调用，可以分配资源使用，用完之后回收，不负责其他的东西，需要的东西从大厅拿，用了之后回给大厅，让大厅回写DB
包括大厅和PVP之间做直联，后来把直联改成中间的转发，在王者里面我们叫Proxy，相当于代理服务器，屏蔽本身后端很多进程分布的细节。因为王者本身的机器、进程很多，还有不同的路由规则，某些排行榜或者战队根据逻辑区的编号来确定有哪台机器或者多台机器进行处理，有些消息采用随机转发或者多发广播，都是由Proxy负责路由
之后又加入了房间服务器，它负责的是王者里面匹配、排位相关的功能，怎么样把实力比较接近的人糅合到一块儿玩，是由房间匹配服务器来做相应的负责的。也会有战队和其他的服务器
最后我们在上面加入了一个Adapter，作用是用本身已经部署的大区资源实现跨服匹配的功能。王者的后端架构，除了战队这样的服务器之外，所有其他的模块都可以在线扩容，或者在发现在线下降的故障时，从整个架构里自动屏蔽掉。因为路由方式会限定比如一区、二区、三区到这台机器处理，如果故障，影响的只是某几个逻辑区玩家请求的处理，降低故障影响范围
王者目前的机器数量，可能每周都会发现有机器坏掉，至少有一台机器宕掉，在架构里面保证模块自动屏蔽，和在线扩容，是非常重要的事情。整体结构比较像MMO的三层结构，MMO在腾讯有比较典型的三层级别的结构。大厅服务器会根据玩家的所在区登录具体区的大厅服务器。单个大厅进程可以承载2万人，单个PVP可以承载1.2万，小区登录微信一区还是二区就是角色Logo打在他身上。王者就是全区全服的结构，如果剥离了战队，不管是大厅还是PVP服务器，其实每个都是按组的概念。我们可以在线扩容，如果组里面某个宕掉，不会有什么太大的影响。王者现在外网有四个大区，比如Android手Q、Android微信、iOS手Q、iOS微信，还有抢先服。我们会用程序开关的方式，在大版本发布之前，优先更新抢先服，这时候它不能和正式服玩家匹配在一起，因为他们的版本不一致。当全服发布之后，它的版本更新一致之后，我们会打开开关，抢先服的玩家可以和正式服的玩家一起进行PVP的匹配。除此之外，我们还有专门的体验服，是给策划验证相关设计的，体验服保留可能删档的操作，但在正式环境这是绝对不允许的。另外，以前的传统手游偏单机，就会做很多协议兼容，客户端版本没有更新可以玩。但是王者里的主要玩法是PVP，同时结合实现方式，不同版本的玩家不能匹配一起，所以我们没有做多版本协议兼容
架构上的微调，像刚才提到的中转模块，我们架构中大厅机器很多，PVP机器很多，架构中不需要每个进程知道详细信息，比如大厅服务器不需要知道后面有多少房间服务器，只需要知道后面有房间服务器，可以访问就OK。怎么划分、平衡负载、怎么屏蔽后端故障节点，都是由Proxy路由功能在负责。因为大厅、pvp机器太多，我们通过Proxy将整个架构划分成彼此之间没有交集的树枝的概念，每组Proxy只负责一部分的大厅和PVP服务器
ProxyAdapter是上线后加入的，最开始上线只有四个大区，手Q、微信、Android、iOS四个环境，最开始Android的玩家不能和iOS开黑。开始Android和iOS分开也有一定原因，我们之前设想Android会先更新，iOS后跟新，以保持版本更新的稳定性。但后来我们希望Android和iOS的玩家可以因为关系链一起开黑。所以当Android、iOS版本更新频率一致时，我们希望不需要部署太多额外的机器资源和开发，直接利用Android和iOS已有的PVP服务器和大区资源，打通Android和iOS的pvp。当Android玩家登录Android大区会连接到Android大厅，iOS登录之后连接iOS大区的大厅，当他们需要开黑的时候，我们通过Adapter把中转模块所有的大区桥接起来，通过一定的算法投递到某个大区，投递的选择和大区资源占比有直接关系
帧同步网络抗抖动能力比较弱，因为不能丢包。该技术的要点在于局内的运算都是基于客户端运算，10个人每个人各自算一份，有相同的起始、相同的输入、完全相同的中间运算逻辑，不存在随机过程，这时候运算的结果，理论上应该是一致的。甚至包括浮点数运算都不应该存在，它有精度的问题。包括很多碰撞，动画，还有基本的数学运算库都是后台自己实现的，要去浮点整形化，避免客户端的本地逻辑，这是最容易犯的错误，这是出现不同步最常见的原因。如果某个经验不是很足的客户端程序，写程序时候用本地的代码做相应的逻辑，可能跑得越来越远，10个人都是平行的世界
-
整体的网络结构，大体看来是分三层，服务器、客户端逻辑层，客户端表现层
- 服务器主要负责的功能有两部分：一是收集所有玩家上行的输入，把它按定时的间隔打包成输入的序列，投放给所有客户端；二是当客户端出现丢包的时候，服务器进行补发；还有把客户端上行冗余的信息替换掉，比如有新的输入到了，就把老的输入Drop或者替换掉。王者我们的逻辑是66毫秒一次，1秒同步15个包，这是不能少的，因为帧同步不能丢包，数据包必须有严格的执行序列
- 客户逻辑层理解为客户端本地的服务，就是所有客户端运行的结果必须强一致，不能有真的随机，不能有本地逻辑，不能有浮点数的运算，拿到相同的输入，产生结果必须一致
- 客户端表现层是根据逻辑层的数据去做Copy或者镜像，然后在表现层进行平滑，帧数不一样，但是不会影响最终的运算结果，只影响动画和动作的表现
帧同步的消息比较小，按照理论1秒15个驱动帧来算，20分钟的录像是10M左右。但是我们外网统计，正常的5V5对局20分钟，录像的大小大概是3M左右。服务器会把玩家的操作做纯内存的存储，当出现丢包的时候，服务器会通过编号快速找到缓存信息进行下发。同时根据丢包的情况，我们会计算给这个人发送冗余量的变化量。最开始发送每个包会冗余前面3帧的信息，如果丢包严重，我们会尝试冗余更多信息再下发。客户端拿到之后会尽量压缩逻辑执行的过程。帧同步有比较麻烦的模式在于，它不像CLIENT-SERVER的模式随进随出，崩溃之后重回必须从一开始运行，中间运算过程不能少掉
帧同步方案，所有客户端进行运算，期望产生一致的结果，但如果因为bug或者某个人使用修改器，跑出来的结果会和其他人不一样，当不一样出现，我们的说法是不同步了。我们会定时把一些关键信息提取出来做hash，不同步的人的hash和其他人会不一样。王者不同步率上线时大概是2%，也就是100局可能有2局出现一个人或者多个人结果和其他人不一样。我们现在把不同步做到万分之三，一万局里面只有三局出现这个情况。是怎么提升的呢？如果你用帧同步一定会遇到不同步的问题，客户端写错了，用了本地逻辑，可能浮点数的运算误差达到那样的临界点，它就会产生运算结果不一致。我们的方法有很多：自动化测试，用机器人不断跑，比如上新英雄之前，有脚本测试不断跑，看会不会产生不同步的结果；有专门的体验服、抢先服大区，发布到正式网络之前先测试，先暴露问题，再解决问题；另外，当不同步的时候，我们会把这局整个录像和客户端间的log上传和保存下来，这样可以根据录像和中间执行的日志序列快速的定位是哪个地方出现问题
我们对延迟和单局质量也有相应的监控，这一局有没有卡或者卡多少次，有没有出现丢包，丢包多少，最大的延迟、最大的抖动是多少，我们都是有相应的记录和统计。运营部的同学给我们提供了很多帮助，我们会有相关的网络测速、问题分析的SDK的合入。按照我们自己的统计，主要的原因有几个：一是小区的带宽比较繁忙，很多小区其实都是公用带宽出口，比如有人在下电影、看直播，占用了很高带宽，你玩游戏就可能会卡。二是wifi路由器延迟比较高，家里的wifi路由器长期没有重启，就会存在终端过多、信道干扰、其他大流量的应用下载情况，这也会影响你玩王者。还有手机信号差、信号抖动，wifi、4G空口丢包等。我们其实在网络优化上做了很多的尝试，例如根据丢包情况加大冗余，然后优化我们各方面执行的效率，去减少CPU的占用。王者后台方面，有两个点是我们一直努力在做的，网络优化和匹配机制，我们尝试用各种各样的方法，甚至后面也会尝试用AI深度学习的方法，来更加精准的定位玩家本身的真实水平，让他能够匹配到更加真实的同等水平的对手和队友
-
-
龙之谷服务器设计
-
笔记-腾讯上线经验
- 腾讯对项目上线有一系列标准，在此简要列举几点：1、架构设计要合理，支持弹性动态扩容能力，高可用容灾能力。2、服务器性能要满足要求。3、符合DB规范。4、符合运维规范
- 设计架构要求：1、弹性动态扩展能力，逻辑层要求支持线上动态扩容，并且要求对用户无影响。2、高可用容灾能力，核心模块和关键路径不允许有单点，不允许无法扩展。3、要求对同时大并发访问有防雪崩机制，比如排队、访问频率控制等，防止过载。4、要求非关键核心模块故障不影响玩家主逻辑服务，可提供有损服务。5、不允许数据变更未及时入库，导致可能发生10分钟以上的回档
- DB规范：1、按需Cache，存储层实现分库分表平行扩展或接入TSpider集群。2、使用域名+Port的配置方式访问存储层。3、存储层访问必须支持故障或者超时后的重连机制
- 运维规范：1、接入腾讯TGW。2、客户端需采用域名+VIP的配置方式访问服务端。3、日志文件支持按小时或大小滚动。4、程序用到的系统参数不能hardcode到代码中，必须以配置项形式写在配置文件中。5、应用程序必须支持通过工具实现动态加载相关的配置文件，而无需中断服务。6、苹果审核服和正式服的访问切换必须通过服务端控制实现
- 单服架构、分区分服
- 单服内模块
- 多开负载均衡和容灾
- 单机宕机拉起后恢复
- 单大区内的模块
- 分4个大区： ios-qq ios-wx android-qq android-wx
- 跨服匹配服务器 主备容灾
- 全区全服模块
- 单服内容灾、大区内容灾
- 单服内模块
- 体系结构
- 分层设计
- 网络层提供通用的二进制传输
- 中间是框架层，提供RPC、Protocol、定时器、网络连接封装，RPC封装，由工具生成RPC代码
- 网络层：1、跨平台的网络模型封装，对外提供统一的抽象接口，内部Windows下封装IOCP，Linux下封装Epoll。2、网络IO在单独的线程中执行，不影响主线程逻辑，通过无锁的环形队列与逻辑线程交换数据。3、Windows下开发调试，Linux下部署运行，提高开发效率
- 框架层：1、主要提供基于时间轮的定时器；2、网络连接的封装，自动重连，心跳保活；3、日志支持；4、RPC，封装通信请求、处理；5、协议的注册、处理分发；6、Utility
- 应用层：1、场景管理，静态场景+动态场景。龙之谷有一个主城，是静态管理，副本是动态创建，根据负载均衡副到各个不同的服务器上。2、视野管理：主城9宫格+战斗场景全同步+特殊场景分线。主城是九宫格视野管理，战斗场景全同步，我们战斗场景人数不多，全场景同步，特殊场景分线，公会大厅，公会中有很多人，这些人都是按照静态分线机制，N个人之间可见。3、AI是基于行为树实现的4、战斗：服务器结算所有的逻辑，做状态同步；5、协议：RPC用工具定义，自动生成代码6、各逻辑系统
- 性能优化
- 运用性能分析工具(Gprof, Perf)找出瓶颈模块，热点函数
- 对热点模块进行优化
- 对热点函数进行优化
- 注意一些依赖库的坑
- 统计服务器的各种压力参数：流量，协议发送/处理频率，定时器数量等，定期输出到文件中
- 架构上支持进程多开，分摊压力
- 性能优化-压测
- 前期删档测试期间记录下高峰期服务器所有协议的处理次数，处理时间，得到重点协议的接收频率，处理时间消耗等数据，有针对性的优化
- 根据测试得出的协议接收频率模型，腾讯压测部门写机器人工具，直接发协议到服务器，模拟真实玩家，对重点流程(登陆，切换场景，战斗，大规模的活动等)进行压力测试，测试响应速度，重点事务tps，找出瓶颈
- 使用机器人进行综合测试，模拟大规模玩家的行为，不停上下线，不停切场景，打副本等，持续跑几天，观察CPU负载，内存增长等指标
- 压测下来，单服最高承载8000人，出于保守考虑，最高允许的同时在线人数设置为7000，到了7000就开始排队
- 经验教训
- 做好容灾，服务器各进程要做到宕机拉起后可重新恢复服务，极端情况是可能出现的
- 服务器硬盘写满，所有进程一起崩溃，要防止重要数据丢档
- 虚拟机母机硬件故障，整个机器挂掉，要防止重要数据丢档
- 内网波动，服务器之间的连接中断一段时间后又恢复，要有自动重连机制
- 网络波动导致服务器进程和 TSpider之间的连接断开，要能够处理这种情况，定时尝试重连TSpider，未写入成功的数据要缓存起来，待连接OK后继续写入，若重试达到一定次数，则禁止玩家登陆，等候运维介入
- 控制好内存分配，多用内存池，对象池，能事先分配好的事先分配好，各系统的内存申请、释放尽量统一控制，禁止随意分配。内存中的Cache要控制上限，避免无限膨胀
- 流量、协议发送/接收频率，场景数量，各系统性能统计数据等定时记录，以备查问题时用
- 关键流程和大规模活动玩法 要有频率控制，防止压力不可控。我们做了很多全服玩法，中午12点30开世界Boss，打的人很多，晚上也有公会Boss，还有大规模的跨服活动玩法等，这类玩法的关键流程要有频率控制，防止压力不可控
- 重要数据实时落地，防止意外情况重要数据丢失，对于非重要的数据丢失给玩家补偿也可以接受
- 重要流程（支付等）的日志要非常详尽，有问题方便排查
- 数据库表格要合理设计，重要数据单独成列，避免更新时被其他数据影响。龙之谷的设计是每个系统的数据自成一列，做成Blob数据，如果某些重要的数据和其他非重要的数据放在一列存储，非重要数据的更新如果有BUG，可能会影响重要数据，得不偿失
- 测试用具要完善，单元测试，压力测试，模拟客户端，压测机器人等
- 负载均衡要多考虑，避免各节点之间压力不均，要均摊到整个集群。我们设计跨服路由集群的时候也考虑过负载均衡，但后来发现某些情况下，整个集群内部的各个节点的压力不均衡，有的节点压力很大，有的很空闲，我们后来优化了一下，最好在最初设计时多考虑权衡，做到把压力均衡到整个集群
- 引入脚本，做到部分逻辑可热更，或通过脚本修复某些错误。如果代码全部是二进制，出现某些问题需要重启服务器，有脚本会更加灵活一些
- 逻辑系统做功能开关，出问题后可动态关闭特定功能，防止问题蔓延。龙之谷所有系统都做了动态开关，根据系统ID可以关闭或打开一个系统，如果某个系统出现问题，就动态的关掉
- 重要数据异常，严重错误要监控记录。比如玩家数据膨胀，最开始创建角色的时候玩家数据很小，玩家玩的过程中不断增大，每个系统数据的大小都会被监控，发现异常就会警告，我们再去排查
- 所有大规模的全服，跨服玩法上线前都要做压力测试，尽可能的模拟真实情况，避免上线才暴露问题
- 数据做集中式存储，对后期合服会很友好。尽量把全区全服的数据存储在一起，这样后期合服就不需要合数据
- 对日志做关键字监控，便于知晓问题的发生。通过脚本进行监控，发现问题实时上报
-
-