中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，于推动APM在国内的成长与发展。
原博瑞游田博辉于服务端应用监控实践发表了题为《MMO游戏性能监控及优化》的演讲，现场从游戏服务器架构演变，预警体系，实时分析系统，手段等方面一些踏过的坑。
以下为演讲实录：
大家好！我个人做了十多年的游戏，现在准备去创业了，可能会暂时离开游戏圈或者说技术圈，在这之前借着这个大会，我把我十多年肚子里的东西都给大家掏出来，给大家一下。
咱们这里做游戏的多吗？我估计是不多，所以我就想今天主要是把游戏性能的思想给大家介绍一下。2010年之前游戏行业的性能比要好得多，但是2010年之后和互联网发展特别快，包括分布式、一些容器的发展，那时候游戏就进入瓶颈期了，原因很简单，用户量下来了。当时我做游戏的时候我们一个星期用户注册量在500万都是很正常的值，现在一个生命周期都不到一百万了。
这是一个游戏的架构，可能大家会说我不是做游戏的，这个架构跟我没有关系，其实它和互联网是一样的。非常简单，这个是用户，然后用户先连到战区列表服务器，就相当于一个CDN，相当于一个做分布式的服务器，后面是DB的集群。后面这里是一个服务器，网关服务器是做网络转发、网络安全的，包括一些用户状态的验证，相当于咱们应用的登录服务器。它的整体架构和互联网是没有太大差别的，比如咱们游戏服务器后面是一个组，这个组就相当于网站的业务服务器，我认为总体思想和互联网没有多大区别。这里有一句话是我十多年的感悟，就是架构和业务是相互促进的，比如说我这里能够支持20万人实时在线，也就是说会有100万的活跃用户，500万的注册用户，这是一个区，如果多了怎么办？那就用分布式，然后后面跟了很多log服务，log服务是我今天讲的主要重点。
这是运营系统架构，它的核心比较简单就是log，把所有的log聚集起来通过一个数据仓库的概念分策略来走不同的部门，包括运维、研发，不同的权限去看到不同的内容，这是游戏里面用的比较多的，包括它在不同层次的实时数据，有一些数据我们要实时看，比如现在多少人在线，后面就是采集数据，比如说玩家今天进行某些操作多少次，比如我今天去找别人交流多少次，别人同意了多少次，不同意多少次。这个就是数据的分析，现在的玩家都有语音聊天，说今天语音聊天多少次，打字多少次，为什么语音多，打字多？这个都能分析出来，然后是游戏的同步，后面分到不同的部门去，比如说运维、运营，有不同的权限可以看。
这个是前天晚上临时加上的比较糙，但是这确实是一个监控系统，它是怎么做的？它在每一个服务器有一个自我健康信息的汇报系统，就是把我服务器的健康情况汇报给最后的中心控制服务器，这里面有一些策略，有一些阀值的设定，比如说阀值大了就要报警，可能报给运维系统或者运营系统，为什么是两个？运维系统是管硬件，运营系统是管业务型的，它是有一些权限分配的。
关于硬件的监控项，我就说和互联网没什么区别吧，就是监控CPU，监控内存、硬盘、IO、外网内网的网卡使用率，这和互联网一样的。
这是我们的一个监控报表，这个表主要就是分析波峰这个地方的问题，包括CPU、内存，这是我前两天让运维系统截的图，这个图是在服务器维护的时候截的基本上没有负荷的图，这个地方很简单，估计就是服务器刚启动的时候。
这是软件监控项，这个就和游戏业务关联比较紧密了，我说的一句话是这样的，监控的东西绝对是业务上的关键点，你的业务哪一点最关键肯定要监控它，比如说我这边要监控帧速率，还有网络连接数目，因为当时做游戏还是有很多竞争对手，或者有一些大学生朋友会用一些所谓的手段来悄悄的试一下你的服务器，他会疯狂的连接你，然后疯狂的给你发包，这个时候会有一些安全的设定，包括线程的状态、数据库状态，这个确实是和我们的业务紧密相关的。还有在线玩家数量都是和业务相关的，包括NPC的数量等等，这主要是一种思想。
不同的监控有不同的手段，我有一些朋友也是专门做监控来创业，他用一些手段做一些数据最后进行汇总，汇总就是记录日志或者各类报警，这里面可以用开源工具、内嵌API或者心跳等各种方式来实现，但是每个公司有自己擅长的方式或者他用得习惯的方式，这个东西是不能统一的，或者你用哪个熟悉就用哪个，目的达到就可以了，我是这么认为的。
我慢慢接触到业务的东西会多一点，监测和分析是基于业务的，你要做的东西是不是靠谱？上线之后它的效率怎么样？是不是有log记录？是不是有分析？肯定都是基于业务的。比如刚才讲的帧速率，现在咱们讲一下房间数目，或者说一个好玩一点的，咱们讲个NPC的数量，就是怪的数量，每一个怪有一个自己大脑的一个类，然后来跑里面的一些功能，当这个怪的数量足够多的时候会把服务器干掉。
当时我们有一个新来的小同事，因为我们的房间是定期释放的，他没有释放这个房间同时也没有释放怪，然后晚上两点多的时候就接到报警了，房间数目超过一千个，怪超过三万。当时帧速率开始没有怎么掉，没有掉的原因是我们做了一个优化，我们的优化是激活对象的数量，虽然怪没有释放但是这个状态是不激活的，因为没有人没有玩家，不激活基本上就不跑逻辑，所以虽然内存飙上来了但是帧速率没有掉，这个可能是当时的一个优化方式造成的一个血淋淋的教训。
再比如说在线玩家数量，现在有好多游戏上线之后可以看到有好多人，那个东西是怎么弄的呢？这个是行业内幕，好多时候是积分墙还有机器人压上去的，但是有一种情况叫做假用户，就是各种bug造成的，你下线之后那个玩家还存在于服务器上面，可能就是咱们做网站的时候链接没有断掉之类的。
还有存档状态，存档是最要命的东西，有一次我们在做活动的时候，有一个玩家充值充了12万左右去冲排行榜拿武器，充完值后非常不幸掉档了，玩家就来到我们公司找我们。所以，后来我们把存档单独独立出来，做了一个存档服务器。当然现在游戏经过了大概小20年的发展，这些东西都已经成形了，这个东西在2010年左右我们已经做过了，现在都2016年了，我就感觉游戏行业在技术方面的突破已经特别少了，最多就是把DB换掉，我感觉好像也没有多大意思，原因比较简单，它的用户量已经没有那么多了。
这是一个我们内部使用的简单的监控。这是一个游戏刚启动，立项维护的时候，没有太多的内部数据，它里面就是记录了一些核心的东西，比如说帧速率、在线、登录状态，就是记录这些东西和关键的核心业务。
这里会有详细的记录，比如说刚才的服务器出现问题之后，我们双击进来看到它更详细的信息，比如这个包有多少人，帧速率是多少，详细的数据分析，然后下面它还能再点进来，比如常见IP，有多少房间，房间里面有多少人，你所关注的业务的特别核心的地方都把它监控出来，当你用得到的时候就会用到。
下面我们讲优化，基本上监控完了之后肯定是要优化的，优化可能牵一发而动全身，尽快利用各种手段解决问题，保证项目运行，尤其是上线的项目。大家听完了演讲之后可能都热血澎湃，回去之后我要优化我们的系统，然后回去优化了两条代码发现系统和你想象的不一样了，确实是这样的。
举个例子，当时杭州我们有一个工作室，杭州的工作室做了一款项目，他们DB设计的有问题，之后他们核服的时候核一个服可能需要大概30多个小时，也就是说我要停服维护30个小时，这是不能容忍的。他们就想怎么优化，然后发现底层的过程写的有问题，表设计的也有问题，包括数据库存储的压缩方式全部都有问题。那这一套该怎么弄？重写的话估计两个礼拜都搞不定，所以这个时候怎么办？当时是2011年吧，我们就把服务器换成了，让玩家先没有任何问题的跑业务，然后拿过时间来再把它优化，这可能是一种解决问题的方式。有些同学会说，这不是偏产品吗？技术还是为产品服务的，技术是推动产品服务的。
下面我们会讲一些优化手段，这个手段可能应该是通用的。
逻辑帧其实是游戏里很重要的一个数据，玩家的交互我们必须要控制在150ms以内，这个时候怎么控制或者怎么分析出来？这些常用的地方，比如说因为我们有大量的对象就要分批计算、设置激活，刚才设置激活给各位讲过一次，就是说他看不到玩家的对象是不跑逻辑的。还有一个分批计算是什么意思？就是说我不可能一个逻辑帧把所有的对象跑完，所以就会分段来计算，这可能也能用到咱们某些地方，我确实对于互联网不是特别的熟悉。
在游戏里面它的同步其实是个非常要命的地方。大家都想玩，就是PK，晚上的时候我们有一个时间段是10点11点，那个时候玩家已经开始往下走了，理论上我们感觉就可以回家休息了，突然有一天运维打电话说网卡报警了，就是有A帮派和B帮派，两个帮派的老大冲突了，100V100在我们一个叫做桃花谷的地方，在我们没有优化之前每一个玩家动一下我要把消息发给周围的一百个人，那一百个人同时在动我就要发一万，一个逻辑帧就要发一万，我每秒有三十个逻辑帧，就是一秒有三十万个数据包往外发。后来这个地方我们怎么优化呢？就是在一个逻辑帧里面我就把一百个消息包合成一个发给我，那我的数据量就下来了，这个地方我不知道说的合适不合适，比如某个网站上请求一个网页，是不是可以把所有的地方压缩成一个东西发下来。
接下来是锁操作，锁操作我这边用的力度确实比较小一些，因为锁的力度大了以后很多资源要等待，这个都是常识。死锁现在已经很少发生了，因为锁规划合理以后其实没有大家想象的那么恐怖。我们有一个消息链条，我们在韩国的数据大概是一秒12万个数据往外发，分成逻辑帧，一个逻辑帧里面可能有几千个，几千个不可能锁住之后把它发出去，然后一个交换队列发出，就是尽量减少操作中的一些时间。
还有一个就是数据结构，这个就比较大了，就是说要把里面的成员变量压缩的尽量小，因为游戏玩家上线的时候要求效率非常高，3-5秒之内就要进入场景里面去，所以说它的存档要尽量小。原来在没有压缩的时候一个存档大概在3兆左右，后来优化完了之后剩下500K，也能算出来1秒能有多少存档。说到这儿咱们可以多说一点，好多时候在设计的时候就能算出来这个极限值，比如有500K，每秒能存二三十个存档就够了，因为好多是百兆的，所以这个时候在数据结构上的优化会特别多。
网络包的优化，这个可能大家用的也不多，比如刚才说了逻辑帧合并减少投递次数。大量的网络IO重点优化包，这个是什么意思呢？我们有一个log系统，log系统会记录每一个消息IP的包发了多少次，高峰多少次，平时多少次，每天把log看了之后，就知道哪个包异常了。所以在压力产生的时候，我写了一个控制范围，控制范围是什么概念
