站务联系
游戏的构架设计十分重要，好的构架代码清晰，责任明晰，扩展性强，易于调试。这些会为我们的开发市下不少时间，对于游戏服务器的构架设计，我们首先要了解游戏的服务器构架都有哪些组成？一款游戏至上线，需要具有这些功能？游戏构架原本代表是一个机制游戏服务器，它包括：
1.系统初始化
系统初始化是在没有客户端链接的时侯，服务器启动时所须要做的工作。基本上就是配置文件的调用，初始化系统参数。
但是还要留意一些问题：
系统初始化还要的参数配置在那里，是配置在本地服务器还是配置在数据库。
服务器启动的时侯去数据库取；
配置的更改需不需要重启服务器等；
2.游戏逻辑
代码应当分层，不然后期要更改需求，比较麻烦，Netty是现在比较流行的NIO框架。
协议层，也叫后台交互层，它主要负责前台交互合同的解读跟返回数据。在这一层基本上没有哪些业务逻辑实现。与前台交互的数据都在这一层开始，也在这一层中止。比如用Netty框架，那么Netty的Ctx只好出现在这一层，他不能出现至游戏业务逻辑代码的实现中，接收至客户端的恳求，在这一层把还要的参数解读下来，再把参数传入业务逻辑步骤中，业务逻辑步骤处理完后，把要返回给客户端的数据再返回至这一层，在这一层组织数据，返回给客户端，这样就可以把业务逻辑跟网路层分离，业务逻辑只关心业务实现，而且也便于对业务逻辑进行单元测试。
业务逻辑层，这里处理真正的游戏逻辑，该估算售价估算售价，该通关的通关，该计时的计时。该保存数据的保存数据。但是这一层不直接操作缓存或则数据库，只是处理游戏逻辑估算。因为业务逻辑层是整个游戏时间的处理核心，所以他的处理是否正确直接决定游戏的正确性。所以这一层的代码要尽量使用面向对象的方式去实现。不要出现重复代码或相同的功能进行复制粘贴。
这样更改上去非常不便，可能是更改了某一处，而忘掉更改另外同样的代码。还要考虑每位方式都是可检测的，一个方式的行数最好不要超出一百行。另外可以多爱看设计方式的书，它可以帮助我们设计出灵活，整洁的代码。
3.数据库系统
数据库是储存数据的核心，但是游戏数据在储存至数据库的时侯会经过网路跟硬盘的IO，它·的访问速率相对于显存来说是太慢的。一般来说每天访问数据库都要跟数据库推行链接，访问完成以后，为了节约数据库的链接资源，再把链接断掉。
但是这些链接无形中又为服务器提高额费用，在大量的数据访问时，可能会更慢，而游戏又是要求低带宽的，这时该如何办？
有一个数据库连接池，即把访问数据库的链接放在一个地方管理，用完不断掉，用的时侯去拿，用完再放出去。这样不用每天都推行新的链接了。
但是假如要我们自己去实现一套连接池管理成立的话游戏服务器，需要时间不说，对技术的把控又是一个考验，还要经过检测等等，幸好互联网开源的明天，有一些先成的可以使用，这里推荐Mybatis，即实现了代码与SQL的分离，又有足够的SQL撰写的灵活性，是一个不错的选择。
4.缓存系统
游戏中，客户端与服务器的交互就是要求低带宽的，延迟越低，用户感受越好。像之前说过的一样，低带宽就是要求服务器处理业务尽量的快，客户端一个恳求进来，要在最短的时间内相应结果，最低不得超出500ms,因为加上来回的网路传输消耗，基本上就是600ms-700ms，再长都会认为卡。
如果直接从数据库中取数据，处理完以后再·存回数据库的话，这个功耗是和不上的。在服务器，数据在显存中处理是最快的，所以我们要把一部分常用的数据提早读取至显存中。比如说游戏数据配置表，经常登入的玩家数据等。这样在处理业务时，就不用走数据库了，直接从显存中取就可以了，速度更快。
游戏中常见的缓存：
1.直接把数据存贮在JVM或服务器显存中
