posts
在线联机原型第 34 章导航：联盟战争
本章把「几百人同时打一场跨服战争」压缩成一个可验证的分布式问题：战场按 Shard 切分后，各分片如何独立推进战斗、战斗日志又如何聚合回一张全局战报。本页给出第 34 章联盟战争（Alliance War & World Conflict）的定位、六个核心验证目标（Shard 分区、战斗日志聚合、跨分片结算、成员权限与指挥链、断线续战、战报一致性）、推荐技术栈与真实文章入口，并串起前后相邻章节与相关专题。
第 34 章是「在线联机原型全集」里第一个真正意义上的分布式战场：同一场战争可能牵涉多个服务器、上千名玩家、持续数天的推进过程。它要验证的不是战斗手感，而是分区与聚合——把一个大战场切成若干 Shard 各自推进，再把这些分片的战斗日志汇总成一份所有人都认可的战报。这一章适合已经完成跨服战与联盟建设、准备把「服与服之间打一场」做成长期玩法的团队，也适合想用游戏场景练分布式一致性的后端工程师。
本章定位
| 项目 | 内容 |
|---|
| 全集层数 | 第 4 层（概念原型层） |
| 难度梯度 | 高阶。涉及分区分服、跨分片结算与日志聚合，建议先完成第 22 章公会建设、第 23 章跨服战与第 33 章社交关系 |
| 前置章节 | 第 12 章团队占点、第 22 章公会建设、第 23 章跨服战系统、第 33 章社交关系与好友推荐 |
| 后续章节 | 第 52 章自演化政治系统、第 53 章自组织联盟与自治经济、第 55 章多宇宙桥接 |
| 原型代号 | proto-34-联盟战争 |
| 形态 | 分布式战场型，单篇文章的完整 PRD，覆盖架构、状态机、接口与验证清单 |
这一章最关键的取舍是「分片边界画在哪里」：按地图格、按联盟、还是按战场阶段分。边界一旦确定，后续的日志聚合与结算方式就基本被锁死。
核心验证目标
| 验证点 | 要回答的问题 | 判定标准 |
|---|
| Shard 分区 | 战场如何切分，玩家与实体如何路由到分片 | 跨分片实体无重复、无遗漏 |
| 战斗日志聚合 | 各分片的日志如何合并成全局战报 | 聚合结果可重放，与各分片原始日志一致 |
| 跨分片结算 | 联盟积分、领土归属如何跨分片计算 | 结算幂等，重复触发结果不变 |
| 成员权限与指挥链 | 盟主、指挥官、成员的权限如何同步到各分片 | 权限变更在秒级生效且不可越权 |
| 断线续战 | 玩家掉线重连后如何回到原分片与原状态 | 重连后战场状态与掉线前一致 |
| 战报一致性 | 不同客户端看到的战报是否相同 | 同一战报在所有端呈现一致 |
技术栈建议
- 语言：Go、Rust、Python 三者任选，分片服务与聚合服务建议用 Go 或 Rust。
- 协议：WebSocket over HTTPS 承载实时战场指令，gRPC 承载分片间调用与日志上报。
- 存储：Redis 保存战场热状态与分片路由表；PostgreSQL 保存联盟、领土与结算结果；对象存储或日志系统归档战斗日志，供回放与审计。
- 消息：Kafka 承载战斗日志流，聚合服务按战场 ID 分区消费，天然获得顺序保证。
- 可观测：分片负载、日志聚合延迟、结算差异告警、跨分片调用错误率。
本章文章
这篇文章内部按八个部分展开，阅读时可以直接跳到关心的那一段：
| PRD 小节 | 内容 |
|---|
| 一、概述 | 分布式战场的一句话定义与本章要验证的能力 |
| 二、核心玩法与系统目标 | 产品体验、功能目标与四类验证重点 |
| 三、系统架构设计 | Gateway、分布式战场 Service、State Manager、Event Bus、Persistence 五层划分 |
| 四、功能模块详解 | 基础通信、状态同步、输入校验、日志与监控 |
| 五、状态机与流程图 | 战场状态机与指令广播的时序图 |
| 六、事件与接口定义 | WebSocket 消息类型与 REST 会话接口 |
| 七、性能指标与优化 | 延迟、并发、吞吐、内存四项目标值 |
| 八、验证清单 | 可直接当作验收用例的五条清单 |
与相邻章节的关系
相关专题