手机网页游戏的服务器和客户端游戏的服务器本质上没有区别。 区别在于游戏类型。
第一类：卡牌、跑酷等弱交互服务器
由于卡牌跑酷类型的互动性较弱，玩家不需要实时面对面PK。 他们只需要查看对方的线下数据，计算排名，买卖道具即可。 因此，常常使用一个简单的HTTP服务器来实现：
手机网页游戏服务器端与客户端游戏的架构及区别
登录时可以使用非对称加密（RSA、DH）。服务器根据客户端uid、当前时间戳和服务器公钥计算哈希加密密钥并发送给客户端。 之后，双方使用 HTTP 进行通信，并使用该密钥进行 RC4 加密。 客户端收到密钥和时间戳后，将其保存在显存中以供以后通信。 服务器不需要保存密钥，因为可以根据客户端传递的uid和时间戳以及服务器自己的公钥来估计每次。 使用模仿TLS的行为来确保多次HTTP请求之间客户端的身份，并使用时间戳来确保同一个人使用不同的密钥登录两次。
在每场游戏开始时，访问并请求关卡数据。 玩完后再次提交，查看是否合法以及获得了哪些奖励。 数据库可以是单个MySQL或MongoDB，后端Redis用于缓存（可选）。 如果要实现通知，那么让客户端调度一个15秒的协程到服务器。 如果有消息，请将其删除。 如果没有消息，可以逐渐增加协程时间，比如30秒； 如果有消息，则缩短协程时间。 10秒、5秒，即使两个人在聊天，延迟也能自适应。
这种类型的服务器，实现一个三国策略或者卡牌、酷跑游戏绰绰有余。 此类游戏逻辑简单，玩家互动性弱。 如果使用HTTP开发，开发速度快，调试只需要浏览器就可以调试清楚逻辑。
类型 2：第一代游戏服务器 1978 年
1978年，英国著名金融学院埃塞克斯大学的中学生Roy Trubshaw编写了世界上第一个MUD程序“MUD1”。 1980年埃塞克斯大学接入阿帕网后，包括美国在内的许多外部参与者也加入其中。 玩家。 “MUD1”程序的源代码在阿帕网上共享后，出现了许多改编版本。 直到那时，MUD才在全球范围内广泛流行。 在不断建立的MUD1的基础上，形成了开源的MudOS（1991），成为众多网络游戏的鼻祖：
手机网页游戏服务器端与客户端游戏的架构及区别
MUDOS是用C语言开发的。 由于玩家之间存在比较强的交互（聊天、交易、PK），MUDOS使用单线程非阻塞套接字为所有玩家服务，所有玩家请求都发送到同一个线程。 处理，主线程每1秒更新所有对象（网络发送和接收、更新对象状态机、处理超时、刷新地图、刷新NPC）。
游戏世界以卧室的形式组织。 每个卧室有东南、西北四个方向，并且可以与下一个卧室相连。 由于欧美最早的网络游戏都是地下城迷宫，所以场景的基本单位被称为“房间”。 MUDOS使用一种称为LPC的脚本语言来描述整个世界（包括卧室拓扑、配置、NPC和各种情节）。 游戏中的中级玩家（巫师）可以不断地在游戏中添加卧室，通过改变脚本来减少剧情。 早年，MUD1推出时只有17间卧室。 罗伊·特鲁布肖毕业后，将其交给了他的师兄理查德·巴特尔。 在理查德·巴特尔的手中，各种游戏方式被不断地添加到100多个卧室中，MUD终于蓬勃发展。
用户使用Telnet等客户端通过Tcp协议连接到MUDOS，使用纯文本进行游戏，并使用回车符分隔每条指令。 比如1995年，国外第一款MUD游戏《侠客行》，你输入：“向东走”，游戏也会提示你：“侯家园——这是桂云村的侯家园，种满了花花草草，有好几棵树。庄丁正在浇水。这里是猪笼草生长的地方。这里唯一的出口是北面。这里是：一亩，两个庄丁。” 然后你继续使用文字操作查看阿木的信息：“看阿木”，系统提示：“阿木（阿木）是陆乘风的弟子，奉命照顾这里的猪笼草，他看起来在三十多岁了，三十岁的时候，生得五官俊秀，正气大方，一身才华，武功看上去并不高，虽然出手很轻。 然后你可以选择打败他并获得猪笼草，但如果你吃了猪笼草，你可能会中毒而死。 在网络资源匮乏的早期，这样的游戏沉浸感很强。
用户数据存储在文件中。 当每个用户登录时，所有用户数据都会从文本文件中加载。 所有操作都在显存上进行，不需要立即闪回C盘。 如果用户退出，或者每5分钟检测到数据变化，数据就会保存到c盘。 这样的系统在当时每台服务器可以容纳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）。 游戏服务器不直接访问数据库，而是访问代理。 然后，代理访问数据库并提供视频内存级别的缓存。 早年，MySQL 4 并没有提供存储过程。 该后端代理通常与 MySQL 运行在同一平台上。 它将游戏服务器发送过来的中间数据操作指令进行转换，拆分为具体的数据库操作，在一定程度上替代了存储过程：
手游页游与客户端游戏服务器端的结构及区别
不过这样的结构并没有持续太久，因为玩家在切换场景时往往要切换连接，中间的状态很容易出现混乱。 而且，当游戏服务器太多时，相互之间的数据交互会变得比较麻烦，所以人们将网络功能进行了拆分，创建了一个单独的网段服务Gate（有的地方称为Session，有的地方称为LinkSvr等）不同的名称）：
手游页游与客户端游戏服务器端的结构及区别
单独提取网络功能，让用户统一连接到一个网段服务器，然后网段服务器将数据转发到前端游戏服务器。 游戏服务器之间的数据交换也连接到网管系统进行交换。 这类服务器基本上可以稳定地为玩家提供游戏服务。 一个网段服务10000-20000人，后续游戏服务器各服务5k-10000人。 这取决于游戏的类型和复杂性。 图中隐藏了很多。 不重要的服务器，例如登录和管理。 这是目前应用最广泛的模型，直到今天许多新项目都会采用这种结构建造。
人有惰性。 根据之前的经验，似乎MUDOS拆分得越多，性能就会越好。 于是你继续认为网关可以拆分，聊天交易等基础服务可以拆分，也可以提供Web套接字，数据库也可以拆分，于是诞生了下面的模型：
手游页游与客户端游戏服务器端的结构及区别
这个模型好用吗？ 确实有一些成功的游戏使用了这样的框架并利用了它的性能，例如一些小型MMORPG。 但存在两个挑战：每次降低服务器级别，状态机的复杂度可能会增加一倍，导致开发和bug查找成本增加； 这对开发团队来说是一个更大的挑战。 一旦项目时间紧张，开发人员经验不足，就很容易挂掉。
比如我见过上海某一线游戏公司的一款RPG就采用了这样的结构。 我查看了他们团队成员的经验，询问了他们的发布日期，并建议他们使用上面更简单的模型。 人们非常有信心，认为已经有成功的项目做到了这一点，他们也应该这样做，而且他们真的很想实现一套。 于是他们毫不犹豫地开始编码。 项目做了一年多了，然后就没有了。
如今，在游戏成功率不高的情况下，一开始构建相对复杂的架构时需要考虑投资回报率。 例如，你的游戏上线半年内，PCU 的成本是多少？ 如果每组服务器5000人无法达到APRG游戏，那么选择更接近实际情况的结构更为经济。 即使你的项目真的有5000多人，正在朝着10000人的目标跑，我相信到时候你的项目也已经赚了很多钱了。 你会数着钱，加班加点地逐步迭代，一次又一次地剥离。 我相信我的心里也充满了喜悦。
以上类型基本上都是从拆分MUDOS开始，逐步将MUDOS中的各个组件从单机拆分为分布式。 尽管如今仍然有很多新项目使用与前一个类似的结构，或者他们对其他热门模块进行了衍生。 由于它们本质上是MUDOS的分解，因此被归类为第二代游戏服务器。
类型4：第三代游戏服务器2007
无缝世界地图从魔兽世界开始就深入人心。 与往年相比，游戏玩家仍然需要切换场景来走几步。 每次切换都要等待数十秒的LOADING，非常损害游戏体验。 所以对于2005年以后的小型MMORPG来说，无缝地图已经成为标准配置。 与往年按地图划分游戏相比文字手游网游源码搭建，无缝世界没有一张有人的地图，仅由一台服务器处理：
手机网页游戏服务器端与客户端游戏的架构及区别
每个Node服务器用于管理一个地图区域，NodeMaster（NM）对其进行整体管理。 上级World提供台湾级别的管理服务。 这里省略了一些详细的服务器，比如传统的数据库后端、登录服务器、日志和监控等，都是ADMIN总结的。 在这样的结构下，玩家从一个区域移动到另一个区域时只需要简单处理：
手机网页游戏服务器端与客户端游戏的架构及区别
玩家1完全由节点A控制，玩家3完全由节点B控制。位于两个节点边缘的玩家2同时由A和B服务。 在A连接到B的过程中，玩家2会同时向A请求左侧信息，向B请求左侧信息。但此时玩家2仍然属于A的管理。 直到玩家2完全远离AB的边界后，才完全交给B管理。 按照这个逻辑，世界地图被划分为多个区域，并由不同的节点进行管理。
对于一个Node所负责的区域来说，没有必要将它们在地理上连接在一起。 例如，台湾周边地区和山区，人口相对较少，可以由一个Node集中管理。 这些街区在地理上是无法区分的。 无需将它们链接在一起。 节点管理的区块可以根据游戏的实时负载情况和定期维护期间进行修改。 NodeMaster上的配置可以修改。
所以我看到的第一个问题是许多 Node 服务器需要与玩家通信。 我需要询问管理服务器具有特定 UID 的玩家位于哪个 Gate。 以前服务器是按照场景来划分的。 这不是什么大问题。 问了一次就解决了。 可以缓存，不过现在服务器种类减少很多，玩家会飘来飘去。 通过UID查找玩家比较麻烦； 另一方面，GATE需要根据坐标动态估计将与哪个Node通信，导致逻辑越来越厚。 所以势在必行地从GATE中切掉负责连接管理的“用户对象”，于是我们就有了如下的模型：
手机网页游戏服务器端与客户端游戏的架构及区别
网关服务器再次回归精简的网络转发功能，用户逻辑由基于UID定义的OBJ服务器处理。 GATE是根据网络访问时的负载来分配的，而OBJ是根据资源编号（UID）来分配的。 进行分发，这样在与用户通信时，可以直接根据UID估计出OBJ服务器编号并发送数据。 新独立的OBJ提供更多高水平的服务：
对象连接：管理不同节点管辖区域内特定玩家之间的连接，并与所需节点进行通信。
数据广播：Node可以为每个用户设置多个TAG，然后根据TAG通知Object Master进行广播。
对象消息：一般消息推送，发送数据给某个用户，直接告诉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游戏的玩家上限真的可以无限扩展，因为这样的系统会受到网络带宽和客户端性能的限制。 带宽决定了同一区域内的最大广播限制，客户端性能决定了同一屏幕上可以绘制多少个字符。
由于Seamless Map引入了分布式对象模型，它已经完全脱离了MUDOS系统，成为一种新的服务器模型。 并且由于动态负载均衡的引入，无缝服务器如虎添翼，可容纳比上一代游戏服务器数倍的人数，提供更好的游戏体验。 我们称之为第三代游戏服务器架构。 网络游戏始于小规模多人角色扮演。 RPG网游曾长期占据90%以上的市场份额，带动了基于MMORPG的服务器端架构的蓬勃发展。 然而，随着玩家对RPG的厌倦，各种非MMORPG游戏如雨后春笋般出现在人们的眼前，并受到市场的欢迎。
类型5：战网游戏服务器
经典战网服务器和RPG游戏有两个区别：RPG是分地区的，北京和广州的用户从来没有接触过。 至于Battle.net，虽然每场游戏通常限制8人，但全省只有一台服务器，所有玩家都可以一起玩，玩家通过P2P连接在一起形成游戏：
手机网页游戏服务器端与客户端游戏的架构及区别
玩家通过配对服务器进行创建、加入、自动匹配、邀请等方式组成游戏。 服务器会选择一个人作为主持人，其他人将P2P连接到做主的玩家。 STUN是一个帮助玩家构建P2P的牵引服务器。 由于P2P的移动性只有75%左右，所以确实无法连接的玩家就会通过Forward进行转发。
大量的联网战斗和体育竞技游戏都采用了类似的结构。 P2P有网状模型（所有玩家都相互连接）和星型模型（所有玩家都连接到主玩家）。 复杂的游戏状态在网络模型下无法保持一致，因此星型P2P模型经受住了历史的考验。 除了游戏数据外，支持语音的战网系统还将把所有人的语音数据发送到玩家的发号施令的机器上，通过混合、去重、重新编码的方式返回给所有用户。
战网游戏主要是竞技、体育、动作等类型的游戏。 它们与节奏较慢的RPG（包括ARPG）有着本质的区别，激烈的游戏过程必然会导致比RPG更复杂的同步策略。 ，这样的同步机制往往会导致很多游戏结果都是由客户端直接估算的。 那么在裂痕遍地的世界里，如何才能保证比赛结果的公平性呢？
主要方式是投票方式，所有客户端都会独立估算，然后传递给服务器。 如果结果相同，则更新记录。 若结果不一致，则采用类似投票的方式确定最终结果。 同时，记录本次游戏的所有输入，如果可能的话，再找一个闲置的游戏客户端检查整个游戏是否是结果。 并记录经常涉嫌作弊的用户，以供运营商封号时参考。
类型七：休闲游戏服务器
休闲游戏类似于Battle.net服务器。 它们都是区域范围的结构。 不同的是，有卧室服务器和特定游戏服务器。 游戏的主体部分不再是玩家之间的P2P，而是连接到专用的游戏服务器进行处理：
手游页游与客户端游戏服务器端的结构及区别
和战网一样的全区结构，用户数据不能像分区RPG一样一次性加载到显存，然后直接在显存上更改。 在全区结构下，为了处理一个用户同时玩多个游戏，用户数据需要区分基础数据和不同的游戏数据，游戏数据需要区分积分数据和文档数据。 胜、平、负等积分可以直接提交进行增量更改，而更常见的文档数据需要读写令牌。 只有一个写令牌和许多读令牌。 当同一帐户和同一游戏同时在两台笔记本电脑上玩时，先启动的游戏将获得写入令牌，该令牌可以操纵任何用户数据。 之后开始的那种游戏不仅可以提交胜、平、负分的增量变化，而且对用户数据采用只读的方式，保证游戏可以继续运行，但是会提示用户游戏数据被锁定。
类型八：现代动作网游
从早期的美式动作游戏开始，传统的战网动作游戏和RPG游戏开始尝试融合。 纯动作游戏的玩家容易疲劳，留存度没有RPG高； 而纯粹的RPG战斗则节奏缓慢平庸，无法满足很多玩家对于激烈对抗的期待，于是两者开始融合为新一代：动作+城镇模式。 玩家聚集在小镇，然后几人以开副本的形式出去，以动作游戏的方式完成各种RPG任务。 本质是一套RPG服务器+副本服务器。 由于每个副本的角色可以控制在8人以内，因此可以获得更加实时的游戏体验，让玩家玩起来更加爽快。
说了这么多类型的游戏服务器，其实都差不多。 你可以把剩下的类型堆起来，虽然它们就是这样。 游戏服务器经历了如此多的结构变化，内部开发模式还是一样吗？ 是否还要继续传统的开发方式？ 还是有更多的突破方式？ 经过这么多的架构变化，背后是否有一个共同的逻辑？ 未来的发展会遇到哪些困难？ 游戏服务器开发如何到达最终目的地？
