如何运维千台以上游戏云服务器-游族网络

上海游族网络的运维总监李志勇

游戏产品架构进化史

第一代架构：

　　当时主流的产品都是以DB+计算+前端这样的3个角色开发设计并部署，服务器以物理机为主，一个游戏区组需要2~4台服务器，不同的机器承担不同的角色。这种架构方案效率低，基本上不可能实现一天开100个区组（100个区组大概需要400台服务器）；

第二代架构：

　　随着业务量的增长和虚拟化技术广泛使用，游族整体游戏架构更新为第二代架构，全面采用虚拟化技术，把一台高配的物理机器虚拟化成多台符合游戏需求的虚拟机来使用，并实现了ALL IN ONE的系统架构。该架构方案运维效率高，适合规模开展游戏运营，但不具备业务高可用特性，一天开100个区组成为常态；

第三代架构：

　　为了迎合大区大服、全球同服，游族融合了前两代架构的特点，推出了第三代架构，按角色分拆并形成服务集群模式。集群架构结合了物理机与虚拟化的优势，实现 弹性扩容，游戏逻辑以服务进程或集群配置项的形式提供服务。该架构方案运维效率更高，可实现秒级开服同时具备业务高可用特性。

　　基于第二代架构，游族基于OpenStack自己的私有云，最初目标是为了提高服务器利用率、降低成本和实现分钟级开服。运维团队以OpenStack G版为蓝本进行调优并修改；整个网络采用的是VLAN模式，保证最大限度与现有网络架构保持兼容；存储方面使用本地磁盘作为存储。

　　通过底层优化后，游族私有云基本上可以满足业务的需求，目前90%游戏业务运行在上面，虚机规模持续保持在10000台以上，游族私有云平台没有提供WEB管理界面，日常所有的操作都是通过命令行和脚本的形式进行操作，但对于虚拟机的增删查改，重新封装了一层简洁的API接口实现与游族运维平台的对接。经过评估测验，在高峰时期，整个私有云资源利用率可达到83%。

游戏版本更新异常回滚方式：

第一种：游戏服务器上保留历史版本，异常时回退到历史版本

第二种：覆盖回滚，将老版本再次发布进行回滚

数据备份与恢复

　　相对于游戏版本更新备份而言，数据库备份更为重要。ALL IN ONE模式或者非集群模式的游戏业务场景下，会存在多 达好几千个MySQL实例，若是要按常规的MySQL备份方案来实施，管理难度和成本都要翻好倍。因此游族网络采用Xtrabackup在主库上直接备份 数据文件方式，备份文件暂存本地；本地备份完成后在备份系统选举一台远程服务器进行异地备份；备份策略每小时一次备份，半小时本地备份半小时远程备份。该 备份方法在单主库业务场景下可能是最靠谱的数据备份方案，但备份过程对主库会有影响、（限制IO操作），最坏情况下可能出现1小时的数据丢失（业务接受少 量的数据丢失）。

　　在数据恢复方面，通过一键恢复工具，只需要提供恢复的IP、时间段和业务信息（如库名）即可实现数据恢复；24小时内的数据通过本地的数据恢复（结合二进制日志），超过24小时的数据通过异地数据恢复。

云上迁移历程

　　现在游族已经将几款老游戏迁移到阿里云上。在将ALL IN ONE架构平滑迁移到云上的过程中，首先要求就是迁移过程不能长时间停服，只能接受正常的版本更新的停服时间。整个迁移过程分为以下几步：

第一步提前准备资源，在阿里云提前申请好资源，初始化环境并把VPC与自有机房的网络打通，实现内网互通为数据同步做好准备；

第二步提前同步数据，使用Xtrabackup备份在线把MySQL配置成主从同步模式，将数据同步到阿里云ECS，在一段时间后完成数据迁移。

第三步正式迁移，正常的游戏停服维护时间（0.5~2小时）就可完成业务上阿里云的迁移。目前已经平滑完成3款游戏产品的迁移，每款产品准备时间3~5天，正式迁移用时1~2小时，在阿里云平台使用的虚机超过1000台。

如何去选择合适的数据库？

原文地址：http://www.cnblogs.com/aliyunblogs/p/5285027.html