游戏服务器开发的根本体系与服务器端开发的一些倡议
近些年来，我身边的朋友有许多都从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.1.1 了解TCP/IP协定
网络传输模型
滑动窗口技术
创立连贯的三次握手与断开连贯的四次握手
连贯创立与断开历程中的各种状态
TCP/IP协定的传输效率
思索
1）请解释DOS袭击与DRDOS袭击的根本道理
2）一个100Byte数据包，精简到50Byte, 其传输效率提高了50%
3）TIMEWAIT状态怎么解释？
1.1.2 把握常用的网络通讯模型
Select
Epoll，边沿触发与平台出发点区别与利用
Select与Epoll的区别及利用
1.2 存储
盘算机系统存储体系
程序运转时的内存构造
盘算机文件系统，页表构造
内存池与对象池的实现道理，利用场景与区别
关系数据库MySQL的运用
同享内存
1.3 程序
对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 状态监控
随时监控服务器内部状态
内存池，对象池运用状况
帧处置工夫
网络IO
包处置机能
各种业务逻辑的处置次数
2.13 包频率控制
基于每个玩家每条协定的包频率控制，瘫痪变速齿轮
2.14 开关控制
每个模块都有开关，可以危急关闭任何出题目的功能模块
2.15 反外挂反作弊
包频率控制可以覆灭变速齿轮
包id自增校验，可以覆灭WPE
包校验码可以覆灭包拦截篡改
图形辨认吗，可以踢掉99%非人的操纵
魔高一尺，道高一丈
2.16 热更新
中心配置逻辑的热更新，如防陷溺系统，包频率控制，开关控制等
代码根本热更新，如Erlang，Lua等
2.17 防刷
要害系统资源（如元宝，精神值，道具，配备等）的产出记日志
资源的产出和耗损尽量依赖两个或以上的独立前提的检测
严厉检查各项操纵的前置前提
校验参数合法性
2.18 防解体
系统底层与具体业务逻辑无关，可以用大量的机器人压力测试袒露各种bug，确保不乱
业务逻辑倡议运用脚本
系统性的保证游戏不会解体
2.19 机能优化
IO操纵异步化
IO操纵合并缓写 （事务性的提交db操纵，包合并，文件日志缓写）
Cache机制
减少竞态前提 (以免频繁进出切换，尽量减少锁定运用，多线程不一定因为单线程) 多线程不一定比单线程快
减少内存复制
本人测试，用数听说话，别猜
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 相似。额外多两条接入与脱离游戏网络即可。
热门标签：dede模板 / destoon模板 / dedecms模版 / 织梦模板
