在一间游戏公司的两个部门待过， 前一个部门以做web开发为主，后一个部门做游戏开发，我在两边都是做后端的。

在游戏部门待的时间不长， 不敢说已经深入了解游戏开发技术细节，我仅把我已经接触到的内容与之前擅长的web技术做对比，一来作为工作日志记录， 二来希望能给想从web转游戏的同学提供一个预先学习的方向，少走一些弯路。

这一系列内容我会连载发布，而不是一次性讲清楚所有内容， 毕竟当前还不敢狂妄的表示已经了解游戏开发的种种细节。

通用性

即使不同类型的软件开发也是具有一定相似性的，这种相似性随软件类型的不同而不同。 如web前端开发与web后端开发差异就挺大， 前端程序运行在浏览器中，后端程序运行在服务器上；前端程序操纵的目标是网页元素，后端程序操纵的目标是存储在服务器上的数据。前端和后端相似的地方估计也就编程语言使用的一些基础概念了，所以前后端程序员岗位转变存在一定难度，比如让一个没有任何后端经验的前端程序员立马上手写后端程序，几乎不可能。

然而web服务器和游戏服务器的差异就没这么大了，它们用的是相同的编程语言， 比如说java；它们用的是相同的数据库软件，比如mysql和redis；它们都运行在服务器端，比如linux server和windows server，且对稳定性要求及其严格。拥有这几处相同点两种程序在宏观上是完全相似的，对应程序员工作的转换也不存在硬性的技术障碍， 如果程序员技术基础扎实，完全可以平滑过渡。

差异性

因为业务的不同，web服务器和游戏服务器势必存在不同之处，然而这种不同并非技术上的不同，而是套路上的不同。

服务器类型的不同

web程序使用http服务，浏览器和服务器之间是http协议通信。游戏服务器通常是一个socket服务器，与游戏客户端之间保持长连接，如果是网页H5游戏，那么使用的也是全双工的websocket协议。通常，使用http协议的web服务器不用程序员费事去管理网络连接，程序员只要专注业务逻辑即可。而使用socket或者web socket等协议进行长连接通信却需要程序员手动编程管理，比如说断线重连游戏状态恢复机制，就需要手动处理网络连接。这表示socket编程难度大于http编程，从而导致游戏服务器编程大于web服务器编程。可这并不能表示游戏服务器编程不同于web编程， 如果一个web程序员不了解socket编程原理，那也不能算一个优秀的web程序员，毕竟http是以socket为基础的。

传输数据格式的不同

在web前后端传输数据除了使用http标准的键值对格式以外使用最多的是json，json被使用的一个最重要的原因是与JS无缝兼容，高效方便。然而，这种优势在游戏客户端中不存在，人家游戏客户端又不使用JavaScript编程，所以游戏客户端和服务器之间有更合适的数据传输时格式存在。

我接触到的是谷人希家的protocol buffer协议， 它相对于json的优点是

• 体积小。经我测试，同样的数据内容，使用protocol buffer格式存储大小只有使用json存储的三分之一甚至更低，即使在某些特殊情况下也不会超过json的一半。

• 严格验证数据格式，有xml xsd的功效。而json数据格式验证相对宽松，只要符合json语法就行，因此容易出错。反之，protocol buffer则更加稳定。

至于缺点最严重的是使用麻烦， 需要借助谷人希的第三方工具才行。

protocol buffer的使用细节，这里不作讲解。

分布式处理业务

我接触到的游戏服务器是微服务的一种形态， 整个游戏服务器的逻辑被分割成很多服务模块，分别运行在不同的服务器上。然而，我无法理解的是每个模块之间的通信居然使用socket，而不是更流行的http。游戏客户端与服务器之间使用socket连接可以理解， 然而，服务器各模块之间也使用socket却有些使我莫名其妙，虽然这会使服务器之间通信性能有所提升，却会带来编写代码任务过于复杂，稳定性下降等问题，为了些许性能提升而丧失项目的维护性，有点得不偿失。 不过也有可能我还没有理解其中奥秘，判断过于片面。

极端的性能敏感

游戏中实时对战模块必须使用c/c++实现，原因是JVM执行垃圾收集时会造成虚拟机停顿，也就是stop the world。在虚拟机技术发展日新月异的今天， gc停顿依旧会对游戏体验造成影响，因而必须使用老掉牙的c++， 这使我感到震惊。

另外， 游戏中大多数数据被放在redis中而非mysql也使我意外，数据持久化存储显然不是redis的优势，拿性能换稳定和安全，这种做法略显激进。

以上内容是我当前对于web开发与游戏服务器开发不同之处的见解，如有谬误请指出。 此外，在之后的学习和实践中的心得体会，会在之后的文章中继续发布。