本篇文章主要是写工作中关于游戏如果基于AWS的平台进行自动化部署的内容，涉及到的AWS基础知识不会做详细说明，具体细节技术内容可以参考官方文档，因作 者本人一直从事在基于AWS平台部署游戏，经历了游戏在物理机上的时代到现在采用云平台时代，在采用云部署后，给运维带来的便利，个人感觉简直是一个时代 的跨越，之前采用物理机部署的方式的种种不便或无法解决的问题，在云平台上基本不存在，或者很容易的解决，所以云不仅仅是运维成本的降低，而是会让你的企 业充分发挥创造力，如果你的公司也在考虑是否选择云平台来部署你的游戏，而且还没有任何经验，那么这篇文章就是写给你的，讲解共分二个部分：

架构篇

在实际动手部署前，在白板上画出你在AWS上的游戏部署架构是重要的，它会让你清晰的知道你如何应用AWS提供的各个组件去为你产品部署服务，好的架构不但能使你产品部署简单稳定，更会让你产品的可扩展性增强，针对游戏来说一般要考虑的的因素有：

1、Region的选择

2、VPC的设置，一个VPN还是一个项目一个VPC

3、子网的划分，涉及容灾

4、EC2实例的网络设置，是否需要公网

5、如果涉及费用考虑，也要考虑购买预留实例的百分比

6、日志备份

7、用户角色设置

如果游戏规模小，部署的不太复杂，考虑以上因素基本是够了，如果用到DNS可以用 route53的，如果涉及到数据分析，可以考虑EMR。

以上每个考虑都要根据实际业务进行考虑，如果是用户是东南亚的国家，建议用日本节点，实际测试，日本节点要覆盖好些，从台湾ping 到日本和新加坡基本都是50m以上，但到了晚上新加坡延迟会到100ms以上，所以日本对东南亚覆盖补充，如果用户是韩国，节点也可以选择日本。

VPC我个人建议采用一个，主要是方面管理，虽然可以设置多个VPN，例如一个项目一个，即使打通了每个VPC之间的链路通讯，但后续管理成本还是比较高的。

子网建议要至少2个，而且在2个子网要在不同的可用区中，这样将来即使有一个可用区宕掉，也只会影响一部分用户，不会导致游戏全部无法访问以下是示意图，采用的aws官方图片：

关于ec2的网络设备，为安全考虑，如果ec2不需要有公网，建立的时候就不要创建带公网的环境，确保安全，如果开服的量太大，能上百台以上了，觉需要考虑预留实例的购买了，这个百分比不好去评估，得看实际业务情况和公司的策略。

日志备份选择s3存储，定期将日志推动到s3上，对数据分析可以自己搭建hadoop或采用EMR，用户角色根据具体运维人员的分工设置不同角色类型，建议按用户组进行划分。

 

操作篇

当构建好如何部署后操作是很快的，一般是几个小时就可以完成，具体操作不展开说了，我就将我实际操作中的一些细节描述下，帮助大家如何快速自动化完成部署：

1、建立每个游戏服角色镜像：这个操作会让你快速启动另一组服务器，例如你搭建完一组，共三台，游戏服1，游戏服2，游戏服3，调试完毕后，为每个 服做一个镜像，这样你就可以快速启动1组新服，很快就可以完成上百组服务器的配置，在需要开新服时，你基本5分钟就可以开一组，所以为每个不同角色的游戏 服留镜像是很有必要的，同时也可以使用跨区复制功能，快速在另一个region搭建新服，快速完成多region部署，这些工作通过api是可以做到完全 自动化的。

2、设置安全组，为每个游戏服建立一个标准的安全组，这样每个ec2实例都使用相同的模板，避免后续混乱，安全组可以按类别来区分，例如游戏端口，内网互通，特殊开通等描述来建立不同安全组，然后叠加到实例上。

3、如果你是通过信任完成对每台机器的控制，一般是可以这样操作，你创建一个实例做中控，登录实例生成公钥，将公钥放到游戏服镜像中，之后所以启动的镜像，都可以直接ssh登录了。

4、EC2故障，可以卸载磁盘，解绑IP，然后新建实例，重新挂载磁盘，绑定EIP。

5、不要为每一个用户创建密钥

6、账单数据同步到S3bucket中，下载下来，用脚本分析每个业务的费用情况，实时监控。

7、定期查看资源限制情况，保证开服时资源可以立刻分配。

8、用好工单，疑难问题提交工单解决，英文要够好，因为是用英文进行书面交流的。