旨在处理所有来自客户端的通讯：所有“那个玩家有没有连接上”这种讨厌的问题，所有客户端到服务器的数据加密（如适用），所有这些密码等等，所有相对奇怪的reliable-UDP协议（如适用），当然还有客户端与不同游戏服务器之间的路径选择信息——这里处理着所有客户端的通讯。
在需要时会存储相关游戏世界的副本，并在游戏世界升级时扮演集中器（concentrator）的角色。

前端服务器必须能够在不对玩家造成重大不便的情况下就能简单更换。

客户端随机平衡（针对前端服务器）运行良好，没必要改用其他的。DNS负载均衡几乎普遍不如客户端均衡，而基于硬件的服务器端均衡器太过复杂与昂贵，一般没必要在游戏环境中使用。如上所注，可能需要服务器端均衡器的例外情况在于使用基于Web的部署架构时。

根据经验法则，前端服务器是个好东西。尤其是：

• 减轻了游戏服务器的负载；
  • 让系统设备价格更低（因为前端服务器比较便宜）；
  • 也提高了整体系统的可靠性（因为前端服务器很容易更换）；
• 促进了单一客户端的连接（一般来讲是好事）；
• 促进客户端负载均衡；
• 出现大事件时，接待10万+的观看者变得很简单（事实上没有限制）；
• 缺点仅限于额外延迟，而这种延迟一般都在亚毫秒级别；
• 一般对于游戏来说，客户端负载均衡是最好的选择：
• 唯一可能的例外是基于网络的部署架构——可能需要服务器端均衡器；
  需要避免大规模关联。

一般对于游戏来说，客户端负载均衡是最好的选择:

• 唯一可能的例外是基于网络的部署架构——可能需要服务器端均衡器；
• 需要避免大规模关联。

使用DNS负载均衡时要格外小心。换句话说，客户端随机平衡对于游戏效果更好，因为同时在线的玩家数量会从几百增长到成千上万；运行起来几乎没有问题，始终提供几乎完美的平衡体验。也就是说，如果整体的平衡负载是50%，事实上有些是48%，而有些是52%，但不会超过这个数字。

对于游戏负载均衡来说，服务器端负载均衡设备实际用途不大。即便你使用了基于网络的部署架构，也应当避免使用服务器端负载均衡器。

时间一再证明：网络，无论是本地网络还是广域网络，常常都是不可靠的，而且常常是异步的。因此，这对分布式系统的设计造成真实而重大的挑战。

这些结果的潜在影响不仅限于学术圈，而是激发了众多系统和设计的出现，为网络失常的情况下提供了多种保障。

开发人员：我们需要快速消息机制。

我：如果消息偶尔丢失了可以么？

开发人员：什么？当然不行！我们需要它是可靠的。

我：好吧，我们会加入一个提交应答，但如果你的应用在处理消息之间就崩溃了，怎么办？

开发人员：我们会在处理之后发送应答。

我：如果你的应用在处理之后发送应答之前崩溃了怎么办？

开发人员：我们会重试。

我：所以重复发送是没问题的？

开发人员：呃，应该只发送一次。

我：但是你希望它能很快？

开发人员：是的。对了，它还应该保证信息的发送顺序。

我：你可以用 TCP 协议。

与其使用多层而且过于抽象的方式来隐藏复杂性，我们更应该直接在设计决策中考虑这些问题，并从头到尾加以思考。想在分布式系统上达到心平气和的境界，要走过漫长而曲折的道路，但是最佳起点，就是从头开始。

第一范式：电动机械计算机

第二范式：继电器式计算机

第三范式：真空管计算机

第四范式：晶体管计算机

第五范式：集成电路（摩尔定律）

随着这些指数级发展不断继续，我们会开启不可估量的生产能力，并开始理解如何解决世界上最具挑战性的问题。从未有哪个时代像现在这样更令人兴奋。