架构解析

网关服务器负责所有网络数据包的转发，通常是网络负载较集中的点，对于网络吞吐能力要求较高。

场景服务器包含游戏逻辑，相对依赖CPU处理能力以及一定的网络包转发能力。

单个游戏区承载玩家数量过万，逻辑服务器通常按照场景【地图】来划分，规模再大会通过分线的方式实现。

数据中心服务器负责缓存玩家数据并异步入库，保障玩家客户快速获取和写入数据，对于可用性要求较高，需要配合应用层实现数据容错机制。

日志服务器承载了大区所有业务行为的日志收集及处理的压力，对磁盘写入性能要求较高，通常采用多台分组方式实现

架构解析

手游项目相对端游玩法复杂度较低，生命周期相对较短，结合运营策略及资源经济模型通常采用相对简单的部署架构，少部分大型MMO类手游也会沿用端游部署架构。

游戏数据库服务器可以采用与游戏服务器1：1的配比关系，也可以采用多区共用的部署方式。

架构解析

通过负载均衡及网关服务器将原多台逻辑服务器组建成大服，同服可以承载更多玩家在线，有助于打造玩家生态。

通过网关服务器实现玩家请求调度及连接状态监测。

国战服务器（或PVP战场服务器）计算性能及负载能力相对要求更高，可以采用高配置实例或独享型实例构建，并由网关服务器统一调度管理。

架构解析

页游整个游戏过程的内容加载依赖CDN，对CDN的稳定性和下载速度有一定要求，资源加载通常采用大文件资源包分段加载和小文件随时加载两种方式。

页游通常采用快速开服、合服的运营策略，短时间内可能开通上千个游戏区，并随着每个区的活跃玩家降低而陆续的合服，通过自定义镜像加自动开服脚本可以实现快速的创建游戏大区及逻辑服务器。

页游计算复杂度相对端游、手游较轻，单个游戏区对服务器的计算能力和网络吞吐能力没有特殊要求，通常会采用一机多开的方式，会依据计算负载来决定每台服务器开服的数量。

逻辑服务器层和游戏数据库层通常会采用集中部署和分区部署两种方式。

架构解析

页游整个游戏过程的内容加载依赖CDN，对CDN的稳定性和下载速度有一定要求，资源加载通常采用大文件资源包分段加载和小文件随时加载两种方式。

页游通常采用快速的开服、合服的运营策略，短时间内可能开通上千个游戏区，并随着每个区的活跃玩家降低而陆续的合服，通过自定义镜像加自动开服脚本可以实现快速的创建游戏大区服务器。

页游计算复杂度相对端游、手游较轻，单个游戏区对服务器的计算能力和网络吞吐能力没有特殊要求，通常会采用一机多开的方式，会依据计算负载来决定每台服务器开服的数量。

逻辑服务器层和游戏数据库层通常会采用集中部署和分区部署两种方式。

架构解析

接入层服务器集群借助ESS实现自动扩容及缩容，能够有效的应对开机风暴、国战活动高峰等场景，保障服务器集群资源的负载能力。

登录服务器或有弹性伸缩需求的服务器同样适用此方案。

架构解析

通过多级下载重试，保障下载及更新高可用，降低在此环节的玩家流失比例。

通过回源地址与直接对外下载地址分离，规避可能存在的地址暴露安全隐患。

通过设置OSS作为CDN源站，借助OSS异地自动复制功能，进一步提升源站可用性及吞吐能力。

如采用ECS构建源站，可以使用多SLB实例+ECS实现不同IP地址接入，以保障源站高可用。