云服务已经是大势所趋了，通过购置传统服务器来进行应用开发，无法与现代化敏捷的开发方法相结合，对于系统运维的难度也大大增加，而云服务的弹性伸缩、动态计费可以很好地帮助中小企业实现快速应用开发，使得产品的价值最大化，而亚马逊在这方面有很多年的技术和解决方案的沉淀，本次是通过学习亚马逊云科技助力游戏上云《运行》阶段的学习心得，主要是是研究了亚马逊在云游戏上的相关解决方案，真的让我醍醐灌顶。

这次主要学习了：

• Amazon对于游戏上云提供的基础设施
• MOBA游戏如何上云？
• 无服务器游戏后端解决方案
• 如何防范DDOS攻击以及相关解决方案？

Amazon对于游戏上云的基础设施

弹性游戏服扩展

如何实现游戏的弹性扩展呢？在之前的学习中就有提到GameLift，Amazon GameLift 是一个专门的托管解决方案，可以用来部署并自动扩展，基于连接的多人游戏服务器队列，以满足全球玩家的需求。用户通过 Amazon GameLift 能够创建和上传游戏服务器，一次性构建、复制，并且部署至多个地区和本地区域，提供全球玩家低延迟游戏体验。

通过GameLift可以轻松地实现弹性的游戏扩展，在保证服务器的扩展性同时还可以有较低的延迟，对于对战匹配模块还可以有效保证对局的平衡、缩短等待的时间；当解决完应用的扩展性之后，我们也要考虑底层数据库的扩展性，要想整个系统扩展性都得到较大的提升，必须对整个链路的可用性进行合理评估，并根据扩展性情况进行合理重构或者上云。

游戏数据库

游戏其实也是需要数据库的，往往游戏都不止会使用一种数据库，因为在游戏中，用户会产生各种各样的数据。例如用户的注册，积分榜、虚拟物品，还有游戏中的一些比赛检测，玩家都会产生大量需要实时处理、存储和访问的数据，为了保证业务能够合理地开发，我们需要根据业务情况选择合理的数据库，并且保证数据库能够具备高扩展性。

而在这方面，亚马逊提供了丰富的数据库让我选择：

• 关系型数据库：Aurora、RDS
• 键值型数据库：DynamoDB
• 文档型数据库：Document
• 图式数据库：Neptune
• 时序数据库：Timestream
• 记账式数据库：QLDB
• 宽列存储数据库：Managed Cassandra

我们在游戏开发的过程中，一般都会使用到Nosql，而对于非游戏核心模块，例如注册、用户基本信息等都会使用关系型数据库。而对于Nosql，亚马逊这边也提供了多种数据库给我们选择：

• Amazon DynamoDB：键值型NoSQL数据库，适合存放游戏玩家的数据，稳定的延迟，无限的扩展
  • 支持海量数据和吞吐，写入读出个位数毫秒延迟
  • 无需运维
• Amazon Redis：兼容Redis6所有协议的内存级数据库，适合高速变化的游戏状态数据，高速且持久化
  • 内存级读取速度
  • 数据持久化能力，个位数毫秒写入延迟
• Amazon DocumentDB：完全托管式文档数据库服务轻松扩展JSON工作负载，兼容MongoDB场景
  • 通过独立扩展计算和存储，支持每秒数以百万计文档的读取请求
  • 可扩展、高持久性且完全托管式数据库服务，用于操作任务关键型MongoDB工作负载

这里可以着重关注一下 DynamoDB，这个组件的论文获得了图灵奖，是亚马逊通过多年经验研发的，通过使用这些云数据库，可以不再用DBA团队，节省运维成本，对于DynamoDB，Supercell使用之后成功获得了1亿日活的用户，解决了每天产生的500TB数据，足可以看出其性能和可扩展性是非常高的

但是这么多弹性组件，真能组合成一款游戏吗？这个我也是带着疑问的，最后看到亚马逊自己做了一个新世界游戏，并且有很明显的效果，真的很感慨，未来已来！

MOBA游戏如何上云？

MOBA类游戏就不得不提英雄联盟手游、DOTA2、英雄联盟等等，这类游戏的玩法是：在战斗中一般需要购买装备，
玩家通常被分为两队，两队在分散的游戏地图中互相竞争，每个玩家都通过一个RTS(Real-TimeStrategy)风格的界面控制所选的角色。这类游戏通常无需操作RTS游戏中常见的建筑群、资源、训练兵种等组织单位，玩家只控制自己所选的角色。

• (1)以局为单位（开房间），快节奏（每局游戏时间为几分钟至几十分钟不等)。
• (2)组队对抗(4V4,5V5),即时对抗.互动性强，社交属性。

MOBA游戏常见的技术挑战有哪些？

• 资源调度
  • 战斗匹配的机制，对于战斗服的需求，根据业务的高峰低谷时间差异明显，需要很强的资源调度能力以节约成本
• 网络要求
  • 实时竞技中，客户端与服务器端产生海量的数据交互，对网络带宽吞吐能力和延迟要求非常高。玩家匹配的公平性成为保障游戏成功的核心要素
• 大量实时计算
  • 游戏中由玩家移动、发动技能、转换装备、调整属性等产生的数据需求，服务端需要进行大量实时计算进行支持。

以下是一个MOBA应用的架构用例：

MOBA大厅服务的推荐架构

大厅服功能主要是：竞技类型的游戏通常分为大厅服和战斗服，玩家在进入战斗之前和战斗结束之后都停留在大厅服，在大厅服中玩家可以查看自己角色的信息，和好友之间互相聊天、组队，查看战斗回访录像，进入商城购买喜欢的道具与皮肤，查看自己战绩排行榜，匹配其他玩家开启一局对战等。

为了支持玩家所需要的各种功能，大厅服包含了大厅、消息通道、聊天、排行榜、匹配、商城等功能模块。

• 大厅主要用于承载玩家的连接，获取玩家角色状态信息
• 聊天用于玩家之间的文字语音交流
• 排行榜用于显示所有玩家的排名情况
• 匹配用于玩家、玩家队伍之间的匹配
• 消息中枢是大厅和其他功能模块之间通信的中间桥梁
  

无服务器游戏后端解决方案–事件驱动的serviceless游戏后端架构

常见的游戏后端服务器管理方式

• 完全自建: 在云中创建一个定制的服务器基础设施，同时保持对环境的控制。然后根服务器监控指标做出管理。
• 托管服务: 更快地发布你的游戏，并迅速为玩家带来他们所期望的游戏体验。用更少的操作资源维护服务器，并轻松提供更新、补丁和新内容。

完全自建的情况下需要考虑我们的运维成本和运维压力，但是托管服务可以大大减少我们时间从而有更高的可用性，因为云平台在退出产品时就已经达到了五个9的可用性了。

托管服务解决方案有：

• 事件驱动Serverless：如果是可以拆分成微服务，事件驱动导向的架构，可以做到无状态化，可以使用全Serverless架构。
• 会话管理Gamelift：如果对网络对战和事件有优先级需求，那么可以使用Gamelift帮助你管理game session.和底层服务器的硬件调度。

为什么会采用事件驱动的serverless架构

网游最受欢迎的两种模式是p2p和dedicated server，现代化游戏开发又出现了一种新的架构方式，即游戏云原生（没有固定的服务器去运行服务端程序，而是通过API）

• 我们来看一下传统的游戏后端架构：
  
• 采用serverless的游戏架构：

可以看到，serverless架构就没有和传统架构一样有明确的分层了，对于游戏服务层里面可以更灵活地组合起来。采用Serverless后对项目还是产生了比较大的影响，从新旧架构中也能发现：

• 快速启动项目、不需太多运维人员： 客户之前的经验，管理docker系统仍须相当多的人员，但使用Serverless的架构，大量的运维工作转移到AWS,只需4~5人的团队
• 更加云原生、可以随时调整架构：没有固定的基础架构，可以灵活的调用AP之间的逻辑调用，功能间隔离较佳，降低模块间的依赖间，方便新增功能模块
• 天然贴近开发思维、业务逻辑清晰：Serverless可以用开发人员管理AP的方式，管理整个架构，天然形成DevOps的开发模式，便于长期的开发运维管理

事件驱动设计的原理

所有的游戏逻辑和玩家行为都认为是事件驱动的

• 每个模块独立：每一项模块有独立的一套架构，将每项服务拆分为一个单独的独立流程，从而加速开发。
• 每个模块统一：所有的模块遵循统一的API开发模式，统一的数据结构，服务直接都是通过API互相调用。
• 每一项功能使用独立的DynamoDB表去存储缓存和状态数据

为什么我们要强调模块化呢？模块化带来的好处是啥？

• 模块之间相互独立，耦合度低
• 按功能区分，可以分别使用合适的协议，WSS保持客户端长连接和http短连接，甚至使用MQTT
• 信息交互放到DDB中
• 可以通过SNS和SQS做消息推送和队列，能降低lambda运行时间
• Dynamodb等服务可缓存可持久化

事件驱动设计案例

例如登录和大厅模块等，我们可以通过HTTP请求来负责登录和大厅模块，包括帐户创建/帐户修改/帐户删除/身份验证和支付
模块。将卡片商店，卡片收集API也包含在这部分中。

通过 CloudFront -> API Gateway -> Lambda -> DynamoDB 的这个流程，很简单就能研发出我们需要的效果，那么匹配模块就可以改造成下图：

Serverless架构于游戏的优点和挑战

优点

• 实现快速上线缩短创新周期：
  • 小团队的开发人员正可以在短期内开发应用程序并部署到生产。使用短而简单的函数和事件来驱动游戏逻辑和数据存储
    等API。部署速度极快。
  • 很适合小型初创的游戏团队。
• 增加弹性和灵活性：
  • 对于传统应用来说，要应对更多的请求的方式，就是部署更多的服务器。而Lambda会自动的扩展。无需规划业务的弹性扩缩策略。
• 减少资源浪费
  • 不计划到底需要使用多少资源，而是根据实际需要来请求资源。根据使用时间来付费，根据每次申请的计算资源来付费，让计费的粒度更小，将更有利于降低资源的开销。这是对游戏的优化。

挑战

主要在状态管理上：

• 要想实现自由的缩放，需要将有状态和无状态的服务进行分离，而要做Serverless架构就需要尽量避免事务性操作，所以在Serverless游戏中就要做事务性操作的无状态改造。
• 大部分的对战游戏会倾向使用有状态服务去处理玩家的游玩逻辑，而Serverless的游戏可以通过session和隐藏表单等方法解决有状态服务的事件问题。

抵御全球DDOS攻击

什么是DDOS攻击？

首先，我们要先理解DOS攻击，DoS(Denial of Service) 是拒绝服务攻击，过各种手段，使网络服务无法使用或不可用的行为，让正常用户的使用受到影响。

简单的DOS攻击如何应对呢，如果攻击来源单一，可以简单拦截IP防范，在入网层设置好对应黑名单，过滤规则等就可以了；但是随着互联网的不断发展，黑客们也明白了这种防范方式，于是就产生了DDOS攻击，是一种分布式拒绝服务攻击，攻击者往往地区都分布的比较分散，普通的范文已经足以产生效果了

例如这个ACCN攻击小组，直接对企业进行勒索，采用DDOS攻击收 “保护费”

一般中小企业根本没有办法抵挡，那我们应该如何解决呢？

如何从技术上防止DDOS攻击？

DDOS攻击类型

首先就是我们的网络是根据七层模型来构建的，黑客是可以根据他的环境对任意层进行攻击，所以我们的防范也需要在多层上进行处理。

UDP反射攻击

例如上图中黑客可以通过发送大量的UDP请求包，造成服务器的带宽消耗，让你的带宽没有办法处理正常用户的请求，从而达到攻击的目的，以下是一个攻击示例：

SYN泛洪攻击

黑客还可以在传输层，建立大量的TCP连接，形成SYN 泛洪攻击，对我们的防火墙或者负载均衡层造成影响，因为我们的链接表是有限的，如果连接表全让恶意请求给站满了，那么正常的用户就没法建立TCP连接了

Http泛洪攻击

通过并发大量的Get请求，让服务器的处理速度下降甚至是没有办法处理正常用户请求

近两年DDoS攻击趋势的变，边缘的计算能力增强，带宽变，肉鸡的能力也变强了；目前黑客对7层CC攻击变多了，
攻击也更加有纪律性（黑客对肉鸡的控制能力强了），我们系统做了防护错误，但是在短时间内，大流量的攻击，防御系统尚未及时启动

亚马逊是如何解决DDOS攻击的？

首先就是将整个请求链路梳理清楚，对各个地方的基础设施进行安全处理

通过上图可以看到，亚马逊的基础设施是十分安全的，攻击者无法获取到服务器的最终IP，而是会先进入边缘节点，而边缘节点也不是固定IP，会根据请求用户的环境进行分配，从而减少最终的服务器请求

如何缓解HTTP/HTTPS的DDoS

在有盾和没有盾的情况下都有不同的解决方案，如果在没有遁的情况下，我们需要尽可能让攻击效果最小化，并且让后台服务能够自动扩展，提升承载能力

可以看到，不同的角色访问的入口都是不一样的，普通用户通过ELB分配请求到EC2，因为ELB本身就具备了可扩展能力，所以可以轻松应对大量流量。

在这里，如果不想自己去处理，也可以使用亚马逊提供的安全盾解决方案：

亚马逊云科技Shield标准盾，主要分为：标准盾和高级盾。标准盾是默认开启的，并且免费，保护所有AWS，所以只要购买了基础的EC2服务器亚马逊就提供了安全保护措施；如果你的系统有更复杂的攻击，完全可以选择高级盾针，他可以针对大型和复杂的攻击提供全面的，额外的保护，需付费。

正确的配置Shield Standard标准盾

• 如果架构合适，尽可能的使用ALB/NLB和CloudFront/AGA
  • 托管的服务，后端自备弹性的架构
  • 全球PoP,流量很难打爆单点
• 正确的设置网络ACL和实例安全组
• Linux/Windows系统加固

当有3/4层DDoS攻击会发生啥？

• Cloudfront
  • 影响范围是很多客户，快速自动处理（号称秒级)
  • 处理方法，丢弃并黑洞被攻击的IP,生成新的IP放入DNS
• ALB
  • 影响范围是一个客户
  • 较快速的自动处理（号称分钟级）
  • 处理方法基本同上
• NLB
  • 影响范围一个客户
  • 部分自动处理（号称分钟级）
  • NLB默认不能抛弃IP,只能扩容抵挡（有上限）
• AGA
  • 局部类似NLB,全局较难打死

如何防止CC攻击

AWS 有提供 WAF 服务（即web应用防火墙），他会自动生效，通过 CloudFront 检查是否需要引入WAF实现自动化防护

当受到攻击后，亚马逊会自动发送攻击通知和报告，让我们能够及时感知到服务器的状态，并且很方便取证

以下是一个实际的攻击，可以看到攻击流量之大，但是通过 Shield Advanced 高级盾是可以完美解决的：

如果我们遇到了DDOS攻击，我们应该做么做呢？

• 先做好 Well Architected 良好架构
• 设置好NACL/安全组，使用AGA服务
• 巧妙使用托管服务，ALB/NLB等
• Shield Standard可以免费防护3/4层攻
  • 可以保护Route53/CloudFront
  • 流量清洗/黑洞/海量带宽
• Shield Advance有专家24x7保驾护航
  • 可以保护EIP/ALB/Route53/CloudFront等
  • 攻击通知/攻击报告/Byte Match等
• WAF可以防护7层攻击，包括Xss攻击，SQL注入和cc攻击等