游戏服务器开发实际上并不比Web服务器复杂，都是为客户端的网络请求提供服务。本质上游戏服务器是基于长连接的Socket服务器，相比Web服务器来说，游戏服务器在逻辑复杂度、消息量、实时性等方法要求更高。
游戏运行架构与Web应用运行架构比较有什么异同点呢？
| 游戏运行架构 | Web运行架构 |
|---|---|
| 前端服务器 | Web服务器，如Apache/Nginx |
| 后端服务器 | 应用服务器，如Tomcat |
游戏运行架构与Web应用运行架构的区别
- 复杂的Socket服务器
可以将Web服务器作为一个HTTP服务器来看待，而将游戏服务器作为一个原生的Socket服务器。游戏服务器是通过Socket通讯来处理服务器与客户端之间的交互，因此许多游戏服务器直接基于原生Socket（即TCP）来实现。
相比简单的Socket服务器，游戏服务器的任务更为繁重，主要体现在
- 后端服务器必须处理极其复杂的游戏逻辑
- 网络流量更大且实时性要求更高
- 通常会使用集群提供服务以提高并发量
- 长连接与实时性
Web服务器使用基于请求/响应的短连接模式，游戏服务器使用长连接，因此Web服务器所持有和需要的资源远远要少于游戏服务器，基于HTTP使用短连接可以大大提升Web服务器的伸缩性。
Web服务器可以使用短连接是因为
- 单向通信：典型的Web应用程序只需支持拉取模式
- 低实时性要求：一般而言，Web服务器在3秒内做出响应就不会明显影响用户体验。
而游戏服务器只能使用长连接的原因是
- 双向通信：游戏服务器不仅需要拉取模式还需要支持推送模式，更重要的是服务器推送的数据量哟啊远远超过客户端拉取的数据量。
- 高实时性要求：一般来说，服务器推送消息或响应客户端请求的事件应该小于100毫秒。
长连接与短连接
Web应用使用基于HTTP的短连接以达到最大的可扩展性，游戏应用采用基于Socket（WebSocket）的长连接以达到最大的实时性。
- 分区策略和负载均衡
一般来说Web应用之间没有交互的概念，所有用户之间的交互式平等的。在Web应用中交互频率与用户的地理位置无关，而在游戏应用中则相反。游戏服务器中，玩家的交互频率与玩家的位置或区域密切相关。比如两个相邻的玩家会相互攻击或组队来攻击怪物，他们之间的交互会非常频繁且实时性要求很高。这也意味着两个玩家需要被分配到同一区域服务器进程中以减少跨进程的成本。因此，游戏应用应该根据区域的不同而有一个分区策略，这也是与Web应用的不同之处。
服务器进程可能位于一个区域或多个区域，因此游戏服务器的可伸缩性受区域的限制。如果一个区域太忙超出了它的容量，那么整个游戏服务器就会被阻塞或关闭。区域服务器是有状态的，来自特定玩家的请求必须发送到同一区域服务器。有状态的服务器会带来很多问题，会导致该区域服务器在可扩展性和可用性方面不如Web服务器。通常，必须通过隔离游戏服务器来缓解这些问题。
Web应用的分区可根据负载均衡自行决定，游戏则是基于场景的分区模式，这使同场景的玩家跑在一个进程内以达到最少的跨进程调用的成本。
- 可扩展性和分布式
无论是Web应用程序还是游戏应用程序，可伸缩性都是最重要评估指标之一，同时也是要解决的难题之一，会涉及到运行架构及各种优化策略，可以通过一个可扩展设计，以保证在线玩家数量以及响应时间。在传统游戏服务器的架构中，会使用一个单进程模型来处理所有逻辑。在这种架构下线上没有大量玩家时可以使用。但随着玩家数量的增加，会带来巨大问题。因此，分布式、多进程的游戏服务器架构就称为必然的选择。
Web服务器可以通过单个负载均衡器将请求重定向到任何进程，因此它的运行结构相对简单，也很少需要分布式。而游戏服务器使用了蜘蛛式网络架构，每个进程都有自己的职责，这些进程又相互交织在一起完成一项任务。因此游戏服务器是一种典型的分布式体系结构。
有无状态
Web应用是无状态的，可以达到无限的扩展。游戏应用是有状态的，由于基于场景的分区策略，游戏的请求必须路由到指定的服务器，这也使游戏达不到Web应用同样的可扩展性。通讯方式
Web应用基于请求响应模式，游戏应用则更为频繁的使用广播，由于玩家在游戏里的行动要求实时地通知场景中的其它玩家，必须通过广播的模式实时发送，这也使游戏在网路通信上的要求高于Web应用。
游戏服务器的难点
由于游戏服务器采用了蜘蛛式网路架构，这也给游戏开发带来了一些困难。
- 实时性保证
对于单个游戏服务器来说会包含一些实时性任务包括
- 实时tick
通常游戏服务器需要定时tick来执行定时任务，为了实现实时的行为，这tick定时器会在100ms。这些任务一般包含以下逻辑：遍历区域中的玩家、怪物等实体，并对它们进行一些操作，比如移动、复活、消失等。在区域中部分怪物被干掉后再定时制造一些怪物。定时的AI逻辑比如怪物攻击、逃跑等。
由于定时器间隔在100ms以内，所以上述任务的处理时间也应该控制在100ms以内。
2.广播
当一个玩家做某一动作后必须实时通知同一区域内的其它玩家，这时就需要广播，这也使得游戏应用的网路需求远远高于Web应用。广播在游戏中的开销很大，由于玩家之间输入输出信息的不对称，比如玩家只是稍微移动，服务器就要把这个动作传递给所有其它玩家，以使他们可以在同一个区域看到这个玩家。当一个区域内的玩家数量较少时，广播消息数量不多，但如果玩家数量达到较高水平时，广播消息数量将成倍增加。
比如：当某个区域中有1000个玩家，每个玩家做一个动作，服务器需要通知区域内的所有玩家，这时广播的消息将达到10000000个，足以阻塞服务器而放弃其它任何操作。
- 分布式
分布式开发是困难的
- 多进程服务管理
游戏服务器通常采用多进程模型，这些进程之间又会有交互，因此这些进程的管理是非常困难。如果没有对服务器进程统一抽象和管理，在开发环境中启动这些服务器会非常复杂，也会影响开发效率。更重要的是，重量级进程消耗了大量的机器资源。一般用于开发的服务器无法承受这么多处理，而多服务器又会带来进程间调试的困难。
- RPC远程过程调用
RPC调用方案虽然已经出来很多年，但开发效率仍没有显著提高。当所定义的接口发生改变时，在不稳定的开发环境中，RPC调用方式会严重影响开发效率，因此需要更为灵活的方式。
- 分布式事务 & 异步操作
尽管视图将相关逻辑放到一个进程中，分布式事务仍然是不可避免的。在使用普通编程语言时，分布式异步提交操作不是一件很容易的事。
- 负载均衡 & 高可用
由于游戏服务器是具有状态的，所以特定玩家的请求需要通过路由规则路由到同一服务器，可以很轻松的将请求路由负载到无状态Web服务器，而对有状态的服务器，使其高可用是非常困难的。实现的两种方式：
- 将状态保存在外部存储中：比如可以将玩家状态信息保存在Redis或类似存储中，这样服务器就不再需要状态，从而变成无状态的。但这状态相关操作将会经过Redis也会导致性能的损失。
- 服务器冗余：服务器的状态可以通过日志备份到另一个冗余服务器，但服务器切换时可能会出现短暂的数据丢失问题，并最终导致数据的不一致。
- 原生Socket开发中的问题
可以基于Socket进行开发但使用原生Socket也会带来一些问题：
- 低级抽象：低级的Socket抽象不易用，许多处理机制需要由开发人员来实现，比如Session、过滤器、请求、广播等。
- 可伸缩性：可伸缩性取决于多方面，比如消息密度、存储策略、服务器架构及其他因素。如果需要提高原生Socket的可扩展性，开发者需要在架构设计上耗费大量精力。
- 服务器监控管理：服务器状态监控很必要，比如消息密度、在线玩家数量、机器状态、网络压力等，如果使用原生Socket会存在很大的工作量。
