做更好的游戏服务器

基础环境整理

基础环境定义：

1. 包含依赖框架以及基础设施（网络通讯，心跳机制，基本管理工具等），与具体项目无关。

2. 包含开发过程中使用到的工具，比如代码生成工具,项目构建脚本等。

3. 具备一套基本的说明文档。

   1. 项目目录结构介绍，特殊配置文件的介绍
   2. 使用到的工具介绍和使用说明，比如代码生成工具的使用说明
   3. 配置文件的每个配置项的介绍
   4. 代码架构的基本介绍，架构图，执行流程等。
   5. 功能扩展点的位置，比如添加玩家信息的位置，增加持久化类的位置，添加新协议方法，开启内部通讯的配置方法，开启支付模块的配置方法等。

基础环境的用途：

1. 开始一个新项目时，直接copy一份过来，往上加东西就能用。
2. 新人培训时，copy一份直接用作练习使用。
3. 增加新的功能时，以基础环境为起点进行开发。比如增加ip过滤功能，直接在基础环境的基础上开发，而不是直接在某个项目中增加，避免其他模块的干扰，提高效率。

开发阶段辅助功能

当我们进行开发的时候，应该适当的考虑一下做点额外的但是可以提高开发效率的功能。

依然从自身举例:
我们目前开发一个新功能的时候，客户端，服务器分别完成，然后再进行联调。这时客户端出现了一个问题，某个协议返回值不对，或者没有返回。客户端需要服务器人员进行配合。服务器人员会看日志，打断点，或者加输出。其实这时客户端人员需要的只是明确的知道服务器收到和发出了哪些协议，内容都是什么。
于是我想，服务器其实可以做一个功能，专供开发时期使用。比如提供一个页面，只展示200条最近收到和发出的协议及其内容，如果服务器有报错的话，也展示出来。这样的话，客户端人员在定位问题的时候就可以独自完成，并且很方便，效率会提升很多。

技术提升

游戏行业或者说整个计算机行业，技术提升是必须的。稍一不慎就会落后，落后就会被抛弃。这些有很多国际大公司作为前车之鉴，就不赘述了。

对已使用的技术进行深度学习

就拿我们当前的游戏服务器来讲，我们用到了spring，hibernate，memcache等。
但是这些技术，大部分我们只是达到熟悉甚至只是了解的层度而已。
开发人员的大部分时间花在了游戏业务上（当然我不是说这样不对），对技术本身的提升根本不重视，甚至公开表示不重要。

我们用这些技术的原因是什么，是因为他们给我们带来了便利，但我们只是用了它20%的功能，带来了20%的便利。为什么我们宁愿抛弃剩下80%的便利，也不愿意多花点时间去深入一下呢。
还有一点，任何技术都是有风险的，掌握程度越是低，风险越大。现在没出问题只是幸运，如果在关键时刻出了问题怎么办。大部分问题在不深入了解原理的情况下都是难以解决的，甚至是毫无头绪。比如我们之前遇到的一个问题：在数量很大的情况下，会出现个别数据没有写入数据库，最后我们认为可能是hibernate的一个bug，并且没有给出解决方案，变成了一个将会一直遗留下去的问题。其实我对这个结果是很怀疑的，作为一个流行的开源库不能说没有bug，但是大部分情景下的问题都是我们自己造成的（或是使用方式不正确，或是对问题定位不准）。

不管什么原因，我们之前选择了这些技术，并且一直在使用，那就应该将其掌握透彻。

对新技术进行研究和测试，在适当的时机进行升级

讲到技术提升，除了把正在用的掌握好，还有就是不断了解新的技术，新的工具。最简单的方法就是看看同行们都在用什么，然后去研究下适不适合自己。
再拿自身来讲：
我们目前用到了memcached，可以去了解下Redis，研究下，做下测试比较。
我们目前用到了hibernate，同样的持久框架有spring jdbc，mybatis等，并且我们业务上db只是简单的插入和单表查，其实完全可以使用更轻量，更简单的spring jdbc来代替。

有人会讲，游戏服务器，选一套框架一直用下去，这样最稳定。但是它能否适应更大的流量，更高的并发，更快的要求呢。不管怎样，我们要多做储备，以免措手不及。

客户端模拟器

模拟客户端给服务器发协议的工具。
工具用途：

1. 模拟客户端，方便服务器开发完功能之后先行自测。减少部分与客户端开发人员沟通的时间。
2. 扩展之后用作压力测试工具，对服务器的并发能力和部分模块的计算性能进行测试。

框架本身的log

我们会记录下很多业务相关的log，玩家获取装备，获取金币等等。
同样的我们也要记录下框架本身的一些log，比如：

1. 一些数值，当日总的协议量，出异常的协议量等，便于后续的一些分析
2. 运行过程中所有线程的未捕获异常，便于对未知的错误进行定位，对业务功能进行完善。

……
这些信息要做到可视化，尽可能方便的让人查看和归纳。
正常情况下这些信息我们都是记录到log文件中的，但是大家有很少主动的去查看log，除非是出了问题。并且log查看起来有不方便。

硬件需求量化

根据已开发的功能，结合计算和前期运维经验，量化出单个玩家在线所消耗的内存和cpu，大概值就行。
方便运维根据玩家数量对服务器的配置进行选购或者调整，而不是完全凭主观讨论决定。

令人信服的质量报告

我们的框架很稳定，几乎没什么bug。
我们的框架性能很好，能支持很高的并发。
……
光说是无法令人信服的。我们为什么相信那些开源的项目，因为他们有足够的测试用例，并且有足够多的人在使用，在帮助它变的更完善。
我们是不是也应改增加一些单元测试，增加一些专业的并发测试报告呢。