BattleServer 架构概述
战斗服采用开房间的形式，以单进程模式运行。每个战斗服可管理 N 个房间，单个房间最多容纳 4 人。系统设定每个战斗服上限为 125 个房间，即每台战斗服最多承载 500 名玩家。
战斗服的核心功能是广播，广播量按房间数量计算。
战斗服管理器
战斗服管理器负责战斗服的分配与负载均衡，一个管理器可以连接 N 个战斗服。网关收到的所有加入房间、单人匹配、创建房间请求，均统一转发给战斗服管理器来处理。
管理器的负载基本思想是：优先使用缓存中的负载信息进行分配，只有在缓存不足时，才从缓冲区刷新到当前战斗服的最新负载数据。战斗服会定期将自身的负载量（人数与房间数量）上报给管理器。
当整个系统负载极高时，缓冲区与非缓冲区之间的交换会变得非常频繁，性能大约下降 2 倍。这种设计允许出现少分配的情况，但不会给战斗服过度分配，这在架构设计上是允许存在的。
游戏匹配与房间流程
游戏提供三种进入方式：单人匹配、创建房间、加入房间。
单人匹配
单人匹配分为加入匿名房间和创建匿名房间两种情况，具体走哪条路径由战斗服直接决定，无需管理器干预。
开黑房间
创建房间时，系统会为该房间分配一个全服唯一的房间号，称为"开黑房间"。开黑房间只能通过房间号加入，不允许匿名进入。管理器分配房间号后，会与战斗服进行二次确认：确认该房间可用后，才将战斗服信息和房间号返回给客户端。
负载算法
负载计算参考两个维度：房间数量和可加入玩家数量。对于开黑房间，由于不允许匿名加入，系统直接将其预处理为最大房间人数来参与负载计算。
管理器启动时，负载初始值设为满负载。这样做的目的是：
- 能够及时获取到最新的负载信息；
- 支持战斗服动态扩容——等战斗服的信息同步过来后，才切换为真实负载，然后开始正常分配；
- 即使管理器宕机重启，也能尽快恢复到宕机前的状态，避免给战斗服过多分配负载。
性能表现
这种负载分配方案的速度非常快。在 15 个战斗服、7500 人同时在线战斗的设计容量下，战斗服管理器单核 CPU 使用率不足 20%。