最近参与开发了一款网页游戏，网页游戏和普通客户端游戏不同，虽然都可以称为网络游戏，从服务器角度来说，网页游戏所承载的用户量是很少的，一般一组服务器3-4000玩家同时在线。当然，技术含量也相对较低。开发周期短，一般为4-5个月。我现在就网页游戏后台开发的技术，谈谈自己的看法。首先是网关，所有玩家进入游戏，都是同网关连接，网关起着隔离游戏逻辑服务器和玩家的作用，保护游戏服务器内部不受外部玩家有意或无意的攻击。一般一个网关下面会挂上多组地图服务器，网关将用户逻辑转发到地图服务器上做具体的处理，处理完成后，地图服务器将处理结果送回网关，网关再转发给玩家。乍一看，网关似乎有可能成为性能瓶颈，确实是性能瓶颈。在网络游戏中，单个客户端上行流量是很小的，一般客户端都会做控制，在战斗和行走的时候，客户端没秒钟基本上只会有3条上行数据，但是下行广播数据是非常庞大的，曾经测试过300人同屏在线，每秒钟3个位置更新消息，广播量基本上是300*300*3=270000条消息，假如服务器为每一条消息调用一次send系统调用，那么意味着每秒钟27万次系统调用，是多么的庞大啊！一般网关前端收发消息部分毫无疑问会采用epoll的边缘出发模式（非阻塞），多线程收/多线程发。客户端发上来的消息，通过网关路由到地图服务器做具体的逻辑处理，对于地图服务器通常都是一个服务器对应一副或者多幅地图，在这个地图上玩家发生的所有事件，都有这个服务器来处理，地图服务器采用单线程/单进程这种模式，主要是保证游戏逻辑的顺序处理。评价地图服务器处理能力的一个指标是地图服务器可以支撑多少怪，多少玩家，因为怪的AI都在服务器这边做，服务器需要主动触发事件，广播给玩家，这个时候timer是不可缺少的资源，timer开得越多，系统性能也就越差了。对于数据库访问这一块，目前很多网页游戏，都使用的是和mongodb类似的内存数据库，是不是可以不采用cache，而直接访问数据库了呢？答案是错误的，根据具体情况来定吧，基本上到最后，性能瓶颈都会在数据库I/O这一块了，主要是读。