如果是同等用户规模，相对来说，游戏服务器的复杂程度要大于普通app和web服务器。当然涉及到特殊算法的服务器另说，比如搜索引擎、头条人工智能推荐这些除外，在这里只说普通的。
游戏服务器根据不同的游戏类型有很大的区别，如王者荣耀之类的MOBA手游，服务器主要由2部分构成，局内战斗服务器和局外系统服务器。
局内战斗服务器程序是游戏专用的，在其他app服务器上几乎没有使用场景，在技术方面是有鸿沟的，也就是说你在开发app服务器上使用的技术以及设计思路，是无法转换为局内战斗服务器设计思路的，两者之间存没有相同点。
战斗服务器需要做到给各个玩家数据同步，也就是说，在一局游戏内，所有玩家的实时状态都要相互可见。这其中又设计到2种技术，帧同步和状态同步。
帧同步服务器不包含游戏逻辑，就是简单将客户端发送过来的命令转发给其他客户端，比如玩家A执行一个公鸡操作，那么玩家A客户端会给服务器发送一个公鸡命令，服务器将这个命令同步给局内的其他玩家，至于公鸡一下少多少点血，会不会把人打死，服务器不管，全部由客户端完成计算判断，客户端计算完毕后将结果发送给服务器，服务器再将结果同步给其他玩家，然后客户端播放表现效果。简单的说帧同步服务器就是给各个游戏客户端同步数据，它会不间断的发，即使局内的玩家什么都不干，傻傻的站在那里，服务器也会发，他的作用就是同步玩家们的状态，所以说帧同步服务器费流量。
状态同步服务器和帧同步服务器的区别在于，除了同步玩家状态的机制相同外，状态同步服务器包含游戏的运行逻辑，比如玩家之间互相公鸡、技能伤害大小计算，都在服务器上执行，然后再将执行结果同步给客户端，客户端只要根据结果播放对应的动画就可以了。
简而言之，帧同步服务器和状态同步服务器的区别就是游戏局内游戏逻辑放在哪儿运行的问题。因为要运行游戏逻辑，状态同步非常消耗服务器资源，如果代码写的烂一点，一台4核8G的机器上只能跑10局游戏100个玩家，那么要是同时有10万玩家在局内，就需要1000台服务器，这么多服务器，运维管理压力非常大。因此使用帧同步服务器能有效的减少服务器消耗资源，减少服务器数量。然而有缺点就有优点，因为业务逻辑在客户端，帧同步服务器很难有效的杜绝歪瓜问题，断线重连也相对费劲，用户体验差。而状态同步则不存在这种问题，能有效的杜绝歪瓜，也能很容易的支持重连进入游戏。所以这两种技术各有优缺点，选择哪一种，需要根据实际情况权衡。
普通的web服务器或者app服务器十有八九使用基于tcp的http协议，而局内战斗服务器，普遍使用UDP。TCP是可靠传输协议，用起来省事，确认机制、丢包重传、滑动窗口之类机制开销也大，在极端性能敏感的场景下，裸奔的UDP更加合适，通过UDP实现一个lite版的TCP，是游戏战斗服务器常规的优化手段。
不过话说回来，看起来局内战斗服务器实现有很多门道，但是工作量其实非常少，属于做好一次到处通用， 即使状态同步，虽然业务逻辑跑在服务器上，但实际功能开发还是客户端程序员实现，服务器只是提供了一个运行程序的容器，战斗逻辑的实现不归服务器管。
再说说局外服务器，这部分和普通的web服务器和app服务器就比较像了，MySql、Redis、protobuf、消息队列、分布式框架等等互联网应用的基础架构在游戏服务器上也是常规配置，不过有一点明显的区别是，游戏服务器的数据存储都是以玩家为单位的，当玩家登录的时候，程序会将所有玩家的数据，如道具、装备、任务等所有相关数据从MySql等数据库中加载到程序内存，之后所有的操作都在内存中进行，之后等到某个适当的时机才会将内存中的数据同步到MySql中。当然，为了保证即使程序挂掉，数据也不丢失，还需要设计许多复杂的机制，这里就不展开了。
而web服务器和app服务器则不是这么设计的，因为游戏如果不登录是不可以玩的，因此我们可以把数据结构设计成以用户分组的。而web和app即使用户不登录，功能依然需要可以使用，功能和用户不绑定，所以设计的时候也不会把数据以用户为单位进行组织。不过除了数据组织方式不同外， 其他地方大致都相同，原本是做游戏服务器的，稍微熟悉下就可以去做web或者app服务器，反过来也一样，互相之间没有门槛。
不过从技术的角度出发，局外游戏服务器的技术相对与其他互联网行业是比较落后的，如果你原本是在传统互联网行业，转去做游戏服务器，可能会被雷到，因为他们用的框架一点也不”现代化“，也许框架的性能还不错， 但是开发效率极低。这一点和游戏客户端不一样，游戏客户端是脱离传统互联网技术的，他们有自己的技术栈，而且实时更新。比如unity、unreal引擎出新版本了，他们都会讨论的热火朝天，然后尝试升级使用，这和互联网行业的vue、react、spring更新一样，相关程序员都会热衷与研究。
但是服务器却没有这样的热点可以追，我在一家公司，这家公司虽然已经生产了几十个游戏，客户端引擎也不知道换了多少套，但是服务器程序却一点没变，仍旧使用祖宗流传下来的那套c++框架，里面什么都是手动实现的
比如数据传输协议，是自己组装字节流，发送给另一端，另一端根据事先定义好的规则，一个int，一个bool，一个float的读取。这对于理解网络的本质非常有好处，但是显然在实际应用中，使用protobuf会更好。
当然我也碰到过协议不自己实现而是使用protobuf的，而且使用的是java开发局外服务器，而网络底层仍旧使用java自带的NIO，而不是更好的netty。
总而言之，传统的游戏服务器程序不是太喜欢用框架，而是偏向于自己造轮子。这可能跟这个行业大量使用c++有关系，即使有一部分游戏使用java服务器 ，但是开发人员大多也是c++转过来的，还是以c++一切靠自己的思路在开发，所以很难见到流行的互联网框架在游戏服务器上使用。
游戏服务器不会只用一种语言开发，也可能是两种。如果是一种，那大概率是c++。如果是两种，那大概率是c++加另一种语言。
用c++的原因很多，如果要找一种语言，兼顾性能、开发效率、流行度，那肯定是c++。战斗服务器通常用c++开发，一来是速度够快；二来战斗程序通常需要同时在客户端和服务器上运行，要找一种跨平台的，还是要c++，比如unity种就可以通过c#调用c++。
局外服务器可以不用c++做，用java、go甚至php都可以，不过近年来用go好像越来越多了。
最后还有一个人员方面的区别，一个传统互联网项目，后端开发人员会多于前端开发人员。而一个游戏项目，客户端开发人员要比服务器开发人员多，可能一个项目服务器程序员只有3个，而客户端程序员有10多个。而且客户端程序员都很忙，而服务器程序员，在开发阶段，相对很闲，游戏上线后， 会忙一些。