前言

这里，我们将从香港游戏服务器发展的简单历程出发，鸟瞰一下目前大多数的香港游戏服务器架构。

这里尽可能的避免陷入细节的技术问题，而是从技术进化的结果状态，反推原始问题是什么。希望能通过这个过程，解释清楚香港游戏服务器是在解决什么问题，痛点到底在哪里。

一、早期网游服务器。

蛮荒时期的游戏服务器框架我们一笔带过，那时的游戏服务器和一个小Web服务没有区别。

蛮荒时代的服务器只负责存储玩家账号、数据、转发场景内其他玩家的行为。很多移动、使用技能等关键逻辑在服务器上根本没有。随意就能用变速齿轮改变游戏速度。

从《传奇》的时代开始，游戏服务器就不再是简单的上传存档、下载存档、访问页面而已。游戏服务器内部出现了游戏逻辑，既能用于同步每个玩家看到的世界，又能让逻辑与客户端分离，避免早期的网络游戏那种毫无防范的逻辑体系（对外挂防御能力为0）。

如图，客户端通过某种形式验证登陆以后，就和服务器通过TCP直接相连了。这种服务器的承载能力不高，但那时在游戏逻辑上也务求简化，把负载减少到极致。

· 例如：1、玩家看不到怪物的血量，或者只能看到正在打的怪物的血量。2、地图有格子的概念，每个格子只能有一个单位，极大限制了同屏人数。

由于逻辑尽量简化，虽然这时的服务器逻辑服务都是单进程单线程的，但是也足够表现交互的感受。

这种架构奇怪的地方是处理网络连接数据传输的压力和逻辑处理的压力在同一个服务器上（存储模块可能也在同一个进程），就算逻辑处理压力为0，承载人数也高不到哪去。

虽然这时的游戏服务器设计很简陋，但是网游第一次给了玩家真实世界的感受。单服人数不足的问题可以靠开多组服务器实现，所以曾经出现了几百上千组服务器的辉煌时代。

二、早期游戏服务器的改进版本

当开发者们有了初步经验以后，新作品的开发，自然而然的过渡到了如下的形式：

游戏逻辑服务依然是在一台服务器上，单进程（逻辑处理本身肯定是在一个线程中，可以有子线程负责内网通信）。但是我们自然的想到，存储负载和网络连接负载可以从逻辑服上拆出来。

连接服务器负责把客户端和服务器之间的消息转化为服务器之间的消息，可以顺便做一些加解密的工作。

这一点小改动极大提高了单服连接人数的上限。但是玩家要求提高了，空出来的性能很快被丰富的游戏系统吃掉了。

由于连接服务器本身没有时序性，很容易做分布式的（其实大部分游戏还是只用一个连接服），存储服务不要求高实时性，高峰期存盘间隔可以稍长一些，不会对游戏服造成影响。

三、成熟形态的服务器框架

逻辑服务器的负载均摊方法一：按照功能划分多个服务器进程

逻辑服务器的负载均摊方法二：按照场景划分多个服务器进程

对游戏服务器历史有了基本了解后，成熟形态的游戏服务器很容易理解。简单来说，就是把逻辑服务器单个进程的压力分摊到多个服务器。

难点在逻辑的设计上，要像做手术一样把本来是一体的功能切开，并抽象出若干个API来保持联系（服务器之间是TCP连接）。

在分解时，要找联系相对最薄弱的环节入手，比如场景和场景之间分开、单独抽出聊天服务、组队服务、好友服务。

无论如何分解，最终结果只能是有限个服务。而且分解的越细，开发难度就越大。因为跨服务器逻辑是把简单的同步逻辑变成了异步Callback逻辑，而且容易出现时序问题等不易测试的问题。

单个场景服务几乎是无法分解的。分解单个场景难度巨大以至于出现了BigWorld引擎来专门的解决场景分割问题，后面会谈到。

这种成熟形态的游戏服务器已经能满足现实中99%的频繁交互类网游需求，是大型MMO端游、页游的主流形式。

当然有实力的公司在这个基础上会做很多改动，实现动态开辟副本、相位技术等等，但是万变不离其宗，其本质和上图没有什么区别。