别把预算浪费在云上！

3.5、自动化服务器端更新系统

我们采用的服务器端更新模式也是一种比较传统的类似于CDN的方式，是由目标服务器通过缓存节点到中央节点下载，由缓存节点缓存控制，这样可以减少网间传输的数据量以及提高效率。我们在设计这套系统的时候，也想过用P2P去做。大家想P2P是很炫，又节省带宽，但是用于生产环境中大文件分发的时候会有几个问题。一是安全控制的问题，很难让这些服务器之间又能传数据又能进行安全端口的保护。二是在P2P里做流量控制或者流量限定也是一个挑战。所以最终我们采用了一个看起来比较简单的架构。

3.6、自动化数据分析系统

说到客户端更新，其实更新的效果如何，玩家到底有没有安装成功或者进入游戏，很多时候我们也很茫然，只能看日志。但是日志里面的很多信息是不完善和不完整的。下载客户端的时候，如果看HTTP的日志的话，里面是206的代码，很难计算出玩家到底完整下载了多少客户端，甚至他有没有下载下来，校验结果是否正确，也很难知道。所以我们最终设计了一个自动化数据分析系统，目标就是分析从用户开始下载到他登录游戏，数据到底是怎样转化的。最理想的一种情况是用户下载客户端以后，就进入了游戏，但这是一个理想情况。很多时候，比如因为网络不好，导致用户最终没有下载成功，或者是因为账号的一些问题，用户最终没有登录到游戏里面去。所以，展现出来的数据就是一个漏斗状。我们的目标就是让最终登录的用户数接近于起初下载客户端的用户数。

我们来看一下系统的架构。首先由玩家这边的下载器或者是安装客户端，游戏客户端里面集成一些SDK，对于任何一个关键点，比如“下载”按钮或者“终止”按钮的数据都上报，当然这里面不会涉及敏感信息。上报以后会有Tomcat集群，集群处理以后会将数据写入MongoDB。

看一下这个游戏在引导过程中有什么问题，左边的这一列它分为三个文件，有一个是3MB，有两个是2G多的文件，其实大家可以想像一下。很多时候玩家看到小的文件就把小的文件直接下载安装了，但是实际上并不完整。这一点也告诉我们，其实很多时候在运营或者是业务方面，在引导方面也是要比较合理才能去规避掉一些问题。

3.7、自动化数据备份系统

我们第一个版本的备份系统，它的设计和实现是比较简单的：不同的机房会有一台FTP服务器，本机房的数据写入FTP服务器，然后写入磁带，但是这样就导致磁带是分散的，没有集中存放的地方;另外，基于FTP的上传会有带宽甚至有延迟的要求。

后来我们设计了一个集中的备份系统。它主要解决了以下两个问题。

第一是简化配置。我们所有机房的全部配置，用一个负载均衡器的IP就可以了，当客户端需要上传文件时，通过负载均衡器获取实际上传的地址，然后上传文件，由左边第二个框里面的服务器进行接收，并且根据MD5值进行校验，如果校验没有问题，就转到Hadoop的HDFS集群里面去。目前这个集群有数十PB的规模，每天上传量有几个TB。

第二是提高传输效率和成功率。大家会想一个问题，在中国，网络环境十分复杂，运营商之间存在隔阂甚至是壁垒，导致网络不稳定，丢包和延迟的问题是怎样解决的呢?如果基于TCP传输大文件，理论上存在单个连接上带宽延时积的限制。这里我们创新的是，客户端的上传采用UDP协议，UDP本身没有任何控制，说白了就是客户端可以任意、使劲地发文件。最终会由服务器端检查你收到了哪些文件片段，然后通知客户端补传一些没上传的片段就可以了。基于这种方式能规避很多因为网络抖动或网络延迟比较大而导致的问题。当然，在客户端做流量控制也是可以的。在遇到问题的时候多想想，或许能找到不走寻常路的解决方案。

3.8、自动化监控报警系统

再看一下游戏的自动化监控报警系统。游戏的架构中有游戏客户端、服务器端、网络链路，所以必须要有比较完整的体系进行全方位、立体式的监控，才能保证在业务发生问题之前进行预警，或者在发生问题时报警。

对于机房链路，有IDC(Internet Data Center)的网络质量监控;在服务器、网络设备和硬件方面，我们会做服务器的健康检查、性能监控，以及网络设备和流量监控;在系统程序方面，我们会收集和分析系统日志;在游戏服务器端应用方面，有服务器端的程序监控;在客户端方面，我们会收集植入的SDK做下载更新后的效果，以及收集崩溃的数据。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!