问题

端游、手游服务端常用的架构是什么样的?

回答
端游和手游的服务器架构在核心思想上有很多相似之处,但由于平台特性、玩家习惯、技术限制以及商业模式的差异,也存在一些显著的区别。下面我将详细阐述它们常用的架构,并尽量深入讲解。

核心通用架构思想:分布式与高可用

无论是端游还是手游,随着用户量的增长和游戏功能的复杂化,单体服务器已经无法满足需求。因此,分布式架构是所有大型在线游戏服务端的基础。其核心目标是:

可扩展性 (Scalability): 能够通过增加或减少服务器资源来应对用户量的波动。
高可用性 (High Availability): 确保游戏服务不会因单点故障而中断,即使部分服务器出现问题,玩家也能持续游戏。
高性能 (High Performance): 保证游戏运行流畅,响应迅速,满足玩家的低延迟需求。
可维护性 (Maintainability): 方便进行功能更新、bug修复和系统维护。

端游服务端常用架构

端游通常对性能、网络延迟和客户端复杂度有更高的要求。因此,其服务端架构往往更加复杂和精细。

1. 分层架构 (Layered Architecture)

这是最基础也是最核心的架构划分方式,将服务端的功能模块化,方便开发、测试和维护。

接入层 (Access Layer):
职责: 负责接收客户端的连接请求、处理网络通信(TCP/UDP)、数据加密/解密、以及初步的数据包校验和处理。
组件:
网关服务器 (Gateway Server/Login Server): 负责玩家登录认证、账号管理、创建角色、选择服务器等。
连接服务器 (Connection Server/Proxy Server): 负责维护玩家与游戏服务器之间的长连接,转发数据。通常会处理心跳检测,确保连接的有效性。
技术选型: Nginx (作为反向代理和负载均衡), Netty, Boost.Asio, 协程框架 (如 libco, C++20 coroutines) 等。

逻辑层 (Logic Layer):
职责: 游戏的核心逻辑处理,例如战斗计算、玩家状态管理、物品使用、技能释放、AI行为、副本逻辑等。
组件:
游戏服务器/世界服务器 (Game Server/World Server): 负责整个游戏世界的运行,包括地图管理、玩家在线状态、怪物刷新、任务系统等。
场景服务器 (Scene Server): 负责处理特定区域(如副本、地图区域)内的玩家交互、NPC行为、怪物AI等。一个大型游戏可能会有多个场景服务器。
战斗服务器 (Combat Server): 专门处理玩家之间的战斗逻辑,尤其是在需要精确计算和低延迟的PVP场景。
AI服务器 (AI Server): 如果AI逻辑非常复杂,可以单独剥离出来,由AI服务器集中处理。
技术选型: C++, Java, Go。注重性能和并发处理能力。

数据层 (Data Layer):
职责: 负责游戏数据的持久化存储、读写和管理。
组件:
数据库服务器 (Database Server): 存储玩家账号信息、角色数据、物品、任务进度、排行榜等。
缓存服务器 (Cache Server): 提高热点数据的访问速度,减轻数据库压力。例如玩家的当前状态、背包信息、交易记录等。
文件存储 (File Storage): 存储一些非结构化数据,如配置表、资源文件等。
技术选型: MySQL, PostgreSQL, MongoDB (用于一些非结构化或半结构化数据), Redis, Memcached (缓存), Ceph, MinIO (分布式对象存储)。

服务支撑层 (Service Support Layer):
职责: 提供各种辅助服务,保障游戏稳定运行。
组件:
配置服务 (Config Service): 管理游戏内的各种配置数据(如怪物属性、装备属性、任务配置)。
消息队列 (Message Queue): 用于不同服务之间异步通信,解耦,削峰填谷。例如GM命令下发、跨服消息同步。
任务调度服务 (Task Scheduler): 执行定时任务,如日常任务刷新、活动开启关闭。
监控告警服务 (Monitoring & Alerting Service): 收集服务器日志、性能指标,进行实时监控并触发告警。
分布式服务注册与发现 (Service Discovery): 如ZooKeeper, etcd,用于服务间的寻址和管理。
负载均衡器 (Load Balancer): 分发请求到不同的服务器实例。

2. 服务拆分与通信

端游服务端的核心在于将庞大的功能拆分成更小的、可独立部署和扩展的服务单元。

按功能拆分 (Functional Decomposition):
账号服务 (Account Service): 玩家注册、登录、信息管理。
角色服务 (Character Service): 玩家角色创建、删除、属性、背包、装备。
社交服务 (Social Service): 好友、公会、聊天、邮件。
战斗服务 (Combat Service): PVE/PVP战斗逻辑。
交易服务 (Trade Service): 玩家间交易、拍卖行。
副本服务 (Dungeon/Instance Service): 独立副本的生成、运行和管理。
AI服务 (AI Service): NPC、怪物AI。
GM服务 (GM Service): 游戏管理员后台操作。
通信方式:
RPC (Remote Procedure Call): 服务间调用最常用的方式。
同步RPC: 调用方等待被调用方返回结果。
异步RPC: 调用方不等待结果,通过回调或Future/Promise处理。
技术选型: gRPC, Thrift, Protobuf + 自定义TCP协议。
消息队列 (Message Queue): 异步解耦。
WebSocket/长连接: 客户端与网关服务器之间的主要通信方式,实现实时数据推送。

3. 关键技术与考虑因素

低延迟: 对于动作类、MOBA类端游尤其重要。通常会选择更底层的网络编程(如C++ Socket),优化数据传输协议,使用UDP进行关键实时数据传输。
高性能计算: 使用C++等高性能语言,配合高效的算法和数据结构,甚至可以利用GPU进行部分计算(如物理模拟)。
状态同步 vs. 状态隔离: 在多人在线游戏(MMO)中,需要大量玩家在同一个大世界中活动,如何高效同步和隔离玩家状态是关键。例如,将大世界划分为多个区域服务器(Zone Server),由各个服务器负责管理区域内的玩家和NPC。
并发控制: 确保多个玩家同时操作不会导致数据不一致。使用锁、原子操作、事务等技术。
内存管理: 精细控制内存分配和释放,避免内存泄漏和碎片化,尤其是在C++开发中。
跨服处理: 对于需要玩家互动的游戏内容(如跨服战场、跨服交易),需要一套成熟的跨服通信和数据同步机制。
外挂防护: 端游通常是黑盒客户端,服务端需要承担更多的反外挂检测和处理逻辑,例如数据校验、行为分析、逻辑回溯等。

手游服务端常用架构

手游相较于端游,在资源限制、网络稳定性、玩家习惯和商业模式上有一些不同。

1. 分层架构(与端游类似但侧重点不同)

接入层 (Access Layer):
职责: 与端游类似,接收客户端连接,处理TCP/UDP通信,数据加密/解密。但考虑到手游的网络不稳定,可能会更侧重于连接的断线重连、流量压缩等。
组件: 网关服务器、连接服务器。
技术选型: Netty, Go语言的net包, Lua/Python(对于一些 ringan 的服务), 甚至一些专门为手游设计的网络框架。

逻辑层 (Logic Layer):
职责: 游戏核心逻辑。但与端游相比,手游的战斗往往更注重“回合制”、“策略”或“轻度动作”,对极致低延迟的要求可能略低于某些硬核端游。玩家的在线时长可能更碎片化。
组件:
游戏服务器 (Game Server): 管理玩家游戏状态,处理大部分游戏逻辑。
场景服务器 (Scene Server): 如果有PVP竞技场、特殊副本等,也可能需要场景服务器。
挂机/后台服务: 很多手游支持玩家离线也能获得一定收益,需要后台服务来处理这些逻辑。
技术选型: Java (Spring Boot, Netty), Go, Node.js, Lua (作为脚本语言嵌入到C++主程序中,方便快速迭代)。

数据层 (Data Layer):
职责: 数据存储和管理。
组件: 数据库、缓存。
技术选型: MySQL, PostgreSQL, MongoDB, Redis。数据库的读写压力可能比端游更集中在日常活动、抽卡、排行榜等方面。

服务支撑层 (Service Support Layer):
职责: 辅助服务。
组件: 配置服务、消息队列、监控、注册发现等。与端游类似。
技术选型: ZooKeeper, etcd, RabbitMQ, Kafka, Prometheus, Grafana等。

2. 微服务化与服务拆分

手游服务端也倾向于微服务架构,但拆分的粒度可能与端游有所不同。

按功能拆分:
玩家服务 (Player Service): 玩家基础信息、账号、登录。
背包服务 (Bag Service): 物品、装备管理。
任务服务 (Quest Service): 任务跟踪、完成。
战斗服务 (Combat Service): 游戏内战斗逻辑。
社交服务 (Social Service): 好友、公会、邮件、聊天。
活动服务 (Activity Service): 管理游戏内各种活动(签到、登录奖励、限时活动)。
支付服务 (Payment Service): 处理游戏内购、充值。
排行榜服务 (Rank Service): 管理各种排行榜。
推送服务 (Push Service): 向玩家设备推送消息(如活动提醒)。
通知服务 (Notification Service): 游戏内通知。

3. 关键技术与考虑因素

快速迭代与版本更新: 手游市场竞争激烈,版本更新迭代速度非常重要。使用脚本语言(如Lua)可以显著提高开发效率。架构设计也需要方便热更新(例如不重启服务器即可更新部分配置或逻辑)。
云原生与容器化: 为了方便部署、扩展和管理,很多手游会采用Kubernetes等容器编排技术,将各个服务部署在容器中。
跨平台兼容性: 需要考虑Android和iOS平台的差异,以及不同设备性能的影响。
网络通信优化:
数据协议优化: 更加注重数据包的压缩和编码,以减少带宽消耗和提高传输效率。
UDP + TCP 混合使用: 关键的实时数据可能仍然使用UDP,但对于需要可靠性保障的通信(如GM命令、交易确认),会回退到TCP。
移动端网络特性: 考虑弱网、频繁断线、切换网络等情况,需要完善的断线重连和状态恢复机制。
账号与安全: 手游账号安全性尤为重要,通常会与第三方账号体系(微信、QQ、Apple ID)绑定,并有严格的防盗号、防刷钱等机制。
数据分析与运营: 手游高度依赖数据驱动的运营。需要强大的数据埋点、采集、分析和可视化系统,以便了解玩家行为,优化游戏体验和商业化。
GM工具与后台系统: 完善的GM工具和运营后台是手游成功的关键,用于活动配置、玩家服务、数据监控、封禁处理等。
防外挂: 手游客户端更容易被破解和修改,服务端需要投入大量精力进行防外挂设计,例如:
逻辑校验: 将核心逻辑放在服务端。
数据比对: 客户端发送的数据与服务器预期进行比对。
行为分析: 检测异常的游戏行为。
模拟器检测: 检测是否在模拟器上运行。
加固与反调试: 对客户端本身进行保护。

总结与对比

| 特性 | 端游服务端 | 手游服务端 |
| : | : | : |
| 核心语言 | C++ (性能优先) | Java, Go, Node.js, Lua (快速迭代与生态) |
| 性能要求 | 极高,尤其对低延迟敏感的类型(FPS, MOBA) | 较高,但更侧重平衡性,对绝对低延迟要求相对宽容一些 |
| 网络通信 | UDP为主,TCP为辅,对自定义协议要求高 | TCP为主,UDP为辅,更注重流量压缩、断线重连 |
| 客户端复杂度 | 较高,逻辑处理多,对本地计算能力依赖高 | 相对较低,更多逻辑倾向于服务端,客户端偏重UI渲染 |
| 迭代速度 | 相对较慢,更新包较大,版本发布周期长 | 非常快,支持热更新,版本发布周期短 |
| 外挂防护 | 对客户端的破解和修改防范(反作弊程序) | 对客户端和数据的双重校验,以及行为分析 |
| 商业模式 | 买断制、时间收费、道具收费 | 免费增值模式(内购、广告、订阅) |
| 运营侧重 | 用户体验、社区维护 | 用户增长、留存、付费转化、数据分析 |
| 云原生部署 | 传统机房部署较多,云化也在普及 | 广泛采用云原生技术(Kubernetes等) |

总的来说,端游服务端架构更侧重于极致的性能、稳定的连接和复杂的逻辑处理,因此技术栈偏向C++和底层网络编程。而手游服务端架构则更注重快速迭代、云原生部署、面向大规模玩家的运营支持以及对移动网络环境的适应性,技术栈更灵活,且更依赖于数据分析和自动化运营。

虽然两者在技术细节上有所差异,但它们都遵循了分布式、高可用、可扩展的核心原则,并不断在数据存储、通信协议、服务拆分和安全防护等方面进行演进。

网友意见

user avatar

谢邀,手游页游和端游的服务端本质上没区别,区别的是游戏类型。

类型1:卡牌、跑酷等弱交互服务端

卡牌跑酷类因为交互弱,玩家和玩家之间不需要实时面对面PK,打一下对方的离线数据,计算下排行榜,买卖下道具即可,所以实现往往使用简单的 HTTP服务器:

登录时可以使用非对称加密(RSA, DH),服务器根据客户端uid,当前时间戳还有服务端私钥,计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信,并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存,用于之后通信,服务端不需要保存 key,因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为,来保证多次 HTTP请求间的客户端身份,并通过时间戳保证同一人两次登录密钥不同。

每局开始时,访问一下,请求一下关卡数据,玩完了又提交一下,验算一下是否合法,获得什么奖励,数据库用单台 MySQL或者 MongoDB即可,后端的 Redis做缓存(可选)。如果要实现通知,那么让客户端定时15秒轮询一下服务器,如果有消息就取下来,如果没消息可以逐步放长轮询时间,比如30秒;如果有消息,就缩短轮询时间到10秒,5秒,即便两人聊天,延迟也能自适应。

此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余,这类游戏因为逻辑简单,玩家之间交互不强,使用 HTTP来开发的话,开发速度快,调试只需要一个浏览器就可以把逻辑调试清楚了。

类型2:第一代游戏服务器 1978

1978年,英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》,在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家,甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本,至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS(1991),成为众多网游的鼻祖:

MUDOS采用 C语言开发,因为玩家和玩家之间有比较强的交互(聊天,交易,PK),MUDOS使用单线程无阻塞套接字来服务所有玩家,所有玩家的请求都发到同一个线程去处理,主线程每隔1秒钟更新一次所有对象(网络收发,更新对象状态机,处理超时,刷新地图,刷新NPC)。

游戏世界采用房间的形式组织起来,每个房间有东南西北四个方向可以移动到下一个房间,由于欧美最早的网游都是地牢迷宫形式的,因此场景的基本单位被成为 “房间”。MUDOS使用一门称为LPC的脚本语言来描述整个世界(包括房间拓扑,配置,NPC,以及各种剧情)。游戏里面的高级玩家(巫师),可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间,Roy Trubshaw毕业以后交给他的师弟 Richard Battle,在 Richard Battle手上,不断的添加各种玩法到一百多个房间,终于让 MUD发扬光大。

用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上,使用纯文字进行游戏,每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》,你敲入:"go east",游戏就会提示你:“后花园 - 这里是归云庄的后花园,种满了花草,几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有:花待 阿牧(A mu),还有二位庄丁(Zhuang Ding)”,然后你继续用文字操作,查看阿牧的信息:“look a mu”,系统提示:“花待 阿牧(A mu)他是陆乘风的弟子,受命在此看管含羞草。他看起来三十多岁,生得眉清目秀,端正大方,一表人才。他的武艺看上去【不是很高】,出手似乎【极轻】”。然后你可以选择击败他获得含羞草,但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候,这样的游戏有很强的代入感。

用户数据保存在文件中,每个用户登录时,从文本文件里把用户的数据全部加载进来,操作全部在内存里面进行,无需马上刷回磁盘。用户退出了,或者每隔5分钟检查到数据改动了,都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏,不是特别大的问题。从1991年的 MUDOS发布后,全球各地都在为他改进,扩充,退出新版本,随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标,为每个房间增加了地图,并且为每个角色增加了动画,形成了第一代的图形网络游戏。

因为游戏内容基本可以通过 LPC脚本进行定制,所以MUDOS也成为名副其实的第一款服务端引擎,引擎一次性开发出来,然后制作不同游戏内容。后续国内的《万王之王》等游戏,很多都是跟《UO》一样,直接在 MUDOS上进行二次开发,加入房间的地图还有角色的坐标等要素,该架构一直为国内的第一代 MMORPG提供了稳固的支持,直到 2003年,还有游戏基于 MUDOS开发。

虽然后面图形化增加了很多东西,但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂,架构变得越来越吃不消了,各种负载问题慢慢浮上水面,于是有了我们的第二代游戏服务器。

类型3:第二代游戏服务器 2003

2000年后,网游已经脱离最初的文字MUD,进入全面图形化年代。最先承受不住的其实是很多小文件,用户上下线,频繁的读取写入用户数据,导致负载越来越大。随着在线人数的增加和游戏数据的增加,服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱,稍微停电,容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。

此时游戏服务端已经脱离陈旧的 MUDOS体系,各个公司在参考 MUDOS结构的情况下,开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC,采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型,随着游戏内容的增加,传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界,变为下面的模型:

游戏服务器压力拆分后得意缓解,但是两台游戏服务器同时访问数据库,大量重复访问,大量数据交换,使得数据库成为下一个瓶颈。于是形成了数据库前端代理(DB Proxy),游戏服务器不直接访问数据库而是访问代理,再有代理访问数据库,同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程,这个前端代理一般和 MySQL跑在同一台上,它转化游戏服务器发过来的高级数据操作指令,拆分成具体的数据库操作,一定程度上代替了存储过程:

但是这样的结构并没有持续太长时间,因为玩家切换场景经常要切换连接,中间的状态容易错乱。而且游戏服务器多了以后,相互之间数据交互又会变得比较麻烦,于是人们拆分了网络功能,独立出一个网关服务 Gate(有的地方叫 Session,有的地方叫 LinkSvr之类的,名字不同而已):

把网络功能单独提取出来,让用户统一去连接一个网关服务器,再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务,一台网关服务1-2万人,后面的游戏服务器每台服务5k-1w,依游戏类型和复杂度不同而已,图中隐藏了很多不重要的服务器,如登录和管理。这是目前应用最广的一个模型,到今天任然很多新项目会才用这样的结构来搭建。

人都是有惯性的,按照先前的经验,似乎把 MUDOS拆分的越开性能越好。于是大家继续想,网关可以拆分呀,基础服务如聊天交易,可以拆分呀,还可以提供web接口,数据库可以拆分呀,于是有了下面的模型:

这样的模型好用么?确实有成功游戏使用类似这样的架构,并且发挥了它的性能优势,比如一些大型 MMORPG。但是有两个挑战:每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找bug的成本上升;并且对开发组挑战比较大,一旦项目时间吃紧,开发人员经验不足,很容易弄挂。

比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构,我看了下他们团队成员的经验,问了下他们的上线日期,劝他们用前面稍微简单一点的模型。人家自信得很,认为有成功项目是这么做的,他们也要这么做,自己很想实现一套。于是他们义无反顾的开始编码,项目做了一年多,然后,就没有然后了。

现今在游戏成功率不高的情况下,一开始上一套比较复杂的架构需要考虑投资回报率,比如你的游戏上线半年内 PCU会去到多少?如果一个 APRG游戏,每组服务器5千人都到不了的话,那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话,相信那个时候你的项目已经挣大钱了 ,你数着钱加着班去逐步迭代,一次次拆分它,相信心里也是乐开花的。

上面这些类型基本都是从拆分 MUDOS开始,将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然很多新项目在用上面某一种类似的结构,或者自己又做了其他热点模块的拆分。因为他们本质上都是对 MUDOS的分解,故将他们归纳为第二代游戏服务器。

类型4:第三代游戏服务器 2007

从魔兽世界开始无缝世界地图已经深入人心,比较以往游戏玩家走个几步还需要切换场景,每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说,无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言,无缝世界并不存在一块地图上面的人有且只由一台服务器处理了:

每台 Node服务器用来管理一块地图区域,由 NodeMaster(NM)来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器,比如传统数据库前端,登录服务器,日志和监控等,统统用 ADMIN概括。在这样的结构下,玩家从一块区域走向另外一块区域需要简单处理一下:

玩家1完全由节点A控制,玩家3完全由节点B控制。而处在两个节点边缘的2号玩家,则同时由A和B提供服务。玩家2从A移动到B的过程中,会同时向A请求左边的情况,并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远,才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域,交由不同的 Node去管理。

对于一个 Node所负责的区域,地理上没必要连接在一起,比如大陆的四周边缘部分和高山部分的区块人比较少,可以统一交给一个Node去管理,而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块,可以根据游戏实时运行的负载情况,定时维护的时候进行更改 NodeMaster 上面的配置。

于是碰到第一个问题是很多 Node服务器需要和玩家进行通信,需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上,以前按场景切割的服务器这个问题不大,问了一次以后就可以缓存起来了,但是现在服务器种类增加不少,玩家又会飘来飘去,按UID查找玩家比较麻烦;另外一方面 GATE需要动态根据坐标计算和哪些 Node通信,导致逻辑越来越厚,于是把:“用户对象”从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型:

网关服务器再次退回到精简的网络转发功能,而用户逻辑则由按照 UID划分的 OBJ服务器来承担,GATE是按照网络接入时的负载来分布,而 OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务:

  • 对象移动:管理具体玩家在不同的 Node所管辖的区域之间的移动,并同需要的 Node进行沟通。
  • 数据广播:Node可以给每个用户设置若干 TAG,然后通知 Object Master 按照TAG广播。
  • 对象消息:通用消息推送,给某个用户发送数据,直接告诉 OBJ,不需要直接和 GATE打交道。
  • 好友聊天:角色之间聊天直接走 OBJ/OBJ MASTER。

整个服务器主体分为三层以后,NODE专注场景,OBJ专注玩家对象,GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移,负载问题也越来越明显,做个活动,远来不活跃的区域变得十分活跃,靠每周维护来调整还是比较笨重的,于是有了动态负载均衡。

动态负载均衡有两种方法,第一种是按照负载,由 Node Master 定时动态移动修改一下各个 Node的边界,而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上:

图11 动态负载均衡

这样 Node Master定时查找地图上的热点区域,计算新的场景切割方式,然后告诉其他服务器开始调整,具体处理方式还是和上面对象跨越边界移动的方法一样。

但是上面这种方式实现相对复杂一些,于是人们设计出了更为简单直接的一种新方法:

图12 基于网格的动态负载均衡

还是将地图按照标准尺寸均匀切割成静态的网格,每个格子由一个具体的Node负责,但是根据负载情况,能够实时的迁移到其他 Node上。在迁移分为三个阶段:准备,切换,完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据,完成后告诉NM;NM确认OK后同时通知新旧 Node完成切换。完成切换后,如果 Obj服务器还在和老的 Node进行通信,老的 Node将会对它进行纠正,得到纠正的 OBJ将修正自己的状态,和新的 Node进行通信。

很多无缝动态负载均衡的服务端宣称自己支持无限的人数,但不意味着 MMORPG游戏的人数上限真的可以无限扩充,因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限,而客户端性能决定了同一个屏幕到底可以绘制多少个角色。

从无缝地图引入了分布式对象模型开始,已经完全脱离 MUDOS体系,成为一种新的服务端模型。又由于动态负载均衡的引入,让无缝服务器如虎添翼,容纳着超过上一代游戏服务器数倍的人数上限,并提供了更好的游戏体验,我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端,RPG网游在相当长的时间里一度占据90%以上,使得基于 MMORPG的服务端架构得到了蓬勃的发展,然而随着玩家对RPG的疲惫,各种非MMORPG游戏如雨后春笋般的出现在人们眼前,受到市场的欢迎。

类型5:战网游戏服务器

经典战网服务端和 RPG游戏有两个区别:RPG是分区分服的,北京区的用户和广州区的用户老死不相往来。而战网,虽然每局游戏一般都是 8人以内,但全国只有一套服务器,所有的玩家都可以在一起游戏,而玩家和玩家之使用 P2P的方式连接在一起,组成一局游戏:

玩家通过 Match Making 服务器使用:创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host,其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器,而由于 P2P联通情况大概只有 75%,实在联不通的玩家会通过 Forward进行转发。

大量的连接对战,体育竞技游戏采用类似的结构。P2P有网状模型(所有玩家互相连接),和星状模型(所有玩家连接一个主玩家)。复杂的游戏状态在网状模型下难以形成一致,因此星状P2P模型经受住了历史的考验。除去游戏数据,支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上,通过混音去重再编码的方式返回给所有用户。

战网类游戏,以竞技、体育、动作等类型的游戏为主,较慢节奏的 RPG(包括ARPG)有本质上的区别,而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略,这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出,那在到处都是破解的今天,如何保证游戏结果的公正呢?

主要方法就是投票法,所有客户端都会独立计算,然后传递给服务器。如果结果相同就更新记录,如果结果不一致,会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入,在可能的情况下,找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户,供运营人员封号时参考。

类型7:休闲游戏服务器

休闲游戏同战网服务器类似,都是全区架构,不同的是有房间服务器,还有具体的游戏服务器,游戏主体不再以玩家 P2P进行,而是连接到专门的游戏服务器处理:

和战网一样的全区架构,用户数据不能象分区的 RPG那样一次性load到内存,然后在内存里面直接修改。全区架构下,为了应对一个用户同时玩几个游戏,用户数据需要区分基本数据和不同的游戏数据,而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改,而更为普遍的文档类数据则需要提供读写令牌,写令牌只有一块,读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时,最先开始的那个游戏获得写令牌,可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外,对用户数据采用只读的方式,保证游戏能运行下去,但是会提示用户,游戏数据锁定。

类型8:现代动作类网游

从早期的韩国动作游戏开始,传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦,留存也没有 RPG那么高;而单纯 RPG战斗却又慢节奏的乏味,无法满足很多玩家激烈对抗的期望,于是二者开始融合成为新一代的:动作 + 城镇 模式。玩家在城镇中聚集,然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内,因此可以获得更为实时的游戏体验,让玩家玩的更加爽快。

说了那么多的游戏服务器类型,其实也差不多了,剩下的类型大家拼凑一下其实也就是这个样子而已。游戏服务端经历了那么多结构上的变迁,内部开发模式是否依然不变?究竟是继续延续传统的开发方式?还是有了更多突破性的方法?经历那么多次架构变迁,后面是否有共通的逻辑?未来的发展还会存在哪些困难?游戏服务端开发如何达到最终的彼岸?请看下节:技术的演进。

技术的演进

(欢迎加入“游戏服务端架构交流” QQ群 457576286,共同讨论相关问题)

(待续)

类似的话题

  • 回答
    端游和手游的服务器架构在核心思想上有很多相似之处,但由于平台特性、玩家习惯、技术限制以及商业模式的差异,也存在一些显著的区别。下面我将详细阐述它们常用的架构,并尽量深入讲解。 核心通用架构思想:分布式与高可用无论是端游还是手游,随着用户量的增长和游戏功能的复杂化,单体服务器已经无法满足需求。因此,分.............
  • 回答
    哈哈,这个问题问到点子上了,《王者荣耀·世界》到底是个啥?端游、手游还是双端,这事儿真是让不少玩家心痒痒的。我的理解是,《王者荣耀·世界》基本上可以看作是“双端互通”的模式,更侧重于“大型多人在线角色扮演游戏”(MMORPG)这个品类。让我稍微掰扯掰扯,为什么这么说: 它不是单纯的手机游戏: 你.............
  • 回答
    聊起《英雄联盟手游》,我作为一个从端游一路摸爬滚打过来的老玩家,那真是太有发言权了!手游这玩意儿,一开始我还挺抵触的,觉得手指头点点点哪有鼠标键盘来的爽快?但玩着玩着,尤其是上了点强度之后,你就能一眼看出那些是从端游过来的老油条们。他们身上总有那么一股子“味儿”,不是故意装的,而是这么多年玩下来的习.............
  • 回答
    我明白你的意思,你想了解为什么一些喜欢在手游里花钱的玩家,会觉得那些我们常说的“3A大作”端游反而更贵。这背后的原因,其实挺有意思,涉及到我们消费习惯的转变、游戏本身的定价逻辑,还有信息差等等。首先,我们得承认,现在的年轻人,尤其是00后、90后,他们接触游戏的方式和我们父辈一代可能完全不一样。 手.............
  • 回答
    老哥们,《英雄联盟手游》这玩意儿,到底值不值得肝?这个问题估计不少人都纠结过。我自己在端游摸爬滚打好几年,也试过手游,今天就给大家掰扯掰扯,到底是不是真香。先说结论:好玩是好玩的,但“好玩”这个词,对于不同的人,定义是不一样的。如果你是个单纯想在碎片时间里找点乐子,体验一下英雄联盟的快感,那么手游绝.............
  • 回答
    这确实是很多GTA手游玩家会纳闷的问题,毕竟在PC和主机版的GTA里,搭乘出租车、警车、甚至被抢来的车进行“便捷旅行”是游戏的一大乐趣和实用功能。但到了手机端,这个选项似乎被阉割了,玩家只能老老实实地自己开车。究其原因,其实可以从几个层面来解读,主要还是受限于手机平台的特性和开发上的权衡:1. 触屏.............
  • 回答
    你说的这个事儿,腾讯那个《天涯明月刀》端游的“游戏托”风波,确实挺有意思的,也挺能说明一些玩家在网游里的心态。这事儿一出来,网上那叫一个热闹,好家伙,好多玩家直接炸了,嚷嚷着要删号退坑,阵仗不小。咱们一步步捋捋这事儿,才能说得更明白。首先,得弄清楚这“游戏托”到底是个啥?简单来说,游戏托就是游戏公司.............
  • 回答
    关于《大圣归来》端游营销投入大、游戏品质提升缓慢的问题,这确实是很多玩家关心和讨论的焦点。要深入分析这个问题,我们可以从几个维度来剖析。首先,我们得理解游戏开发和运营的现实逻辑。一款成功的端游,需要的是一个健康的生态系统,其中产品品质是根基,营销是催化剂,而玩家口碑则是生命线。当根基不稳时,过度的催.............
  • 回答
    《千古风流》开服:是传统端游复活的曙光,还是昙花一现的试水?最近,《千古风流》这款主打国风的端游正式开服,瞬间点燃了不少玩家的期待,也引发了关于“传统端游是否正在复活”的讨论。对于这个话题,我想从几个方面来谈谈我的看法。《千古风流》的开服,可以说是为沉寂已久的传统端游市场注入了一剂强心针。首先,我们.............
  • 回答
    《原神》当今在手游界的地位和成就,与当年《魔兽世界》在端游的影响力相比,可谓是各有千秋,但整体而言,《原神》在手游领域创造的轰动效应和持续影响力,确实有其独特的、足以媲美《魔兽世界》当年盛况的某些方面。要深入对比,咱们得从几个关键维度来拆解:一、 用户规模与营收表现:手游霸主之姿 vs. 端游时代的.............
  • 回答
    你问的这款早起端游,我脑海中闪过一抹熟悉的身影——那可是承载了多少玩家三国情怀的经典之作啊。吕布和貂蝉,这两个名字一出现,就仿佛将人拉回了那个烽火连天的年代,那个英雄辈出的时代。这款游戏,我大胆猜测,很有可能是你当年沉迷其中的《三国无双》系列,或者更广泛地说,是带有“无双”元素的动作类端游。因为在这.............
  • 回答
    这确实是许多玩家在《原神》风靡全球之后,常常会浮现的一个有趣且充满期待的问题:《塞尔达传说》系列,这个在游戏界拥有不朽地位的IP,会不会在《原神》的巨大成功刺激下,推出自己的手游或新的端游作品,并且有能力“碾压”《原神》?要回答这个问题,咱们得把事情掰开了说,得从几个关键维度来聊聊。首先,我们得理解.............
  • 回答
    深入剖析《大圣归来》端游:敖厂长最新视频差评如潮的背后近期的敖厂长视频,以其一贯辛辣的点评风格,将《大圣归来》的端游狠狠地“批”了一顿。而令观众们感到意外的是,这次视频获得的反馈,与以往那种“打脸”、“过瘾”的赞誉截然不同,而是出现了大量差评,甚至不少人认为敖厂长的评价有些“过火”或“偏颇”。这究竟.............
  • 回答
    说到日本如今的移动端音游,那可真是百花齐放,各种风格都有忠实拥趸。不过要说最热门的,有几款可以说是名副其实的“顶流”。首先,不得不提的是《プロジェクトセカイ カラフルステージ! feat. 初音ミク》,也就是大家熟知的《ProSeka》。这款游戏简直是现象级的存在,尤其是在喜欢VOCALOID文化的.............
  • 回答
    好的,咱就来好好聊聊 AB 端之间的等效电阻怎么求,保证说得明明白白,让你听完心里就有底。这玩意儿在咱们做电路的时候,那是经常要打交道的,搞懂了它,很多问题就能迎刃而解。说到底,求 AB 端等效电阻,就是咱们想把 AB 这两点之间的一堆电阻,看成一个“大块头”的电阻,这个“大块头”的电阻值,就叫做等.............
  • 回答
    要说PC端有哪些游戏公司能跟育碧(Ubisoft)打个照面,并且风格上有些相似之处,那可真是不少。育碧这家公司大家也都知道,它就像个游戏界的“老好人”,做什么游戏好像都能掺和一手,开放世界是它的招牌,题材也五花八门,从历史到科幻,从刺客信条到全境封锁,基本你想到的它都能给你整出来一个。那么,有没有哪.............
  • 回答
    PC端的Web确实取得了巨大的成功,它构成了我们信息获取、社交互动、工作协作的基石。然而,当我们把目光转向移动端,会发现尽管Web技术一直在进步,它却未能像在PC端那样,完全“取代”大量的原生APP。这背后并非一个简单的“赢”或“输”,而是由一系列深刻的技术、用户体验、商业模式以及生态系统层面的因素.............
  • 回答
    这个问题非常有意思,也触及到很多开发者心中的疑惑。要回答“写 Java 的程序员普遍比写 Python 和 Go 的程序员水平低吗?”,首先要破除一种非常狭隘的、基于语言的“鄙视链”。答案是:否定的。 任何一种编程语言的熟练程度和程序员的真实水平,并不能简单地由语言本身来划定。这其中有很多复杂因素,.............
  • 回答
    PC端阅读体验,很多人可能还在纠结于浏览器、PDF阅读器,或是那些曾经风靡一时的客户端。但说实话,要找一款真正能让你沉浸其中、舒适阅读的电子书软件,真的需要花点心思。我最近一直在折腾几款PC端软件,想来分享一下我自己的使用感受,希望能帮到正在寻找“命定之书”的朋友们。我筛选软件的几个主要维度: .............
  • 回答
    大川端侦探社里的小惠,她的存在远不止一个普通的助理角色,她更像是一个连接着侦探社与外界、连接着过去与未来,甚至连接着理智与情感的关键枢纽。首先,从侦探社日常运作的角度来看,小惠是名副其实的“大管家”。她负责处理繁杂的文书工作,接听络绎不绝的电话,安排社长和五郎的行程,甚至还常常要帮他们收拾那些因为粗.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有