【SLG游戏服务器开发手册】沙盘地图的Scale设计

Scale是我们的设计目标，通常我们说一个系统“能不能scale”，就是在评价他应对负载增长的能力。

我们将从 Zoning（分区） 和 Offloading（卸载） 两个维度来详细探讨SLG游戏服务器地图的Scale设计。

---

核心挑战：SLG游戏的独特性

1. 超大地图与全局性：一张无缝世界地图上可能有数万甚至数十万个格子（Hex/Tile），所有玩家都在同一个全局环境中交互。
2. 异步交互为主：大部分交互（行军、采集、攻城）是异步的，操作发出后需要经过现实时间才能完成。这与MMO的实时同步有本质区别。
3. 热点事件：联盟集结、攻占关卡等行为会在短时间内让数万玩家聚焦于一个极小的地图区域，产生巨大的读写压力。
4. 状态持久化：地图上每一块地的归属、资源等级、城防值等都是需要持久化且频繁变更的状态。

传统的单服务器或简单分线模式无法应对这些挑战，因此必须采用分布式的 Zoning 和 Offloading 策略。

---

一、Zoning（分区）设计

Zoning的核心思想是“分而治之”，将整个大地图水平分割成多个不重叠的区域（Zone/Shard），每个区域由独立的服务器进程（或微服务）来管理。这是最主流、最基础的Scale方案。

常见的Zoning策略：

1. 静态地理分区 (Static Geographic Zoning)

   • 设计：将世界地图预先划分为固定的、大小相等的网格（例如 100x100 的格子为一个Zone）。每个 ZoneServer 负责管理一个或多个这样的固定区域。
   • 工作原理：
     • 玩家操作（如移动部队、采集）只由其部队所在格子的 ZoneServer 处理。
     • 跨Zone的行军被拆分为多个阶段，由不同的 ZoneServer 接力处理。一个主服务器（如 WorldServer）或网关来协调跨Zone操作。
   • 优点：
     • 简单直观，易于实现和管理。
     • 负载均衡容易，可以预先根据地图活跃度分配服务器资源（例如，边缘区域的Zone可以合并到一个进程）。
   • 缺点：
     • 热点问题：当一个Zone内发生大规模战斗（如皇城争夺）时，负责该区域的单个 ZoneServer 可能成为瓶颈，无法Scale。
     • 跨Zone交互复杂，需要引入协调层，增加了延迟和系统复杂性。

2. 动态负载分区 (Dynamic Load-Based Zoning)

   • 设计：分区不是固定的，而是由一个主控服务器或协调服务（如Kubernetes）根据实时负载动态地将地图区块分配给可用的 ZoneServer 实例。
   • 工作原理：
     • 启动时，地图区块未被分配或平均分配。
     • 监控系统持续收集每个区块的负载（实体数量、事件频率）。
     • 当某个区块负载过高时，协调服务可以将其拆分为更小的单元，或将相邻的低负载区块合并，并迁移到新的 ZoneServer 上。
   • 优点：
     • 弹性伸缩，能更好地应对热点和流量波动，资源利用率高。
   • 缺点：
     • 极其复杂，需要实现复杂的负载监控、状态迁移和服务发现机制。
     • 状态迁移期间可能会带来短暂的服务不可用或延迟。

Zoning架构的技术实现（Java为例）：

• ZoneServer：一个独立的Java进程（Spring Boot应用），负责其分配区域内的所有逻辑：行军Tick、战斗计算、资源再生、地图事件等。它持有区域内实体的内存状态。
• WorldManager：一个中心管理服务，维护全局地图视图、Zone分配表、路由信息。所有需要全局视野的操作（如远程侦查、全图搜索）都通过它路由。
• 数据库：使用 分片（Sharding） 数据库。通常按照 ZoneId 进行分片，每个Zone的数据存储在独立的数据库分片上，完美匹配服务器架构，避免数据库瓶颈。

// 简化的路由示例：网关收到客户端请求后，如何路由到正确的ZoneServer
public class GatewayService