背景

我做过六年游戏服务端开发，后来想换个方向，转做电商后端开发，做了两年之后感悟很多，也体会到了游戏服务器和普通的服务器的区别。

我所说的游戏是大众的游戏，它要有常见游戏的一些元素，比如交互，比如场景，比如对战。举几个例子：魔兽世界，梦幻西游，王者荣耀。
当然也有很多游戏是弱交互的游戏，其实这类游戏跟普通的服务器的区别会小一点。

其实游戏说到底，最重要的几点就是保持状态、低延迟、交互。这几点就让游戏服务器和普通的服务器（比如电商后端）区分开来了。

互联网和游戏后端开发的区别

游戏特有的

保持连接

游戏一般来说需要保持一个客户端到服务端的连接，可以对客户端的玩家的行为（移动，攻击，操作，互动，聊天）进行及时的反馈以及主动推送给场景内的其他玩家。所以游戏更多的使用TCP来保持客户端和服务端的连接。少量弱交互游戏使用HTTP，对延迟要求更高的游戏会使用UDP。

保持状态

服务端会保持一份玩家的实体，当玩家进行操作时，下次通信的数据会依赖之前的通信的数据。

服务端推送

游戏服务器由于保持连接和状态，任何数据的改动可以通过服务端主动通知客户端的方式，这样就只需要推送修改的数据。不需要客户端频繁去刷新。

低延迟

很多游戏服务器，尤其是 RPG，MOBA， FPS等游戏，对延迟容忍度非常低，网络不好的情况下tcp协议由于重传机制，拥塞机制导致非常慢，就需要重新设计协议来处理。

写频繁

游戏中的每一个操作都可能是数据，场景中移动、攻击、击杀怪物、伤害量、交易、经验增长等等。通常每一帧都有可能有数据的变更。所以游戏通常来说需要定时写数据，否则可能会有DB性能瓶颈（定时存盘机制）。而且游戏的数据库的设计很多都是反范式的。如果你网上搜梦幻西游的数据库设计，他们甚至直接存到文件里面的，没有用任何主流数据库。

交互

很多游戏是多人游戏，需要玩家交互，场景中移动，聊天，组队，击杀BOSS等等，都需要反馈给场景中的所有可视玩家。这个时候需要保持任何玩家之间都能及时的互动或者沟通，对服务器架构上的设计就有一定的要求。

复杂度高

游戏的核心是玩法，更是由于多人在线的游戏的玩法可以设计的很复杂，所以做游戏后端开发的业务复杂度比互联网高的，比如实现一个多人战斗系统，一个副本玩法等等。比如梦幻西游的回合制战斗，或者王者荣耀的战斗等等。而互联网的业务就相对简单的多了。

互联网特有的

请求响应

互联网应用一般只需要支持请求响应式的通信，最常用的协议是HTTP来做客户端和服务端的通信。互联网应用一般来说只用关心自己的行为，而不太关注其他用户的行为（即使关注，也没有实时的响应需求），请求响应模式是最适合普通的互联网服务器的一种通信模式。

无状态

互联网的应用一般是无状态的，也就是下次操作不会保存上次的状态，每次进行不同的操作，都需要服务端进行完整的数据读取操作，无法利用上次请求的数据。

服务拆分

互联网是比较容易做服务拆分的，比如现在很多的微服务架构，因为业务相对独立，交互弱，做成微服务架构，通过请求响应去其他的微服务取得需要的数据。

读频繁

互联网一般是一个读频繁的场景，需要大量的读取数据，只有特定的行为才需要写入。要考虑一定的缓存机制，对数据库的设计要求更高。

延迟容忍

可以容忍一定的延迟，用户感知不明显。20毫秒还是200毫秒，用户是感觉不到的，但是如果是玩王者荣耀这类游戏，基本上你都感觉得到。

业务简单

互联网的业务说到底就是增删改查。（当然1000用户的增删改查和10亿用户的增删改查不一样）。高并发不属于业务的范畴，我现在处理百亿级数据和千万级QPS的服务，主要考虑高并发下的服务的拆分，架构的设计，微服务化，数据分库分表，缓存设计，异步存储，热点处理等等一系列高并发下的性能考虑。但是仅仅业务本身的复杂度相对游戏真的低很多。

总结

以上就是一个同时做过游戏开发和互联网开发的程序对这两个的区别的一些总结。

我做游戏的时候主要关注的是业务的玩法方面设计一个复杂的玩法需要考虑很多，需要了解的是玩法的设计。
做互联网的时候，主要关注的就是数据的操作，往往高并发最终的瓶颈会落在DB这一层，怎么优化DB就很重要，比如我说的分库分表，索引的设计，缓存的设计，预热机制，热点数据的处理等等。

<全文完>