游戏服务器开发的基本体系与服务器端开发的一些建议
投稿：mdxy-dxy
字体：[ ] 类型：转载 时间：
刚开始时以为做游戏服务器和做web差不多，但是经过一段时间之后，才发现代码太多，太乱了，一看代码都想重构，都是踩着坑往前走。这里我把一些游戏开发方面的东西整理一下，希望能对那些想做游戏服务器开发的朋友有所帮助
近年来，我身边的朋友有很多都从web转向了游戏开发。他们以前都没有做过游戏服务器开发，更谈不上什么经验，而从网上找的例子或游戏方面的知识，又是那么的少，那么的零散。当他们进入游戏公司时，显得一脸茫然。如果是大公司还好点，起码有人带带，能学点经验，但是有些人是直接进入了小公司，甚至这些小公司只有他一个后台。他们一肩扛起了公司的游戏后端的研发，也扛起了公司的成败。他们也非常尽力，他们也想把游戏的后端做好。可是就是因为没什么经验，刚开始时以为做游戏服务器和做web差不多，但是经过一段时间之后，才发现代码太多，太乱了，一看代码都想重构，都是踩着坑往前走。这里我把一些游戏开发方面的东西整理一下，希望能对那些想做游戏服务器开发的朋友有所帮助。
&&&&& 首先，要明确一点，做游戏服务器开发和做传统的web开发有着本质的区别。游戏服务器开发，如果没有经验，一开始根本没有一个明确清析的目标，不像web那样，有些明确的MVC架构，往往就是为了尽快满足策划的需求，尽快的实现功能，尽快能让游戏跑起来。但是随着功能越来越多，在老代码上面修改的越来越频繁，游戏测试时暴露出来的一堆bug，更让人觉得束手无策，这个时候我们想到了重构，想到了架构的设计。
&& 游戏的构架设计非常重要，好的构架代码清析，责任明确，扩展性强，易调试。这些会为我们的开发省去不少时间。那要怎么样设计游戏的构架呢？可能每个游戏都不一样，但是本质上还是差不多的。
&& 对于游戏服务器的构架设计，我们首先要了解游戏的服务器构架都有什么组成的？一款游戏到上线，需要具备哪些功能？有些人可能会说，只要让游戏跑起来，访问服务器不出问题不就行了吗？***是不行的，游戏构架本身代表的是一个体系，它包括：
&& 1，系统初始化&&
&& 2，游戏逻辑
&& 3，数据库系统
&& 4，缓存系统。
&& 5，游戏日志
&& 6，游戏管理工具
&& 7，公共服务组件
这一系统的东西都是不可少的，它们共同服务于游戏的整个运营过程。我们一点点来介绍各个系统的功能。
一，系统初始化
&&&&& 系统初始化是在没有客户端连接的时候，服务器启动时所需要做的工作。基本上就是配置文件的读取，初始化系统参数。但是我们必须要考虑的是，系统初始化需要的参数配置在哪儿，是配置在本地服务器，还是配置在数据库，服务器启的时候去数据库取。配置的修改需不需要重启服务器等。
二，游戏逻辑
&&&&& 游戏逻辑是游戏的核心功能实现，也是整个游戏的服务中心，它被开发的好坏，直接决定了游戏服务器在运行中的性能。那在游戏逻辑的开发中我们要注意些什么呢？
&& （1）网络通信
&&&&&&& 游戏是一种网络交互比较强的业务，好的底层通信，可以最大化游戏的性能，增加单台服务器处理的同时在线人数，给游戏带来更好的体验，至少不容易出现因为网络层导致的数据交互卡顿的现象。在这里我推荐使用Netty，它是目前最流行的NIO框架，它的用法可以在我之前的文章中查看，这里不再多说了。
&&&&&&&& 有人疑问，代码也需要分层次？这个是当然了，不同的代码，代表了不同的功能实现。现在的开发语言都是面向对象的，如果我们不加思考，不加整理的把功能代码乱堆一起，起始看起来是快速实现了功能，但是到后期，如果要修改需求，或在原来的代码上增加新的需求，那真是被自己打败了。所以代码一定要分层，主要有以下几层：
&&&&& a，协议层，也叫前后台交互层，它主要负责与前台交互协议的解析和返回数据。在这一层基本上没有什么业务逻辑实现。与前台交互的数据都在这一层开始，也在这一层终止。比如你使用了Netty框架，那么Netty的ChannelHandlerContext即Ctx只能出现在这一层，他不能出现到游戏业务逻辑代码的实现中，接收到客户端的请求，在这一层把需要的参数解析出来，再把参数传到业务逻辑方法中，业务逻辑方法处理完后，把要返回给客户端的数据再返回到这一层，在这一层组织数据，返回给客户端，这样就可以把业务逻辑和网络层分离，业务逻辑只关心业务实现，而且也方便对业务逻辑进行单元测试。
&&&&&& b,业务逻辑层，这里处理真正的游戏逻辑，该计算价格计算价格，该通关的通关，该计时的计时。该保存数据的保存数据。但是这一层不直接操作缓存或数据库，只是处理游戏逻辑计算。因为业务逻辑层是整个游戏事件的处理核心，所以他的处理是否正确直接决定游戏的正确性。所以这一层的代码要尽量使用面向对角的方法去实现。不要出现重复代码或相似的功能进行复制粘贴，这样修改起来非常不方便，可能是修改了某一处，而忘记了修改另外同样的代码。还要考虑每个方法都是可测试的，一个方法的行数最好不要超过一百行。另外，可以多看看设计模式的书，它可以帮助我们设计出灵活，整洁的代码。
&三，数据库系统
&&&&& 数据库是存储数据库的核心，但是游戏数据在存储到数据库的时候会经过网络和磁盘的IO,它的访问速度相对于内存来说是很慢的。一般来说，每次访问数据库都要和数据库建立连接，访问完成之后，为了节省数据库的连接资源，要再把连接断开。这样无形中又为服务器增加了开销，在大量的数据访问时，可能会更慢，而游戏又是要求低延时的，这时该怎么办呢？我们想到了数据库连接池，即把访问数据库的连接放到一个地方管理，用完我不断开，用的时候去那拿，用完再放回去。这样不用每次都建立新的连接了。但是如果要我们自己去实现一套连接池管理组件的话，需要时间不说，对技术的把控也是一个考验，还要再经过测试等等，幸好互联网开源的今天，有一些现成的可以使用，这里推荐Mybatis，即实现了代码与SQL的分离，又有足够的SQL编写的灵活性，是一个不错的选择。
&四，缓存系统
& 游戏中，客户端与服务器的交互是要求低延迟的，延迟越低，用户体验越好。像之前说过的一样，低延迟就是要求服务器处理业务尽量的快，客户端一个请求过来，要在最短的时间内响应结果，最低不得超过500ms，因为加上来回的网络传输耗时，基本上就是600ms-到700ms了，再长玩家就会觉得游戏卡了。如果直接从数据库中取数据，处理完之后再存回数据库的话，这个性能是跟不上的。在服务器，数据在内存中处理是最快的，所以我们要把一部分常用的数据提前加载到内存中，比如说游戏数据配置表，经常登陆的玩家数据等。这样在处理业务时，就不用走数据库了，直接从内存中取就可以了，速度更快。游戏中常见的缓存有两种，1，直接把数据存储在jvm或服务器内存中，2，使用第三方的缓存工具，这里推荐Redis，详细的用法可以自己去查询。
&五，游戏日志
&&&&& 日志是个好东西呀，一个游戏中更不能少了日志，而且日志一定要记录的详细。它是玩家在整个游戏中的行为记录，有了这个记录，我们就可以分析玩家的行为，查找游戏的不足，在处理玩家在游戏中的问题时，日志也是一个良好的凭证和快速处理方式。
&&&&& 在游戏中，日志分为：1，系统日志，主要记录游戏服务器的系统情况。比如：数据库能否正常连接，服务器是否正常启动，数据是否正常加载；2，玩家行为日志，比如玩家发送了什么请求，得到了什么物品，消费了多少货币等等；3，统计日志，这种日志是对游戏中所有玩家某种行为的一种统计，根据这个统计来分析大部分玩家的行为，得出一些共性或不同之处，以方法运营做不同的活动吸引用户消费。
&&&&& 在构架设计中，日志记录一定要做为一种强制行为，因为不强制的话，可能由于某种原因某个功能忘记加日志了，那么当这个功能出问题了，或者运营跟我们要这个功能的一些数据库，就傻眼了。又得加需求，改代码了。日志一定要设计一种良好的格式，日志记录的数据要容易读取，***。日志行为可以用枚举描述，在功能最后的处理方法里面加上这个枚举做为参数，这样不管谁在调用这个方法时，都要去加参数描述。
&&&&& 俗话说，工欲善其事，必先利其器。游戏管理工具是对游戏运行中的一系列问题处理的一种工具。它不仅是给开发人员用，大多数是给运营使用。游戏上线后，我们需要针对线上的问题进行不同的处理。不可能把所有问题都让程序员去处理吧，于是程序员们想到了一个办法，给你们做一个工具，你们爱谁处理谁处理去吧。
六，&游戏管理工具
&游戏管理工具是一个不断增涨的系统，因为它很多时候是伴随着游戏中遇到的问题而实现的。但是根据经验，有一些功能是必须有的，比如：服务器管理，主要负责服务器的开启，关闭，服务器配置信息，玩家信息查询，玩家管理，比如踢人，封号；统计查询，玩家行为日志查询，统计查询，次留率查询，邮件服务，修改玩家数据等，根据游戏的不同要求，凡是可以能过工具实现的，都做到游戏管理工具里面。它是针对所有服务器的管理。一个好的，全的游戏管理工具，可以提高游戏运营中遇到问题处理的效率，为玩家提供更好的服务。
&七，公共组件
&&&&& 公共组件是为游戏运行中提供公共的服务，比如，充值服务器，我们没必须一个服用一个充值，而且你也不能对外提供多个充值服务器地址，和第三方公司对接，他们绝对不干，这是要疯呀；还有运营搞活动时的礼包码，还有注册用户的管理，玩家一个注册账号可以进不同的区等。这些都是针对所有区服提供的服务，所以要单独做，与游戏逻辑分开，这样方便管理，部署和负载均衡。还有SDK的登陆验证，现在手游比较多，与渠道对接里要进行验证，这往往是很多http请求，速度慢，所以这个也要拿出来单独做，不要在游戏逻辑中去验证，因为网络IO的访问时间是不可控制的，http是阻塞的请求。
&所以，综上来看，一个游戏服务器起码有几个大的功能模块组成：a,游戏逻辑工程；b,日志处理工程；c,充值工程；d,游戏管理工具工程；e,用户登陆工程；f,公共活动工程等，根据游戏的不同需要，可能还有其它的。所在在构架的设计中，一定要考虑到系统的分布式部署，尽量把公共的功能拆出来做，这样可以增强系统的可扩展性。
服务器端开发的一些建议
本文作为游戏服务器端开发的基本大纲，是游戏实践开发中的总结。第一部分专业基础，用于指导招聘和实习考核， 第二部分游戏入门，讲述游戏服务器端开发的基本要点，第三部分服务端架构，介绍架构设计中的一些基本原则。希望能帮到大家
一 专业基础
1.1.1 理解TCP/IP协议
网络传输模型
滑动窗口技术
建立连接的三次握手与断开连接的四次握手
连接建立与断开过程中的各种状态
TCP/IP协议的传输效率
1）请解释DOS攻击与DRDOS攻击的基本原理
2）一个100Byte数据包，精简到50Byte, 其传输效率提高了50%
3）TIMEWAIT状态怎么解释？
1.1.2 掌握常用的网络通信模型
Epoll，边缘触发与平台出发点区别与应用
Select与Epoll的区别及应用
计算机系统存储体系
程序运行时的内存结构
计算机文件系统，页表结构
内存池与对象池的实现原理，应用场景与区别
关系数据库MySQL的使用
对C/C++语言有较深的理解
深刻理解接口，封装与多态，并且有实践经验
深刻理解常用的数据结构：数组，链表，二叉树，哈希表
熟悉常用的算法及相关复杂度：冒泡排序，快速排序
二 游戏开发入门
2.1防御式编程
不要相信客户端数据，一定要检验。作为服务器端你无法确定你的客户端是谁，你也不能假定它是善意的，请做好自我保护。(这是判断一个服务器端程序员是否入门的基本标准)
务必对于函数的传人参数和返回值进行合法性判断，内部子系统，功能模块之间不要太过信任，要求低耦合，高内聚
插件式的模块设计，模块功能的健壮性应该是内建的，尽量减少模块间耦合
2.2 设计模式
道法自然。不要迷信，迷恋设计模式，更不要生搬硬套
简化，简化，再简化，用最简单的办法解决问题
借大宝一句话：设计本天成，妙手偶得之
2.3 网络模型
自造轮子: Select, Epoll， Epoll一定比Select高效吗？
开源框架: Libevent, libev, ACE
2.4 数据持久化
自定义文件存储，如《梦幻西游》
关系数据库: MySQL
NO-SQL数据库: MongoDB
选择存储系统要考虑到因素：稳定性，性能，可扩展性
2.5 内存管理
使用内存池和对象池，禁止运行期间动态分配内存
对于输入输出的指针参数，严格检查，宁滥勿缺
写内存保护。使用带内存保护的函数(strncpy, memcpy, snprintf, vsnprintf等)，严防数组下标越界
防止读内存溢出，确保字符串以'\0'结束
2.6 日志系统
简单高效，大量日志操作不应该影响程序性能
稳定，做到服务器崩溃是日志不丢失
完备，玩家关键操作一定要记日志，理想的情况是通过日志能重建任何时刻的玩家数据
开关，开发日志的要加级别开关控制
2.7 通信协议
采用PDL(Protocol Design Language)， 如Protobuf，可以同时生成前后端代码，减少前后端协议联调成本， 扩展性好
JSON，文本协议，简单，自解释，无联调成本，扩展性好，也很方便进行包过滤以及写日志
自定义二进制协议，精简，有高效的传输性能，完全可控，几乎无扩展性
2.8 全局唯一Key（GUID）
为合服做准备
方便追踪道具，装备流向
每个角色，装备，道具都应对应有全局唯一Key
2.9 多线程与同步
消息队列进行同步化处理
2.10 状态机
强化角色的状态
前置状态的检查校验
2.11 数据包操作
合并, 同一帧内的数据包进行合并，减少IO操作次数
单副本, 用一个包尽量只保存一份，减少内存复制次数
AOI同步中减少中间过程无用数据包
2.12 状态监控
随时监控服务器内部状态
内存池，对象池使用情况
帧处理时间
包处理性能
各种业务逻辑的处理次数
2.13 包频率控制
基于每个玩家每条协议的包频率控制，瘫痪变速齿轮
2.14 开关控制
每个模块都有开关，可以紧急关闭任何出问题的功能模块
2.15 反外挂反***
包频率控制可以消灭变速齿轮
包id自增校验，可以消灭WPE
包校验码可以消灭包拦截篡改
图形识别吗，可以踢掉99%非人的操作
魔高一尺，道高一丈
2.16 热更新
核心配置逻辑的热更新，如防沉迷系统，包频率控制，开关控制等
代码基本热更新，如Erlang，Lua等
关键系统资源（如元宝，精力值，道具，装备等）的产出记日志
资源的产出和消耗尽量依赖两个或以上的独立条件的检测
严格检查各项操作的前置条件
校验参数合法性
2.18 防崩溃
系统底层与具体业务逻辑无关，可以用大量的机器人压力测试暴露各种bug，确保稳定
业务逻辑建议使用脚本
系统性的保证游戏不会崩溃
2.19 性能优化
IO操作异步化
IO操作合并缓写 （事务性的提交db操作，包合并，文件日志缓写）
减少竞态条件 (避免频繁进出切换，尽量减少锁定使用，多线程不一定由于单线程) 多线程不一定比单线程快
减少内存复制
自己测试，用数据说话，别猜
2.20 运营支持
接口支持：实时查询，控制指令，数据监控，***处理等
实现考虑提供Http接口
2.21 容灾与故障预案
三 服务器端架构
3.1 什么是好的架构？
满足业务要求
能迅速的实现策划需求，响应需求变更
系统级的稳定性保障
简化开发。将复杂性控制在架构底层，降低对开发人员的技术要求，逻辑开发不依赖于开发人员本身强大的技术实力，提高开发效率
完善的运营支撑体系
3.2 架构实践的思考
简单，满足需求的架构就是好架构
设计性能，抓住重要的20%， 没必要从程序代码里面去抠性能
热更新是必须的
人难免会犯错，尽可能的用一套机制去保障逻辑的健壮性
游戏服务器的设计是一项颇有挑战性的工作，游戏服务器的发展也由以前的单服结构转变为多服机构，甚至出现了bigworld引擎的分布式解决方案，最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。
负载均衡是一个很复杂的课题，这里暂不谈bigworld和atlas的这类服务器的设计，更多的是基于功能和场景划分服务器结构。
首先说一下思路，服务器划分基于以下原则：
分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器。
在同一服务器架构下的不同游戏，应尽可能的复用某些服务器（进程级别的复用）。
以多线程并发的编程方式适应多核处理器。
宁可在服务器之间多复制数据，也要保持清晰的数据流向。
主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够的简单，并满足以上1，2点。
服务器结构图：
各个服务器的简要说明：
Gateway 是应用网关，主要用于保持和client的连接，该服务器需要2种IO，对client采用高并发连接，低吞吐量的网络模型，如IOCP等，对服务器采用高吞吐量连接，如阻塞或异步IO。
网关主要有以下用途：
分担了网络IO资源
同时，也分担了网络消息包的加解密，压缩解压等cpu密集的操作。
隔离了client和内部服务器组，对client来说，它只需要知道网关的相关信息即可（ip和port）。
client由于一直和网关保持常连接，所以切换场景服务器等操作对client来说是透明的。
维护玩家登录状态。
World Server 是一个控制中心，它负责把各种计算资源分布到各个服务器，它具有以下职责：
管理和维护多个Scene Server。
管理和维护多个功能服务器，主要是同步数据到功能服务器。
复杂转发其他服务器和Gateway之间的数据。
实现其他需要跨场景的功能，如组队，聊天，帮派等。
Phys Server 主要用于玩家移动，碰撞等检测。
所有玩家的移动类操作都在该服务器上做检查，所以该服务器本身具备所有地图的地形等相关信息。具体检查过程是这样的：首先，Worldserver收到一个移动信息，WorldServer收到后向Phys Server请求检查，Phys Server检查成功后再返回给world Server，然后world server传递给相应的Scene Server。
Scene Server 场景服务器，按场景划分，每个服务器负责的场景应该是可以配置的。理想情况下是可以动态调节的。
ItemMgr Server 物品管理服务器，负责所有物品的生产过程。在该服务器上存储一个物品掉落数据库，服务器初始化的时候载入到内存。任何需要产生物品的服务器均与该服务器直接通信。
AIServer 又一个功能服务器，负责管理所有NPC的AI。AI服务器通常有2个输入，一个是Scene Server发送过来的玩家相关操作信息，另一个时钟Timer驱动，在这个设计中，对其他服务器来说，AIServer就是一个拥有很多个NPC的客户端。AIserver需要同步所有与AI相关的数据，包括很多玩家数据。由于AIServer的Timer驱动特性，可在很大程度上使用TBB程序库来发挥多核的性能。
把网络游戏服务器分拆成多个进程，分开部署。这种设计的好处是模块自然分离，可以单独设计。分担负荷，可以提高整个系统的承载能力。
缺点在于，网络环境并不那么可靠。跨进程通讯有一定的不可预知性。服务器间通讯往往难以架设调试环境，并很容易把事情搅成一团糨糊。而且正确高效的管理多连接，对程序员来说也是一项挑战。
前些年，我也曾写过好几篇与之相关的设计。这几天在思考一个问题：如果我们要做一个底层通用模块，让后续开发更为方便。到底要解决怎样的需求。这个需求应该是单一且基础的，每个应用都需要的。
正如 TCP 协议解决了互联网上稳定可靠的点对点数据流通讯一样。游戏世界实际需要的是一个稳定可靠的在游戏系统内的点对点通讯需要。
我们可以在一条 TCP 连接之上做到这一点。一旦实现，可以给游戏服务的开发带来极大的方便。
可以把游戏系统内的各项服务，包括并不限于登陆，拍卖，战斗场景，数据服务，等等独立服务看成网络上的若干终端。每个玩家也可以是一个独立终端。它们一起构成一个网络。在这个网络之上，终端之间可以进行可靠的连接和通讯。
实现可以是这样的：每个虚拟终端都在游戏虚拟网络(Game Network)上有一个唯一地址 (Game Network Address , GNA) 。这个地址可以预先设定，也可以动态分配。每个终端都可以通过游戏网络的若干接入点 ( GNAP ) 通过唯一一条 TCP 连接接入网络。接入过程需要通过鉴权。
鉴权过程依赖内部的安全机制，可以包括密码***，或是特别的接入点区分。（例如，玩家接入网络就需要特定的接入点，这个接入点接入的终端都一定是玩家）
鉴权通过后，网络为终端分配一个固定的游戏域名。例如，玩家进入会分配到 player.12345 这样的域名，数据库接入可能分配到 database 。
游戏网络默认提供一个域名查询服务（这个服务可以通过鉴权的过程注册到网络中），让每个终端都能通过域名查询到对应的地址。
然后，游戏网络里所有合法接入的终端都可以通过其地址相互发起连接并通讯了。整个协议建立在 TCP 协议之上，工作于唯一的这个 TCP 连接上。和直接使用 TCP 连接不同。游戏网络中每个终端之间相互发起连接都是可靠的。不仅玩家可以向某个服务发起连接，反过来也是可以的。玩家之间的直接连接也是可行的（是否允许这样，取决于具体设计）。
由于每个虚拟连接都是建立在单一的 TCP 连接之上。所以减少了互连网上发起 TCP 连接的各种不可靠性。鉴权过程也是一次性唯一的。并且我们提供域名反查服务，我们的游戏服务可以清楚且安全的知道连接过来的是谁。
系统可以设计为，游戏网络上每个终端离网，域名服务将广播这条消息，通知所有人。这种广播服务在互联网上难以做到，但无论是广播还是组播，在这个虚拟游戏网络中都是可行的。
在这种设计上。在逻辑层面，我们可以让玩家直接把聊天信息从玩家客互端发送到聊天服务器，而不需要建立多余的 TCP 连接，也不需要对转发处理聊天消息做多余的处理。聊天服务器可以独立的存在于游戏网络。也可以让广播服务主动向玩家推送消息，由服务器向玩家发起连接，而不是所有连接请求都是由玩家客互端发起。
虚拟游戏网络的构成是一个独立的层次，完全可以撇开具体游戏逻辑来实现，并能够单独去按承载量考虑具体设计方案。非常利于剥离出具体游戏项目来开发并优化。
最终，我们或许需要的一套 C 库，用于游戏网络内的通讯。api 可以和 socket api 类似。额外多两条接入与离开游戏网络即可。
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具游戏服务器框架概括分析
来源：博客园
这篇blog题目涉及的范围真大！以至于在这里需要先写一篇前言把范围缩小。选择写这样一个系列的文章，主要是想给工作了两年的自己一个交代，或者说是一个阶段性的总结。两年时间里，房价依然再涨，工资依然跑不赢CPI，某人依然在仰望星空。期间很多梦碎了，很多还在坚持着，生活过得波澜不惊。而我也从刚毕业是的青涩逐步蜕变为“老油条”。不知道是一种悲哀、还是一种悲哀、还是一种悲哀....... 庆幸的是梦还在继续，一颗倔强的心还在坚持。希望明天的明天被束缚的心能回到梦开始的地方！ ==========================我只是条分割线========================
作为本系列blog的开篇前言，本文主要明确网络游戏服务器构架的设计目标，并作出一些限定。因为本系列所讨论的服务器端构架只适用于部分网游，并不是一个通用的网游服务器构架。 设计目标:支持的游戏类型：大型MMORPG游戏，类似魔兽世界（有大世界，不是开房间式）。连接方式：以TCP长连接为主。动作类游戏并不在本文讨论范围内（因为本人并没有参与开发过动作类游戏），如果有时间可以研究一下龙之谷（部分使用UDP传输）、天下贰（全部使用UDP传输），类似的逆向工程网上已经有人做了。在线人数：保证最大1w人左右在线还能比较流畅的运行。如果在线人数大于1w对客户端的同学和策划的同学都是很大的挑战。服务器可以以多进程的形式布置在不同的物理主机上，也可以布置在同一主机上，考虑效率的同时兼顾可扩展性。能在普通配置的服务器上流程运行，物理主机配置：按照DELL 1950、DELL R610上32G内存的标准来部署主机，一般公司是用不起WOW的小霸王的.......内存不用过多的考虑，因为现在服务器的内存已经很大了。减少内存使用会放到模块设计、详细设计里。不在构架分析的讨论范围内。偏格斗的游戏会对CPU和带宽要求比较高，设计时需要进行讨论。
设计目标就这些多说无益，核心就是设计出能够支持类似魔兽世界的大型MMORPG游戏的网游服务器端。具体的设计以及设计时的取舍、需要解决的问题等，会在后续的文章进行详细的介绍。
本文并没有涉及什么逆向工程，只是拜读刀剑Online服务器端主程的文章后[1]，想结合自己的经验谈一谈。PS：由于题目范围太大，本系列的做了一些限制。 一、网络游戏服务器
要想设计好网络游戏服务器的构架，首先需要知道网络游戏服务器在玩家游戏过程中发挥什么作用。就我个人的理解：网游服务器在玩家游戏过程中扮演上帝的角色。玩家在服务器制定的规则下进行游戏，服务器负责同步在线玩家之间的属性、操作、状态等等，最终在多个不同的客户端呈现一个“统一”的游戏世界。
所谓的服务器构架在本系列blog中，主要是指如何将服务器各部分合理的安排，以实现最初的功能需求。好的结构不是一蹴而就的，是通过需求的推动一步步的完善。而且每个设计者心中的标准不尽相同，所以我认为并没有绝对优秀服务器构架。本系列文章中所谓的优秀构架是指各方面达到一种平衡（包括成本等的非技术因素）。
下面先介绍刀剑Online的服务器构架（后续还可能有WOW、天龙等）： 二、刀剑Online
图1 刀剑Online服务器构架
看了像素的技术总监魏华的文章[1]，感觉有点意思。文章中所介绍的服务器构架并不复杂，但满足一般MMORPG网游要求应该是绰绰有余了。按照魏华自己的话，这样的服务器构架主要满足能够接受以下几条限制的网络游戏：游戏同时在线人数在1w人以下。服务器为多进程程序，可部署在一台或者多台机器上。服务器内存足够大，一般一个进程1~2G的内存需求还是应该满足的，64位系统能支持更大的内存需求。内存这块主要看游戏的设计需求。刀剑属于格斗性质的网游，对CPU和带宽有一定的要求。（这篇文章写于2005年，当时刀剑可能是按照256k、512k或1M ADSL的网速进行设计的。现在已经开始普及10M网，带宽和网速应该可以满足），网络延迟的问题本文后面再做展开。对CPU的要求主要影响可承载人数。地图采用独立小场景的管理模式，各个场景之间通过传送点来连接。每个场景服务器程序分管一部分地图。
服务器包括游戏中和游戏外两大部分，这里主要讨论游戏中的服务器构架，类似客户端自动更新等的游戏外服务器不在本文的讨论范围。
接下来对刀剑Online的服务器构架的各个部分进行详细的分析，其中包含很多我自己的想法，很多内容都是我猜测的，因此不能“信以为真”。 2.1 连接负载服务器（Connection Load Server，CLS）
游戏客户端在游戏过程中实际上是和连接负载服务器（简称CLS）进行连接并做数据交互的。如文中[1]所诉，CLS主要的作用是：把网络连接和真正的游戏逻辑隔离开，降低游戏逻辑服务器处理网络交互的负担，同时提高游戏的安全性。有了CLS，刀剑Online的服务器对于玩家来说就是一个黑盒，如下图：图2使场景服务器（Zone Server）更为独立----客户端连接CLS而不是直接连接Zone Server的好处是：用户切换场景服务器时，并不会导致原来的TCP连接断开，从而使设计更为简单和独立。提高发送广播消息的效率，比如需要全服广播时，游戏逻辑服务器只需要对CLS发送一条广播指令，而向每个用户的广播工作由CLS完成。完成客户端数据交互的加密解密过程。连接服务器的主要工作正如上述魏华谈到的，但有几点并没有做出强调，下面本人结合平时的实际工作给出一些补充（不一定正确）：根据经验：
CLS作为与client建立连接、进行数据交互的“Gate”，从程序角度来看CLS的代码应该是最简洁高效的。因为CLS主要负责与客户端交互数据是的加密解密、以及数据搬运。而使用流加密RC4对整个数据流进行加密解密是很耗CPU的，因此代码的高效在这个模块是十分的重要。
为了提高程序的运行效率，CLS程序往往会使用-O3的选项进行编译，这无形中又对代码的编写有更高的要求。CLS一般会有自己的打包机制（控制发送频率），因此常会使用TCP_NODELAY选项禁用Nagle算法。
CLS常会被分配到不同的物理机器上，因为在处理TCP包时，需要通过软中断来通知进程或者唤醒system call，在服务器十分繁忙的时候CPU可能处理不过来。解决办法是：使用多核的服务器，然后把TCP的软中断平均分配到多个CPU。（一些操作系统默认只使用0号CPU来处理，Fedora Core release 2默认就是只使用0号CPU，较新的版本我没有做研究）
CLS在做数据流的解密后，往往需要把数据包构造成内部服务器进程间通讯使用的protocol，这种protocol模块要独立，序列化和反序列化的接口要稳定，这样以后需要更换协议模块也不至于伤筋动骨。可以使用像google的protobuf这样的开源协议，减少开发难度。
CLS负责建立和client的连接，多会使用多个CLS进程才能支撑1w的在线人数，因此在CLS前端一般会有负载均衡的程序，负责把建立连接的请求均匀的提交到各个CLS。
有一个需要讨论的问题：作为服务器端的“Gate”，只负责数据转发的CLS是否需要对client发过来的数据进行完全的解密？或者只解密包头，知道转发的目的地即可？（RC4并没有增加流的长度，因此可以只做部***密）
CLS只做部***密：好处：将耗费CPU资源的解密功能分摊到别的进程；各进程各服务可以在解密后用不同的方案来构造自己的protocol。
CLS做完全解密：好处：可以提前过滤部分无效的消息，只做部***密也可以做提前过滤，但是这样太过于依赖协议的设计；在CLS处做完全解密，则往后服务器端的之间的消息传递都是明文，利于抓包查错；由于CLS的功能比较简单，很容易通过加机器来进行扩展，因此计算放在CLS上是比较明智的选择。 总结：
CLS是一个功能相对简单但要求代码简洁高效的程序，在设计实现的时应该注重效率及代码编写规范。经过对比在CLS程序对数据流进行完全解密是利大于弊的，推荐使用这种方案。
上一篇《》介绍了刀剑Online的连接负载服务器CLS，博友提出质疑“说得不够详细，比如你怎么，场景服务器怎么才算一个场景服务器，场景服务器切换怎么处理不断线后连接另一个场景的，还有很多细节问题没有说到”，本篇就来介绍游戏服务器最为核心的部分：游戏逻辑服务器，同时也回答了这位博友的问题。PS：本篇的文章结构主要分两个部分，前半部分（2.2节）介绍刀剑Online如何实现游戏逻辑服务器，后半部分（2.3节）为本人结合实际工作对这套服务器构架做出的一些展开解释及补充，主要对设计思想进行分析。精彩在后面哦！ -------------------------------------------我只是条分割线-------------------------------------------- 先来回顾一下刀剑Online的总体构架图：
2.2 游戏逻辑服务器
顾名思义，就是和游戏具体逻辑相关的服务器（这应是一个统称）。这块是网游服务器端的核心部分，不同的游戏差别会很大。在刀剑中，游戏逻辑服务器分为两部分：总控服务器和场景服务器。
2.2.1 总控服务器（Master Server，MS）
关于总控服务器的作用，刀剑Online的主程是这么解释的：
总控服务器（以下简称MS）的作用之一是负责玩家在具体游戏内容之外的操作（即.玩家进入场景服务器之前地操作）。如：登录、注销、各种角色操作（创建、删除、选择）等等。
MS和所有地场景服务器都保持连接，这样它就成为各个场景服务器间的枢纽，当需要一些跨场景服务器的操作或者需要访问别的场景服务器数据的时候，指令都先发给MS，然后MS根据需要再转发给相应地场景服务器或者直接发给相应的用户，并进行后续地协调工作。
比如：在场景服务器1上的用户A希望向游戏中的用户B发出一条添加好友的请求，则场景服务器1向MS发送添加好友指令并附带了用户B的名字，MS查找发现有B这样的用户，则直接把指令发给CLS，然后由CLS转发给B用户；如果没有发现B用户则直接通知A未发现B。
又比如：在场景服务器1上的用户A点中了传送点，将要传到场景X，场景服务器1发现X场景并不在自己的管辖范围内，于是发送转移指令给MS，MS查找发现场景X在场景服务器2上，于是先发送用户A的离开指令给场景服务器1，让用户退回到MS上，然后再发送用户A的进入指令给场景服务器2，并说明用户将要进入的场景为X，这样一次跨服务器的场景转移就完成了。[1] 2.2.2 场景服务器（Zone Server，ZS）
关于场景服务器的作用，刀剑Online的主程是这么解释的：
场景服务器（以下简称ZS）就是具体负责游戏场景的服务器。玩家选择人物开始游戏之后就进入了这种服务器（即开始游戏之后CLS把所有玩家的操作指令都转给ZS）。
玩家的各种操作的逻辑都是由ZS完成的，同时，ZS也要负责各个场景以及场景中的NPC和场景中各个物品的逻辑运行。
每款游戏的真正游戏性的核心就是这些ZS。它的具体细节我就不过多的讲述了，各个游戏的具体内容应该都不相同。不过有几个原则是共同的：
一、是要高效。如果ZS对游戏逻辑的处理效率低，会直接影响玩家同时在线的数量，并导致游戏中的玩家感觉很“卡”，这是除了网络延时之外第二个会造成游戏 “卡”的地方。提高效率的方法除了对代码进行优化外，就是要使用高效的脚本系统，直接把脚本转化为程序代码编译到程序中去也不失为一个办法。
二、是要有灾难恢复机制，就是当ZS发生非法操作时（只要不停电）能够恢复出非法操作时各个用户的数据。这个在游戏运营初期服务器尚不稳定的时候非常重要。虽然我们也可以通过加快用户存盘间隔的方式（比如把每10分钟存一次盘改为每1分钟存一次盘），但是这会成倍加重负担，同时也不能避免由于用户刚好在存盘间隔的时候获得了重要的金钱或道具而导致丢失的情况。刀剑采取的方法是在申请用户关键数据对象的时候通过包装的函数从共享内存中申请，这样即便ZS非法操作了，共享内存并不会消失，在重新启动的时候就可以从共享内存中恢复出程序非法时的用户数据。当然恢复的时候也需要对用户数据进行一些校验，以免把已经被破坏的数据存入数据库。[1]
2.3 设计思想分析
游戏逻辑服务器主要负责汇总所有在线的client发来的各种操作、状态等数据包，经过一系列的处理后有选择的广播给需要的client，从而给所有在线的玩家呈现一个“统一”的世界。
优秀的逻辑服务器需要优秀的设计思想，而优秀的设计思想又源于对游戏虚拟世界的适度抽象。抽象可以看作一个工程问题，同时也可以看作一个哲学问题，这正是游戏开发的魅力所在。本系列blog将围绕这种抽象一步步展开，结合不同的项目来诠释网络游戏服务器端的设计思想（希望能做到....）。
站在服务器端的角度对游戏虚拟世界进行抽象，首先要弄清楚构造虚拟世界需要些什么？让我们来想象一下吧（以下内容参照了《盗梦空间》-“Inception”），先来看一段视频：
Inception是我非常喜欢的影片，第一次看到这一段的时候，就感觉非常像游戏设计。今天能把它写下来也算没浪费几十块的电影票钱。
影片中饰演the architect（造梦师）的艾伦?佩姬(女)，正在接受莱昂纳多（饰演the extractor-盗梦者）的训练。莱昂纳多说道：“Remember you are the dreamer you built this world。”，“I'm the subject my mind populates it”。值得关注的两个名词：world，subject。这就是我们要讨论的主题。那么构造网络游戏的虚拟世界需要些什么呢？其实莱昂纳多已经替我回答了这个问题：“We create and perceive out world simultaneously. You create the world of the dream, We bring the subject into that dream, and they fill it with their subconscious.”。world就相当于游戏里的场景，而subject就是一个个在线的玩家（player）。
游戏世界（world，这里的world泛指游戏世界及地图，见2.3.2）及游戏对象（object，包括player）是构造网络游戏服务器端时，需要关注的两个重点。如何处理好world和object的关系和地位直接影响到服务器端的构架。 2.3.1 游戏对象（object）
先来看游戏里一般会有那些object，以Mangos为例：图2 mangos游戏对象的class diagram[2]
对于上面的类层次结构图这里不做展开（留到本系列后面的文章中展开），这里引用mangos的游戏对象是想给读者一个直观的印象，游戏中的object在服务器端是个什么摸样。类的层次是对游戏世界中的对象抽象后得到的结果，抽象需要“适度”：如果类的层次过深，维护起来困难，而且后期往往会导致基类过于臃肿、不堪重负；如果类的层次过浅，一些object的共性不能体现，很多代码会重复出现在各个子类里，复用性差。 2.3.2 游戏世界（world）
游戏世界在本文是泛指游戏对象所在的场景，以及附加在场景之上的地图管理和对象管理，这里统称游戏世界管理。
如何进行游戏世界的管理是一个复杂的工程问题，网络游戏常常会把整个游戏世界分为若干张地图，每张地图又会分为若干个区域进行管理。这若干张地图能无缝的过渡就称为无缝大地图模式（类似WOW），如果像刀剑Online那样只能通过传送服务在两张不同地图之间穿梭的，称为有缝地图。而相对来说服务器端会比客户端简单一些，例：如果在客户端看到的场景是下面这个样子：服务器端根据划分区域的不同可能看到的地图是这个样子：
这里服务器端用到了tile-based的方式来管理地图，这种tile的方式在2d游戏中十分的常见（打格子），而很多3d网游的服务器端为了减少运算量也采用这种tile模式划分区域进行管理。如果对地图管理有兴趣请阅读云风的blog《》、《》，本文先不做详细的展开。
2.3.3 游戏对象和游戏世界的关系
如何处理游戏对象和游戏世界的关系和地位，是影响服务器端架构的最直接因素。为了体会到这点，下面将以刀剑Online为例，分析玩家对象（player，游戏对象中最为重要的部分）和游戏世界的关系对整个服务器构架设计的影响。 1. 玩家对象player的构建
刀剑Online把游戏逻辑服务器分为总控服务器（Master Server，MS）和场景服务器（Zone Server，ZS，本文提到的游戏世界多指ZS），那么在client成功登陆server后，服务器端应该在哪构建player对象呢？在MS上？还是在ZS上？这是个工程问题，同时也是个哲学问题.......如果把player（以及其他的游戏对象）放在Master Server上：也就是说所有登陆的玩家的数据都会在MS的内存中有一份映像，MS将保存着player最新的数据。这么做的好处是player的数据统一，从而使同服玩家的一些交互变得十分方便，比如同服玩家组队、交友等不需要知道玩家在那个ZS里。切换场景服务器时也不需要把player数据从一个ZS拷贝到另一个ZS，只需要把player身上记的ZS信息修改一下；player在MS上构建的缺点也是显而易见的，所有中心节点式的系统都会遇到单点不可靠的问题，player的信息都保存在MS上，假如有1w人在线，内存占用就是一个很大的问题（毕竟单个进程的内存使用还是有限制的，实际开发中曾经遇到占用十几G内存的进程......相当可怕），而如果一个player借住外挂发送一些非法消息给MS，错误处理不当时很有可能会core进程，这样一来整个服务器的玩家都会掉线。还有一些和地图相关的逻辑会很难操作，比如player与场景中怪物进行PK时，由于player的数据保存在MS，因此ZS需要做一个Attach操作告知MS某个player和某个monster进行战斗，MS进行完伤害计算后发AttachResult给ZS，最后由ZS再广播给相关的客户端，如图：如图中标注的（1）~（4）的步骤，展示了这个过程，编程操作起来还是挺麻烦的。如果把player放在Zone Server上：这是一种比较常见的方式，player和其他游戏对象在场景服务器中构造，隶属于Zone Server。由ZS来掌管player从编程角度讲好处多多：可以直接获得player的信息，对于场景内交互十分便利，场景内的操作不需要多余的数据传输。而在需要跨场景操作时只需用MS中转一下即可；但是这种方式缺点同样是很致命的，player在Zone Server上构造就失去数据放在中心节点的简洁，player的信息常常需要在ZS、MS和DB上进行同步，这种“三体同步”的痛苦只有做过的人才能体会。比如：几个独立的服务器之上需要增加一个跨服服务器，这几个普通服务器的玩家可以进入这个跨服服务器进行pk。那么就需要将player先从普通服务器ZS退到MS，由普通服务器的MS把player的数据发给跨服MS，最后再由跨服MS发送到跨服的ZS。如果还涉及DB则会更加的复杂。ZS、MS、DB相互独立，如果没有强制规定，这种同步往往是没有方向的：player的最新的数据一般在ZS上，但是有些交互不能在ZS上完成，那么可以有两种选择：（1）ZS把player数据发给MS，由MS进行操作，操作过程中ZS不能修改player的相关数据。（2）把player的最新数据存盘，然后由MS读盘取player的数据然后进行操作，操作过程中ZS还不能改变player的相关数据。不管哪种方法开发的逻辑多了以后都不好维护，从此维护人员都变成怨妇.......
刀剑Online应该采用的是第2中方式，把player放在Zone Server上。 2. 玩家对象player和world的关系
如何处理玩家对象player和world的关系集中体现了服务器端的哲学，值得细细品味。处理两者的关系在本人看来有两种主要的模式：一种是以player的中心的“自我”模式；另一种是以游戏世界为中心的“上帝之手”模式。这两种模式的哲学主要体现在加锁模式上，接下来进行详细介绍：（一）player的“自我”模式
“自我”模式顾名思义，就是player以自我为中心，什么事都要亲历亲为。以player使用物品为例：
如上图是一个完整的player使用物品的流程。“自我”模式体现在上图的（1）位置，在（1）中首先取到服务器中对应的player，加锁后用player调用自己的处理函数进行处理。由于（1）相当于处理客户端发来的请求的入口处，因此在这里进行加锁和解锁操作是十分合适的，此后的（2）~（5）player在调用自己的处理函数时，编程人员完全不需要考虑加锁的问题。
所谓的“自我”模式，其实就是指在服务器端对player的操作其实都是player自己去完成的，“我”自己去把事情做完。处理逻辑时“我”（自己的player实例）不会主动去锁住对方的player实例，因此一个player不能修改另一个player的数据，world也不能修改player的数据。world和player的关系是“独立”的，player身上记着world的信息（相当于“我属于哪个世界”），world里存放着player的实例，但是它们直接不能直接修改对方的数据。这么做是为了避免死锁，使得加锁解锁变得简单而统一（如上图）。
“自我”模式有加锁解锁的便利，但是一个网络游戏怎么可能player和player、player和world直接没有交互呢？交互就需要获得或修改对方的数据，遇到这样的问题“自我”模式怎么处理呢？请看下图：
如上图：client A向服务器发送“向玩家B发起攻击”的消息，服务器端client A对应的实例Player A收到消息后，发现需要与player B进行交互，根据“自我”模型的限定，player A不能直接修改player B的血量等信息，这时player A需要做的是将自己的信息打包成一个msg结构然后push_back到消息队列message queue并指定player B作为接收者。在message queue上将这个msg转发给player B前，会先调用lock(playerB)将B锁住，接着把msg传给player B进行处理，在处理完毕后再调用unlock(playerB)。lock和unlock都在统一的地方调用，加锁解锁十分简洁，playerB处理msg消息时不用关心任何加锁问题。在上图的（2）中，player B进行伤害计算后将伤害消息广播给周围的玩家。
注意：“自我”模式下，伤害计算是在受攻击方进行的。player之间、player和world之间都是通过消息传递进行交互的。总结：优点：“自我”模式的优点集中体现在加锁上，编程人员在编写具体逻辑时不用担心加锁问题，也不用费尽心思来避免死锁，因为加锁都在消息入口处统一做了，同时不会主动去对别的player实例进行加锁操作。使用这种模式时，最好把移动的相关逻辑独立出来使用不同的锁，以免照成过多的加锁冲突和等待。缺点：“自我”模式的缺点也是十分明显的，每个player实例作为不同的“我”独立存在，需要交互时只能通过消息队列来传递信息，极大的增加了交流的成本（内存、CPU占用率都会增加）。一个player往往不能即时的取到别的player的数据，这样一来很多的计算都只能做延后处理，比如伤害计算就只能放在被攻击者的player上，使得很多需要做先验判断的技能实现起来变得复杂，这类技能只能靠释放技能的player，发送请求消息给其他player，然后再由其他player把自己的信息通过msg queue发给释放技能的player。异步处理方式往往会但来更多的烦恼----需要增加很多错误判断、错误处理以及超时处理等等。在线人数高的时候，message queue的容量以及所占用的内存也是需要考虑的问题。
引用狄更斯的：“It was the best of times, it was the worst of times”。本人依葫芦画瓢：“自我”模式是一种nb的设计，也是一种sb的设计....... （二）world的“上帝之手”模式
“上帝之手”模式是以world为中心（类似war3），以地图为单位进行划分，player、NPC、monster等游戏对象都隶属于world。在world的掌控之下，就像有一只上帝之手在拨弄着这些小玩意。以client A向服务器发送“向玩家B发起攻击”消息为例，服务器端的处理流程如下：
从上图中可以看出“上帝之手”模式的核心是world去完成这项任务：找到playerA和B，把他们都锁住，然后交给技能模块来进行伤害计算，最后把结果广播出去。整个过程就像在玩war3这样的RTS游戏，服务器就像一个神，以斜45度的上帝视角来观察所有的玩家。
“上帝之手”模式的设计难点在于加锁策略，因为需要对多个对象进行加锁，加解锁的顺序不当容易产生死锁。加锁策略有很多种，这里不做具体的展开。只介绍一种最常用的方法，即对加锁对象进行排序。游戏对象在产生时都会有一个唯一的id做标识，当lock ()函数能按照一种稳定的算法对这些id进行排序时，就可以避免死锁。比如对游戏对象进行分类：player、npc、monster等，先对分类进行排序，再对对象的id进行排序。需要注意的是MMORPG游戏经常需要进行合服操作，为了保证合服后player的id不会重复，需要对player_id进行一些规划。总结：优点：服务器程序扮演上帝的角色，可以获得几乎所有的信息，这对逻辑编写带来极大的便利。和“自我”模式一样，最好把移动的相关逻辑独立出来使用不同的锁，以免照成过多的加锁冲突和等待。“上帝之手”模式更容易进行整体规划，更容易实现模块化设计，降低程序的耦合度。缺点：上帝也不是这么好演的，“上帝之手”模式对整体框架、接口设计、加锁策略等有更高的要求，同时对编程人员的要求也会更高。
最近闲着没事把云风的《》看了个遍，希望能从大牛的开发轨迹中得到一些启发。但可能是因为本人level太低，一遍看下来还是云里雾里，不甚明白。没办法只好再看一遍，希望能对他们的服务器端架构有个简单的认识，这里同时做些笔记。PS：本文是我个人对云风的开发笔记的读后感，可能会有很多错误，慎入！ ----------------------------------------华丽丽的分割线------------------------------- 一、服务器划分原则
在现有的网络游戏服务器端架构中，多是以功能和场景来划分服务器结构的。负载均衡和集群暂且不在本文中讨论（bigworld、atlas）。服务器划分可以基于以下原则：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器。以多线程或多进程的编程方式适应多核处理器。在同一个服务器架构下，应尽可能的复用某些服务器（进程级别的复用，比如场景服务器）。运行时玩家数据的保存、修改及数据流向应该是设计的焦点，它同时也决定了服务器应该如何划分。服务器的划分应该适度，在保证清晰的数据流向的前提下，根据游戏的类型和规模尽量减少服务器或服务器进程的个数，以减少服务器之间过多的复制数据、锁冲突（使用共享内存进行通讯时）。主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够简单，并满足以上1、3两点[1]。
接下来我们来看看云风的服务器架构是如何处理好以上几点的。图1 服务器架构（此图为本人猜测，可能有误） 二、运行时的玩家数据
网络游戏服务器程序一项重要的工作就是根据client发过来的数据包，在服务器端模拟玩家的行为操作并把这些行为广播出去。那么服务器程序在运行时就需要一些实体来保存玩家的数据，这些实体可以是一个类，也可以是一个线程，设计思想不同采用的实体差别也会很大。这里涉及服务器端设计的一个核心问题：运行时玩家数据的保存、修改及数据流向。 agent
云风通过抽象实体agent来处理单个client的服务请求，agent和client是1:1的关系（见图1）。agent是在gate程序后端，负责翻译、转发以及回应客户端发过来的请求。agent的主要工作内容见云风的《》。值得补充的是设计agent的主要优势是：把对单个 client 服务的代码集中写在 agent 服务中。由 agent 再和内部其它服务沟通。数据加载使用共享内存的方案，由 agent 向持久化模块发出信号，做加载或纯盘处理，通过共享内存得到结构化数据块。[2]
agent相当于client在服务器上对应的实体，玩家的属性和数据只能由agent来修改，别的服务只有读权限。通过attach操作获得数据（attach可能是通过服务器通讯框架skynet，也有可能直接mmap到共享内存sharedb上以获得数据）。
agent的设计使得整个系统对玩家数据的修改只有一个输入点，数据流十分的明确，易于维护。虽然这种设计可能会照成数据的多次复制，但是带来的代码维护和查错上的便利是十分可观的。
如果把所有的agent放在同一个进程里，在编程该程序时还应该考虑到容错问题，比如说（1）使用C++编写这个程序，agent以类的形式存在，使用thread pool来处理收到的数据包，实际操作时thread的数量是会远远小于agent的数量的，数据包到达后会在队列里等待thread调用agent的逻辑来处理。这是一种比较常见的设计方法，但要注意的是由于agent都放在一个进程里，程序的健壮性要求很高，一个进程core则会导致全服玩家掉线。而使用C++编写也增加了宕进程的可能性……..你懂的。（2）使用编写，对于这种“中心节点”式架构来说可能是更好的选择，起码不是因为一个玩家的误操作(可能使用外挂)导致全服玩家掉线。（3）云风似乎是使用lua coroutine来实现agent的相互隔离和协同工作的，这样可以减少单一agent失败对其他agent的影响（动态语言的好处）。 sharedb
sharedb在系统中的地位看上去像是database前端的cache，但就本人的理解sharedb的作用远不止是一个数据缓存。
和天龙八部的ShareMemory类似，sharedb也采用了定长的结构化数据（见《》），通过共享内存来实现进程间的数据共享。sharedb的存在使得游戏逻辑处理和数据保存逻辑得到很好的隔离，游戏逻辑不用关心后端的数据是如何保存的，只要sharedb挂上定期存盘的服务，在接口定义明确的情况下，后端到底采用什么样的数据库变得不是那么重要，从而降低了系统的耦合度。 三、服务器底层框架skynet
skynet的设计思想见《》：
我希望我们的游戏服务器（但 skynet 不仅限于用于游戏服务器）能够充分利用多核优势，将不同的业务放在独立的执行环境中处理，协同工作。这个执行环境，最早的时候，我期望是利用 OS 的进程，后来发现，如果我们必定采用语言，比如 Lua 的话，独立 OS 进程的意义不太大。Lua State 已经提供了良好的沙盒，隔离不同执行环境。而多线程模式，可以使得状态共享、数据交换更加高效。而多线程模型的诸多弊端，比如复杂的线程锁、线程调度问题等，都可以通过减小底层的规模，精简设计，最终把危害限制在很小的范围内。这一点，Skynet 最终花了不到 3000 行 C 代码来实现核心层的代码，一个稍有经验的 C 程序员，都可以在短时间理解，做维护工作。
做为核心功能，Skynet 仅解决一个问题：
把一个符合规范的 C 模块，从动态库（so 文件）中启动起来，绑定一个永不重复（即使模块退出）的数字 id 做为其 handle 。模块被称为服务（Service），服务间可以自由发送消息。每个模块可以向 Skynet 框架注册一个 callback 函数，用来接收发给它的消息。每个服务都是被一个个消息包驱动，当没有包到来的时候，它们就会处于挂起状态，对 CPU 资源零消耗。如果需要自主逻辑，则可以利用 Skynet 系统提供的 timeout 消息，定期触发。
Skynet 提供了名字服务，还可以给特定的服务起一个易读的名字，而不是用 id 来指代它。id 和运行时态相关，无法保证每次启动服务，都有一致的 id ，但名字可以。
本人感觉skynet像一个发布订阅的消息中间件（还没看源码，可能有误），这种基于服务的即插即用式的框架给服务器端带来很大的可扩展性，同时也使得各模块之间独立清晰，具有良好的可维护性。但是这里有个疑问，服务都以so的形式挂在skynet上，那么这些服务从哪里获取玩家、怪物、NPC等object的数据？是从skynet中获得还是直接从sharedb中获得，出于性能的考虑是不是要把skynet和sharedb部署在同一台物理主机上？这样一来就会增加设计和具体逻辑的耦合度。看了《》，感觉skynet上的服务是要通过skynet来获得玩家的数据，这样操作会不会导致数据被复制很多次，不知道最终的效率是否受到影响？ 四、gate
满足服务器划分原则里的第一点：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器。
gate的主要工作可以参见本系列blog的第二篇《》 五、场景管理器
主要用于管理静态场景和动态副本，比如agent登录时查询自己所在场景对应的服务器地址。 六、场景服务器
场景服务器的内容我没有从《开发笔记》中得到太多的信息（可能level太低），更多的是以功能模块的形式写，比如AOI。不过其中有一点比较新颖的是云风认为player的位置、动作状态，战斗数值状态等都是场景的一部份，应该保存在场景中而不是agent中。本节有所更正见（八）补充。
据我的猜测，场景服务器应该会负责：怪物行走控制，player移动更新及位置同步怪物AI策略区域性广播，场景广播战斗逻辑AOI服务（Area Of Interest ）碰撞检测自动寻径
需要注意的是场景服务器修改的一些数据应该以什么样的频率通知agent呢？比如player的位置信息，该信息是完全保存在场景数据里还是说agent里也有一份？ 七、总结
本文是一篇云风《开发笔记》系列blog的读后感，所述内容均是本人的猜测，虽恐贻笑大方，但也希望能抛砖引玉。收笔忐忑ing！ 八、补充：
(1) 云风在微薄上的回复是：“我们最终采用的是单进程多线程, 每线程上一个 lua state 的结构. sharedb 是用来线程间数据交换的. gate 和 sharedb 以及 loader 和 agent map 一样, 都是 skynet 下的独立服务, 以 so 挂接进去的. 后来的商品交易, 掉落品分配也是 skynet 下的服务. ”
(2) 关于场景服务器，云风已经给出完整的说明，见《》
场景服务分成两个部分，一是副本管理器，二是地图服务。在角色数据上，记录有角色应该属于的地图。agent 向地图所属的副本管理器查询，得到他所属的地图服务地址。便可以把自己注册到具体地图上。
地图服务管理了所有其中的角色 id ，以及若干 npc 。他的义务在于把让这些 id 对应的 agent 相互了解。但具体逻辑则放在每个 agent 服务上。每个 agent 自己所属进程 attach 其它 id ，可以获取其他对象的状态。
(3) 风哥在《》中已经提到最终使用单进程多线程的模式。看来简单设计是有共识的:-)
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动