游戏服务器全球服架构(游戏服务器架构设计)

阿里云架构师解读四大主流游戏架构

游戏 行业是阿里云最早聚焦的行业之一,近年来 游戏 行业的变化、云计算产品技术的变化都与日俱进。随着行业业务的变化、技术架构的演进以及阿里云产品的迭代演进,整体的产品技术选型在不同的 游戏 场景、业务场景也不尽相同。本文将聚焦阿里云弹性计算产品在 游戏 行业的方案实践经验。

当前, 游戏 行业的各种场景和行业发展密不可分。简单回顾电子 游戏 的发展,80年代的黑白机,90年代的PC单机 游戏 ,00年代前夕随着互联网的发展网络 游戏 开始盛行,2010年后随着移动设备的逐渐普及,手游在国内开始兴起。

从 游戏 终端来区别,主要有:主机 游戏 (往往是3A 游戏 )、PC 游戏 、移动 游戏 和网页 游戏 等。目前出现跨平台多端 游戏 ,以及云 游戏 化的趋势。

关于 游戏 的品类区别会有非常多的维度:RPG(角色扮演)、MOBA类、竞技类、FPS(射击类)、休闲类、卡牌类、棋牌类、SLG(策略类)等等。目前有多品类融合玩法裂变的趋势。

随着国内防沉迷、版号因素,近年来 游戏 行业诞生了越来越多的精品 游戏 ,出海全球化乃至区域化,以及整体存量用户增速放缓,长线运营、精细运营以及私域社区等运营方式也在悄然变化。

不同的业务场景技术架构不尽相同,如竞技类 游戏 和卡牌类 游戏 对计算的需求就有所区别,云 游戏 与常规的网络 游戏 架构也有所区别。这里主要从 游戏 服和 游戏 平台、大数据、云 游戏 这四个目前常见的场景简单介绍其架构。

游戏 服,从 游戏 类型来看有RPG、FPS、MOBA、SLG、棋牌、休闲等等;从 游戏 平台来看通常有主机、手机、PC等;从业务发行来看有全球、国内、海外,从部署架构来看有集中部署和分区部署;从技术架构来看, 游戏 行业也有逐渐分层解耦的趋势,但与互联网应用相比,有一定其独特性。

因为 游戏 的强交互性特点, 游戏 技术架构与其他互联网应用相比有一定独特性。 游戏 需要保持会话连接,也就是从一个客户端到服务端的长连接,便于对客户端中玩家的操作、行为等进行及时的反馈以及推送给共同 游戏 或对战的其他玩家,所以 游戏 普遍对网络质量更加敏感,网络质量较差的情况会使长连接断开或重连,引起玩家掉线。 游戏 也需要保持会话的状态,既服务端会保持一份玩家的实体,当玩家进行操作时,下次通信的数据会依赖之前的通信的数据,这也是一些MMO(多人在线)大型 游戏 对网络吞吐性能要求较高的原因之一。再比如FPS、MOBA类等多人对战类 游戏 ,交互性更强,对网络延迟容忍度更低,要求低延迟。因为 游戏 需要比较高密度的记录玩家的操作以及结果,所以有频繁写入数据的特点,这类场景需要较强的IO性能。因为 游戏 强交互性、低延迟的特点,其技术架构也和互联网应用不同,在逐渐分层解耦的同时,需要保证 游戏 玩家的交互效果,同时也会依赖到底层服务器的计算能力。

这些都是 游戏 场景普遍存在的特点:长连接保持会话、保持状态、低延迟网络、高IO吞吐、高计算性能。

游戏 的部署架构会结合 游戏 业务特点、 游戏 运营需求来制定 游戏 服务,有分区分服、全区全服业务逻辑,分区分服还是全区全服,最大的架构差异在于数据是不是一套。而从部署方式看,主要是集中式部署和分区域部署。

集中部署就是不论 游戏 玩家在哪里, 游戏 服务集中在一个区域,适合对网络延迟要求通常不高的 游戏 类型,如休闲类;分区部署是指 游戏 服务器根据 游戏 玩家地域分布,分区域部署,方便就近接入,适合对网络延迟要求较高的 游戏 类型,如MOBA、FPS类。

典型架构

MMO类有高并发特点,大量玩家并发的高计算量负载对服务器的计算能力和稳定性有着极高的要求。同时MMO类 游戏 有着比较强的PVE或PVP特性,对网络延迟的容忍度较低。

其中网关服务器负责所有网络数据包的转发,通常是网络负载较集中的点,对于网络吞吐能力要求较高。单个 游戏 区承载玩家数量高,逻辑服务器通常按照场景地图来划分,规模再大会通过分区的方式实现。

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

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

(1)MMO 游戏 服性能与稳定需求,建议使用最第7代ECS实例,根据实际需求选型c计算型(CPU与内存配比1:2)/g通用型(1:4)/r内存型(1:8),Intel Ice Lake 2.9GHz基频3.5GHz睿频提供超高性能,能更好地优化 游戏 体验。

(2)异步落库以及日志服务器,对于磁盘读写性能要求高的场景,建议云上使用ESSD PL 0/1/2/3根据业务性能需要选择,避免磁盘读写瓶颈。

(3)在 游戏 日常版本更新中,需要各个地域Region镜像的快速复制,基于ESSD快照异地复制的能力,能够提升镜像复制效率。

(4)分区分服等场景往往需要快速地开服滚服合服,通过CADT云速搭、ESS弹性伸缩、OOS运维编排、ROS资源编排等云上运维工具搭配产品使用,能够提升云上运维效率。

ii. FPS、MOBA类 游戏 架构介绍

MOBA类 游戏 主要包括PVP系统、PVE系统、 游戏 平台等几个主要部分,其中PVP战斗是MOBA/FPS 游戏 的核心。

PVP、PVE、 游戏 平台功能部署于同一VPC中,构成 游戏 大区;战斗服务器(往往)单独跨地域部署。

游戏 客户端首先接入到登录服务器中,完成登录认证、计费等 游戏 平台逻辑。为避免单点问题,所以 游戏 平台服务往往需要高可用方案。可利用云上高可用方案,包括便捷的运维工具满足业务高可用需求。

FPS/MOBA竞技 游戏 ,往往对延迟特别敏感,可以想象,竞技类 游戏 中对战的 游戏 场景:玩家操控人物,在地图里步伐飘逸,枪声密集,每一颗子弹都是一次时间加上空间的矢量计算,而且需要在主进程中完成计算,那么算力需求就随着房间玩家数量上升而指数爆炸,5V5的房间和大房间100人(吃鸡)对算力的需求完全不同。

游戏 这部分重算力场景,推荐阿里云7代高主频或七代实例,更高的单核性能提供更好的战斗效果。

战斗房间类 游戏 ,因为业务本身峰谷特性,灵活地使用云上资源的弹性能力,往往会较好地优化整体的资源使用成本。阿里云弹性计算本身提供了非常灵活的付费方式,包括常规的按量实例、包月包年实例、以及通过节省计划/预留实例券去抵扣按量实例资源,兼顾资源灵活使用的同时达到更优的成本。

此外,为更进一步释放开发运维的效率,当前一些 游戏 也采用了容器化技术架构,阿里云的ACK+ECS/ECI弹性容器实例组合搭配使用,更进一步释放了基础资源的灵活性和弹性能力。

业务场景

游戏 平台(不限于FPS、MOBA类)主要提供的服务:官网、客服、注册、登录、充值、兑换、商城、推送、公告、社区、SDK及邮件、短信等公共服务;包括内容审核、视频录制、弹幕、转码、剪辑、RTC这些业务需要的基础服务,以及运维监控、发布平台、测试平台这些运维等平台服务。

这部分更接近于通用的互联网技术架构,以服务为颗粒度解耦,接入-网关-应用-数据库。

技术特点

这往往通常需要构建高可用基础架构来提升稳定性,业务突发期往往需要一定的弹性能力。相比于 游戏 服务这部分容器化就更加普及,也更容易通过云上的比如弹性容器实例去应对流量峰值场景。在视频录制场景,对实时性要求较高时,往往会基于GPU能力构建,这部分阿里云也提供了vGPU/cGPU能力,释放GPU的灵活性。

大数据是当前 游戏 业务经营、 游戏 运营主要的技术手段,主要面向平台数据运营、 游戏 数据分析、广告转化分析、安全运营分析等 游戏 核心运营场景。不同的场景对实时性要求不同,实时查询检索通常是经营分析、客户受理、玩家监测、在线等场景;离线报表通常是玩家行为分析、用户画像、特征挖掘等场景。

总体而言,实时性业务更多是业务查询类、简单计算类任务,比如买量转化的分析;离线类基本是分析类、预测类任务,比如 游戏 玩法分析。

从技术架构来看,得益于开源社区技术栈的高丰富度,大数据具体的技术选择非常之多,整体从存算一体到存算分离,也诞生像数据仓库、数据湖乃至湖仓一体等概念。

从数据架构流程来看,从数据源-数据采集、传输-数据计算、存储-数据应用,其中可选看技术方案也需要因地制宜。

从部署架构来看,不同的 游戏 公司处在不同的数据建设阶段,会有不同的选择倾向,包括完全自建、基于云自建大数据、基于云上托管、以及利用更多云上成熟的产品技术去丰富整体的大数据能力集,而后者也成为越来越多客户的选择。

拿云上大数据方案举例来讲,比如实时计算部分,选择SLS采集、Kafka数据网关通道,通过Flink做数据计算,通过ES或CK做数据分析,通过ADB以及QuickBI做数据应用展示。离线方案通过OSS做冷数据存储,Spark、Hive、HDFS等组件做数据计算存储,通过CK汇聚分析,通过Dataworks做数据应用。

具体计算存储的产品选型,主要根据不同的业务特性以及大数据应用特性来区分,根据数据容量、IOPS、吞吐、读写特点以及性价比来选择。

如刚刚举例的实时计算/近实时计算场景,Flink具备高性能、低延迟特点,所以是计算密集、网络性能高场景,推荐选型七代ECS实例或6代增强实例;如HDFS需要超大存储容量,高吞吐,推荐D系列本地盘实例,如D2S存储型本地盘实例。Remote Shuffle Service等处理结果多的场景,读写处理频繁如大量的join计算,需要综合来看计算、网络、存储性能以及综合成本来选择通用实例(如第7代ECS实例)或i系列本地盘实例。所以,最终在云上的资源选型,在性能满足的前期下,需要评估通过网络传输数据成本高(云盘),还是就地取材计算成本高(本地盘),不同模型、不同量级选择不同。

从内存处理(成本最高、性能最好、存储容量最小)、SSD本地盘、HDD本地盘、ESSD云盘、OSS对象存储(成本最优、性能一般、存储容量最大),逐渐分层解耦,还带来一个好处:充分释放了云上弹性的能力,可以利用更轻巧的弹性计算产品(如SPOT抢占式实例方式,或ECI容器实例)进行大数据计算,达到更好的弹性能力去满足业务需求的同时也能节约更多的成本。

云 游戏 主要分终端和云端。终端部分基于Windows、iOS、Linux等操作系统的终端设备包括手机、平板、电脑、电视机、VR一体机等。云端架构主要是 游戏 应用层、云 游戏 平台层、IaaS基础资源层,应用层包括PC 游戏 、手游、VR 游戏 、H5 游戏 等多种类型的 游戏 应用;平台层云 游戏 必须的运营平台、支撑平台、流化技术平台等;IaaS基础资源层包括基础网络、基于X86架构以及ARM架构的GPU服务器。

云 游戏 落地,在技术上也经历了诸多挑战,为满足端到端高性能低时延,网络调度、指令串流、编解码、多终端的SDK适配等等都是云 游戏 场景中不可避免的技术问题。

对于云端算力来讲,阿里云解决了云端渲染、串流以及编解码问题,并通过全系列GPU产品来满足云手游、端游、VR乃至企业级视觉渲染场景的需求。

总结来讲,阿里云弹性计算通过云上的串流、编码加速、渲染加速等全套的技术帮助 游戏 客户给云 游戏 玩家提供更好的性能体验,通过基于阿里云全球数据中心可以帮助云 游戏 客户覆盖更多的用户,通过GPU多种产品形态和整体的弹性能力,也帮助到 游戏 客户去更快捷更灵活的构建其云 游戏 业务。

阿里云通过多年的技术积累和持续的运营,提供了大规模的基础设施云服务,目前在全球部署了26个地域、82个可用区,通过优异稳定的性能表现帮助 游戏 客户高效稳定地运行 游戏 业务,为玩家提供极致顺滑的 游戏 体验,并通过技术手段不断地帮助 游戏 客户优化用云成本。

国内的业务出海、 游戏 出海也是现阶段大的趋势之一,很多 游戏 公司已经把出海从业务可选项变成了必选项之一。在2022年3月,阿里云上线了韩国和泰国两大Region,能够为本地化的 游戏 业务提供更流畅、更稳定的 游戏 体验,以此希望能在 游戏 客户出海的业务领域,提供更多的帮助。

当然,作为内容与 科技 两大热门领域的交叉领域, 游戏 产业日新月异,架构也随着前端业务的需要不断改变。阿里云弹性计算也针对 游戏 厂商的不同架构,陆续推出了不同的云服务器类型和付费方式,以及云上运维套件,以帮助客户降本增效。

原文链接:

WebSocket+SLB(负载均衡)会话保持解决重连问题

写在最前面:由于现在游戏基本上采用全球大区的模式,全球玩家在同一个大区进行游戏,传统的单服模式已经不能够满足当前的服务需求,所以现在游戏服务器都在往微服务架构发展。当前我们游戏也是利用微服务架构来实现全球玩家同服游戏。

玩家每次断线(包括切换网络/超时断线)后应该会重新连接服务器,重连成功的话可以继续当前情景继续游戏,但是之前写的底层重连机制一直不能生效,导致每次玩家断线后重连都失败,要从账号登陆开始重新登陆,该文章写在已经定位了重连问题是由SLB引起后,提出的解决方案。

每次重连后,客户端向SLB发送建立连接,SLB都会重新分配一个网关节点,导致客户端连接到其他网关,重连失败。

会话保持的作用是什么?

开启SLB会话保持功能后,SLB会记录客户端的IP地址,在一定时间内,自动将同一个IP的连接转发到上次连接的网关。

在网络不稳定的情况下,游戏容易心跳或者发包超时,开启会话保持,能解决大部分情况下的重连问题。

但是在切换网络的时候,手机网络从Wifi切换成4G,自身IP会变,这时候连接必定和服务器断开,需要重新建立连接。由于IP已经变化,SLB不能识别到是同一个客户端发出的请求,会将连接转发到其他网关节点。所以使用TCP连接的情况下,SLB开启会话保持并不能解决所有的重连问题。

另外某些时刻,手机频繁开启和断开WI-FI,有时候可能不会断开网络,这并不是因为4G切换WI-FI时网络没断开,从4G切换到Wi-Fi网络,因为IP变了,服务器不能识别到新的IP,连接肯定是断开的。这时候网络没断开,主要是因为现在智能手机会对4G和Wi-Fi网络做个权重判断,当Wi-Fi网络频繁打开关闭时,手机会判断Wi-Fi网络不稳定,所有流量都走4G。所以网络没断开是因为一直使用4G连接,才没有断开。想要验证,只需要切换Wi-Fi时,把4G网络关闭,这样流量就必定走Wi-Fi。

上面说过,四层的TCP协议主要是基于IP来实现会话保持。但是切换网络的时候客户端的IP会变。所以要解决切换网络时的重连问题,只有两个方法:1. 当客户端成功连接网关节点后,记录下网关节点的IP,下次重连后不经过SLB,直接向网关节点发送连接请求。2.使用 SLB的七层(HTTP)转发服务。

当客户端经过SLB将连接转发到网关时,二次握手验证成功后向客户端发送自己节点的IP,这样客户端下次连接的时候就能直接连接网关节点。但是这样会暴露网关的IP地址,为安全留下隐患。

如果不希望暴露网关的IP地址,就需要增加一层代理层,SLB将客户端请求转发到代理层,代理层再根据客户端带有的key,转发到正确的网关节点上。增加一层代理层,不仅会增加请求的响应时间,还会增加整体框架的复杂度。

阿里云的七层SLB会话保持服务,主要是基于cookie的会话保持。客户端在往服务器发送HTTP请求后,服务器会返回客户端一个Response,SLB会在这时候,将经过的Response插入或者重写cookie。客户端获取到这个cookie,下次请求时会带上cookie,SLB判断Request的Headers里面有cookie,就将连接转发到之前的网关节点。

HTTP是短链接,我们游戏是长连接,所以用HTTP肯定不合适。但是可以考虑基于HTTP的WebSocket。

什么是WebSocket?

WSS(Web Socket Secure)是WebSocket的加密版本。

SLB对WebSocket的支持

查看阿里云SLB文档对WS的支持,说明SLB是支持WS协议的,并且SLB对于WS无需配置,只需要选用HTTP监听时,就能够转发WS协议。说明WS协议在SLB这边看来就是一个HTTP,这样WS走的也是七层的转发服务。只要SLB能够正常识别WS握手协议里Request的cookie和正常识别服务器返回的Response并且往里面插入cookie,就可以利用会话保持解决重连问题。

Go语言实现WS服务器有两种方法,一种是利用golang.org/x/net下的websocket包,另外一种方法就是自己解读Websocket协议来实现,由于WS协议一样是基于TCP协议之上,完全可以通过监听TCP端口来实现。

客户端发送Request消息

服务器返回Response消息

其中服务器返回的Sec-WebSocket-Accept字段,主要是用于客户端需要验证服务器是否支持WS。RFC6455文档中规定,在WebSocket通信协议中服务端为了证实已经接收了握手,它需要把两部分的数据合并成一个响应。一部分信息来自客户端握手的Sec-WebSocket-Keyt头字段:Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。对于这个字段,服务端必须得到这个值(头字段中经过base64编码的值减去前后的空格)并与GUID\"258EAFA5-E914-47DA-95CA-C5AB0DC85B11\"组合成一个字符串,这个字符串对于不懂WebSocket协议的网络终端来说是不能使用的。这个组合经过SHA-1掩码,base64编码后在服务端的握手中返回。如果这个Sec-WebSocket-Accept计算错误浏览器会提示:Sec-WebSocket-Accept dismatch

如果返回成功,Websocket就会回调onopen事件

游戏服务器的使用的TCP协议,是在协议的包头使用4Byte来声明本协议长度,然后将协议一次性发送。但是在WS协议是通过Frame形式发送的,会将一条消息分为几个frame,按照先后顺序传输出去。这样做会有几个好处:

websocket的协议格式:

参数说明如下:

阿里云的SLB开启HTTP监听后,会检查过往的Request和Response请求,收到服务器返回的Response后,会往Response插入一个Cookie

客户端收到服务器的Response后,可以在Header中查到有个“Set-Cookie”字段,里面是SLB插入的Cookie值

客户端断开连接后,下次发送请求需要往Headers插入Cookie字段

分别在阿里云的两台ECS实例上部署WS服务器,打开8000端口,开启一个SLB服务,SLB服务选择HTTP方式监听,并且打开会话保持功能,Cookie处理方式选择植入Cookie。Demo服务器没有做HTTP健康监听的处理,健康检查这块可以先关掉。

在两台ECS上启动WS服务器,然后本地运行客户端,分别测试两台服务器是否能正常连接,测试完毕后,测试SLB能否正常工作。服务器和SLB都正常的情况下,运行客户端,客户端会得到以下结果

收到的三次Cookie都相同,说明Cookie是有正常植入工作的,并且三次都被SLB正确抓取了。

收到的三次serverId也都是同样的值,说明三次都是同一个ECS上的服务器响应。

至此,验证成功。

Websocket+SLB会话保持能够解决超时重连和切换网络时重连的问题。

参考:

阿里云会话保持

解答Wi-Fi与4G网络切换的困惑

WebSocket的实现原理

阿里云SLB对WebSocket的支持

HTTP Headers和Cookie

像LOL这种竞技类游戏的游戏服务器架构是怎样的?

我认为撸啊撸这种竞技类的游戏客服架构,我觉得是一种非常正常的现象,所以说我们在生活当中一定要有一个良好的方式去让他对我们产生一个有益的想法,然后利用他们给我们的这种便利,然后做一些比较能够便利社会的事情,而且我觉得她非常的优秀,可以让我们在游戏体验中得到一个不错的感觉。

游戏服务器架构和web服务器架构的区别?

1-技术有什么区别

首先通信上目前的主流是HTTP协议和SOCKET这两种(HTML5提供了一种新的协议,WebScoket,对此了解并不多,因此不做评论,以免误导)。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应,在请求结束后,会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

(注:在HTTP 1.1中则可以在一次连接中处理多个请求,并且多个请求可以重叠进行,不需要等待一个请求结束后再发送下一个请求。)

Socket又称\"套接字\",应用程序通常通过\"套接字\"向网络发出请求或者应答网络请求。

以J2SDK-1.3为例,Socket和ServerSocket类库位于包中。ServerSocket用于服务器端,Socket是建立网络连接时使用的。在连接成功时,应用程序两端都会产生一个Socket实例,操作这个实例,完成所需的会话。对于一个网络连接来说,套接字是平等的,并没有差别,不因为在服务器端或在客户端而产生不同级别。不管是Socket还是ServerSocket它们的工作都是通过SocketImpl类及其子类完成的。(摘自百科)

在WEB服务器中,一般情况是只需要使用HTTP协议的。因为它不太需要去与浏览器进行主动推送,只需要响应浏览器的访问就足够了

而在游戏服务器,这样的连接方式肯定是不够用的。很多时候游戏服务器是需要主动推送消息,如系统广播。

2-思维有什么区别

WEB服务器并不需要高频即时通讯,对响应速度要求不高。而游戏服务器,大多数是需要很及时的响应速度(暂不讨论弱联网游戏)。如DOTA,这种竞技类型的游戏,1秒就能发生很多事。

因此,在思考方向上,WEB服务器应该考虑是的多平台的兼容,大量用户访问的高并发。

而游戏服务器应该考虑的是高频通讯,高并发。

3-架构的侧重点有什么区别

在架构上面,一般访问量不是很大的网站是只有一台服务器的,访问量高的才会进行分布式设计或者集群设计。

而大部分游戏服务器都是需要分布式设计的。

在现有的网络游戏服务器端架构中,多是以功能和场景来划分服务器结构的。具体的划分是根据项目的需求进行的,并没有一个十分通用的架构。

以上是比较常见的结构,客户端登录的时候,连接GateServer,然后由GateServer去连接LoginServer进行登录。登录后通过CenterServer转发到GameServer(GameServer即是服务器大区)。

而其中的DCServer,主要的功能是缓存玩家角色数据,保证角色数据能快速的读取和保存。

LogServer便是保存日志的了。

4-本质有无区别

本质上,两者并无区别,只是需求不同,侧重点不同罢了。

游戏服务器与普通服务器有什么区别

首先,游戏服务器与普通服务器相比较来说,游戏服务器需要能够保存更多的用户的状态。用户的等级等属性不用说,一般的IM服务也会有,还有一些时刻变化的数据,比如某个玩家的生命值,发技能前后的法力值等等,这些值区别于一般的属性值如名字,ID这些,这些数据会经常性的变化,还会参与到逻辑的计算中,比如你一个多少等级的玩家吃了什么东西之后战力值变化为多少,打在一个多少属性的玩家身上会不会被他闪避,会不会产生暴击…诸如此类的信息,在游戏服务器中都会一一保存。

其次,游戏服务器中每一个用户都是独立存在的,每一个用户的数据、请求等都是独立的,用户彼此间的数据并没有任何交互。这也是游戏服务器与普通服务器之间最大的区别。至于客户端之间会有交互这一点,举最简单的例子,一个人在一个场景里面说了一句话,那么“同一个屏幕”的玩家也需要能够看到他说的这句话。此时游戏服务器就需要判断,多远的距离以内的玩家,会认定为是\"同屏幕\"的玩家,需要向这些玩家广播这个玩家说的这句话。

这个广播就比较麻烦了。首先,需要计算哪些玩家属于\"同屏幕\",就是我们在第一点提到的玩家身上某些经常变化的属性需要做的运算,在这里需要根据玩家的坐标,找出来跟在同屏幕的玩家,用到的是AOI的概念。另外,找到了这些需要接收这个消息的玩家之后,将消息转发给它们又是一个IO密集的操作,假如场景中有10个人,那么一句话就需要同时广播给另外9个人,假如有100人,1000人呢,数据量就更大了,而且时间的延迟也不能太长,这对于游戏服务器的性能就要求很高了。所以同样的一个硬件配置的服务器,可能跑Nginx可以同时处理上万的链接,但是对于一个游戏服务器就只有1,2千了,就是因为游戏服务器是一个CPU密集而且IO密集的服务器类型。而且不仅需要这样的游戏服务器不仅要求性能比较高,还需要服务器具有极高的稳定性,总不能隔一会就宕机了,那大家还怎么玩。

此外,游戏服务器需要更好的数据承载能力和处理能力。而普通服务器则在各个方面都比较均衡。在寻找游戏服务器租用商的时候,一定要选择那种CPU性能非常出色的。

最后一点,游戏行业一直以来是网络攻击的重灾区,很多游戏刚上线没多久就频繁遭到攻击,导致玩家大量流失口碑下降,最后可能导致直接关服。所以游戏服务器一定要带高防流量包。

未经允许不得转载:便宜VPS网 » 游戏服务器全球服架构(游戏服务器架构设计)