大型网络游戏服务器的框架设计

服务器是用来处理高并发的请求，同时可以知足扩展的业务逻辑的需求，最重要的是知足三点：并发性，稳定性，扩展性。

经历过两款上线游戏产品，见识到了游戏行业的杂乱无章，虽然和传统软件行业相比，少了那么些规范，可是对我的能力要求还真不比传统软件行业低。

今天开始，陆续利用业余时间将本身设计的一个服务器的框架贴出来，也会包好一些基本的代码，也会用到一些开源库。从最基础的讲起，首先看看一个实时网络游戏服务器的框架:

 

目前市面上的游戏，总的来讲分为两类：

1.弱联网类游戏，像手机上的卡牌类游戏(MT,Dota传奇等)，大部分逻辑在客户端处理，不须要实时联网，这类游戏只有一个玩家，并且只有PVE模式，就是打游戏中的机器人(AI)，不存在玩家与玩家的实时交互。例如一场副本打斗，只有在开始和结束，才会链接服务器，请求获取或者存储数据，打斗过程由客户端计算完成，最后将战斗结果提交服务器就好了。

 

2.强联网类游戏，典型的就是MMORPG或者MMARPG的类型的游戏，通常常见于端游或者页游，也包含手游。在一个地图中，同时有不少玩家，任何一个玩家的状态或者属性发生变化，服务器就须要实时更新游戏中角色的状态，而且通知到周围的玩家。例如在副本中，一个玩家释放技能，攻击范围，伤害计算这些逻辑都是服务器来完成的，而客户端只须要负责特效的显示，这个过程当中须要实时的数据交互。

显然，第2种，MMORPG类游戏须要服务器作更多的事情，对服务器的运算要求更高，实时性要求更高，天然实现起来更复杂。

 

一个大型的网落游戏服务器应该包含几个模块：网络通信，业务逻辑，数据存储，守护监控（不是必须），其中业务逻辑可能根据具体须要，又划分为好几个子模块。

这里说的模块能够指一个进程，或者一个线程方式存在，本质上就是一些类的封装。

 

对于服务器的并发性，要么采用单进程多线程，要么采用多进程单线程的方式，说说两种方式的优缺点：

 

1、单进程多线程的服务器设计模式，只有一个进程，但一个进程包好多个线程：

网络通信层，业务逻辑，数据存储，分别在独立的线程中，无守护进程。

优势：

1.数据共享和交换方便，使用全局变量或者单例就能够，数据存储方便。

2.单进程，服务器框架结构相对简单，编码容易。

缺点：

1.全部功能只能在单个物理服务器上，不能作成分布式。

2.不方便监控各个线程状态，容易死锁

3.一个线程出错，例如内存非法访问，栈空间被破坏，那么服务器进程就退出，全部玩家掉线，影响大。

 

2、多进程单线程的服务器设计模式，多个进程，每一个进程只有一个线程：

网路通信，业务逻辑，数据存储，守护进程，分别在不一样的进程。

优势：

1.各个进程能够分布在不一样的物理服务器上，能够作成分布式的服务器框架，例如能够将数据存储单独放到一个物理服务器上，供几个区的服务器使用。将网络通信进程独立出来，甚至能够作成导向服务器，实现跨服战。

2.能够经过守护进程监控其它进程状态，例若有进程死掉，立刻重启该进程，或者某个进程cpu使用率接近100%（基本能够判断是某个逻辑死循环了）, 强制kill掉该进程，而后重启。

3.单个服务器进程异常退出，只要不是网络通信进程（通常这个都会比较稳定，没什么逻辑），那么就能够及时被守护进程重启，不会形成玩家掉线，只会形成在1-2秒内，某个逻辑功能没法使用，甚至玩家都感受不到。

4.服务器经过共享内存进行数据交换，那么若是其中一个服务器死掉，数据还在，能够保护用户数据（固然多线程也可使用共享内存）。

5.并发性相对多线程要高点。

缺点：

1.不方便使用互斥锁，由于进程切换的时间片远远于线程切换，对于一个高并发服务器是没法容许这么高时间片的切换代价的。所以必须设计好服务器的框架，尽可能避开使用锁机制，但要保证数据不出错。

2.多进程编程，在各个进程间会有不少通信，跨服务器进程的异步消息较多，会让服务器的编码难度加大。

 

下面先按照一个游戏的功能，将服务器的功能分块框架画出来:

 

以上是一个游戏服务器最基础的功能框架图，接下来要作的就是设计服务器的框架了。