1.6　一张地图的极限

我们已经知道怎样编写分布式程序（见1.4节），也知道了程序运行的底层原理（见1.5节）。如果不考虑程序实现的复杂度（即1.4.4节提到的各种异常情况处理），不考虑硬件成本，只要搭建好分布式系统，就能支撑无数玩家。

但现实依然是残酷的！

手机游戏的多人组队对战，多数是3V3、5V5，这是为什么呢？MMORPG要分区、分服务器，每个场景能容纳的人数依然有限，这又是为什么呢？

1.6.1　难以分割的业务

实现分布式程序的前提是游戏逻辑能够分割。如果游戏规则复杂，各个功能紧密相连，则不容易找到分割的方案。图1-24是一款策略游戏的截图，在近乎无限大的地图上，玩家可以控制多支队伍在任何地点与其他玩家的队伍作战。

请思考一下，如果让你设计这样一款游戏，怎样让一张地图支撑几千上万的玩家（按照1.3.2节的分析，单个场景只能支持几十名玩家呢）？这是一个贯穿全书的问题。

如果没有很明显的分割方法，部分功能依然要靠单点的性能支撑，比如开房间对战类游戏的每一个房间、MMORPG的每一个场景等，那么单点（单个进程、单个线程）的运算能力依然会限制服务端的承载量。为了提高性能，一些服务端逻辑依然要用C/C++编写，Skynet提供了这种能力。

图1-24　策略类游戏示意图

1.6.2　在延迟和容量间权衡

多个程序协作意味着消息延迟。回到图1-14的全服聊天，聊天消息需由场景服务器发送到聊天服务器上，再由聊天服务器上转发到各个场景服务器上，每一层转发都需要时间。对于聊天功能，消息延迟几毫秒不会有任何影响，但某些功能对消息即时性要求很高（比如帧同步，第8章会介绍），因此需要权衡增多一层转发的代价。