Q10: 如何实现跨服功能（如跨服战场、跨服聊天）？
核心结论
“跨服”不是一个统一问题，而是至少四类完全不同的问题：
- 跨服消息互通
- 跨服关系互通
- 跨服匹配与房间调度
- 跨服交易与结算
它们对实时性、一致性、隔离性和恢复方式的要求完全不同，所以不能用一套架构全包。
更稳妥的做法通常是：
- 轻状态、弱一致的功能做中心服务或事件汇聚
- 强实时对抗功能做独立跨服玩法服
- 强一致资产类功能尽量避免“直接跨服互改”，而是引入中心结算或严格的补偿机制
一、先把“跨服”分型
很多讨论一上来就说“做一个跨服中心”，这通常太粗。
更合理的第一步是先分型。
1.1 消息互通型
例如：
- 跨服聊天
- 全服公告
- 跨服邮件通知
- 跨服活动广播
特点：
- 实时性中等
- 可接受轻微延迟
- 一致性要求通常不高
- 最适合做中心转发或事件广播
1.2 关系互通型
例如：
- 跨服好友
- 跨服黑名单
- 跨服组队
- 跨服公会或联盟
特点：
- 需要有统一身份和关系索引
- 一致性要求高于聊天
- 查询和写入都比较频繁
- 往往要有中心关系服务或统一关系存储
1.3 实时对抗型
例如：
- 跨服战场
- 跨服竞技场
- 跨服副本
- 跨服活动地图
特点：
- 实时性要求最高
- 运行时状态变化频繁
- 通常需要把参战玩家临时迁移到独立玩法服或战场服
- 不适合靠多个原服之间持续远程互调来完成
1.4 资产结算型
例如：
- 跨服交易
- 跨服拍卖行
- 跨服资源转移
- 跨服发奖
特点：
- 一致性要求最高
- 风险也最高
- 一旦出错就是刷资产、重复到账、回滚困难
这类功能通常最不适合“每个服直接互相改数据”。
二、跨服架构里最重要的设计决定
2.1 先决定身份是否全局唯一
如果跨服后玩家身份仍然只是“服内角色 ID”，很多功能都会变复杂。
通常更合理的是区分两层标识：
- 全局账号或全局玩家 ID
- 区服内角色 ID
这样做的好处是：
- 跨服关系更容易建立
- 中心服务更容易索引玩家
- 迁移和回到原服时更容易做映射
2.2 先决定谁是权威源
做跨服时必须先回答：
- 玩家资产由原服负责，还是由中心结算服负责
- 战场里的实时战斗状态由谁负责
- 好友关系由原服缓存，还是由中心关系服负责
如果权威源不清楚，后面就会变成：
- 谁都能改
- 谁都不敢认账
- 出问题无法追责和回滚
2.3 先决定是“数据跨服”还是“人跨服”
这两种思路差异很大。
数据跨服
原服不动，只把需要的数据同步出去。
适合：
- 排行榜
- 聊天
- 公告
- 关系查询
人跨服
把玩家临时送到跨服玩法服，玩法结束后再回原服。
适合：
- 战场
- 竞技场
- 跨服副本
- 实时活动地图
多数实时跨服玩法，本质上都更适合“人跨服”，而不是“多个原服一起远程协同一场战斗”。
三、一个更合理的总体架构
跨服系统更像“独立的上层域”，而不是所有原服之间两两互连。
原服 A ─┐
原服 B ─┼──► Cross Services
原服 C ─┘
Cross Services:
- Chat Service
- Social Service
- Match Service
- Battle Service
- Settlement Service
- Global Cache / DB / MQ
这样设计的原因是：
- 降低原服间网状连接复杂度
- 统一跨服协议和权限边界
- 方便独立扩容
- 方便统一监控和审计
不建议一开始就把每个原服都和其他所有原服直接互联，原因很简单：
- 连接关系会迅速膨胀
- 路由和权限难控
- 问题排查很痛苦
四、跨服聊天怎么做
4.1 更合理的目标
跨服聊天不是“让每个服直接互发消息”，而是：
- 由原服接收玩家发言
- 做本地鉴权、限流、禁言、敏感词过滤
- 再转给跨服聊天服务
- 跨服聊天服务负责分发到目标服
4.2 推荐职责划分
原服负责：
- 验证玩家是否能发言
- 本地风控
- 基础消息格式化
跨服聊天服务负责：
- 频道路由
- 广播分发
- 消息落审计日志
- 跨服限流和黑名单策略
4.3 为什么聊天适合中心服务
因为它通常具备这些特点：
- 消息体小
- 可容忍轻微延迟
- 不要求强事务
- 适合广播和订阅模型
所以聊天是最适合先做跨服化的功能之一。
五、跨服战场怎么做
5.1 最常见的正确思路
跨服战场通常不应该让多个原服的地图逻辑共同维护一场战斗。
更合理的方式通常是：
- 原服把玩家送入匹配
- 匹配中心凑齐对局
- 为该对局选择一个独立战场服或战场实例
- 玩家临时进入战场服
- 战斗结束后，把结果回传原服结算
5.2 为什么不能简单“原服互联打一场”
因为这样会立刻遇到很多问题：
- 谁是战斗权威
- 技能判定在谁那里做
- AOI 和广播谁来发
- 一方服卡顿是否拖累全局
- 中途断链如何恢复
对实时玩法来说，最稳的办法通常还是：
把一场实时战斗收敛到一个独立权威实例里。
5.3 战场服的职责
战场服通常负责：
- 战斗逻辑
- 对局内状态
- 对局内排行榜
- 对局结束结算结果
原服通常负责：
- 玩家进入前的准备
- 进入和回归
- 奖励落账
- 长期资产保存
5.4 最关键的边界
战场服最好不要成为玩家长期资产的最终权威源。
更稳妥的是：
- 战场服产生结果
- 原服或中心结算服务做正式入账
这样战场服异常时，更容易做重试、补偿和审计。
六、跨服好友和跨服关系怎么做
6.1 关系系统的核心问题
跨服好友不是“远程查一下角色信息”这么简单。
真正要解决的是：
- 如何全局定位玩家
- 在线状态谁维护
- 关系写入落在哪里
- 跨服私聊如何路由
6.2 更合理的做法
通常要有一个中心关系服务，维护：
- 好友关系索引
- 黑名单
- 跨服组队关系
- 在线路由映射
原服可以缓存，但不建议每个服都保存一份完整跨服关系真相。
6.3 在线状态怎么处理
最常见的方案是：
- 原服在玩家上线下线时上报中心在线状态
- 中心服务维护“玩家当前所在服 / 当前所在玩法服”的路由表
这样跨服私聊、组队邀请、好友邀请才知道要往哪里发。
七、跨服排行榜怎么做
排行榜是最适合做中心汇聚的跨服功能之一。
7.1 常见做法
- 各原服定时上报排行榜候选数据
- 中心排行服务做汇总排序
- 用 Redis Sorted Set 或数据库存储结果
7.2 关键取舍
排行通常不需要强实时。
所以更合理的目标通常是：
- 秒级或分钟级收敛
- 保证最终正确
- 保证查询稳定
而不是追求每次属性变化都立刻全网同步。
7.3 需要注意的问题
- 排行周期边界
- 重复上报去重
- 数据延迟导致的短暂显示差异
- 赛季结算快照
排行榜的核心不是传输，而是统计口径和结算口径要稳定。
八、跨服交易为什么最危险
跨服交易、跨服拍卖行、跨服资产流动是跨服系统里最敏感的一类。
8.1 风险点
- 扣款成功、发货失败
- 重试导致重复到账
- 两边都以为自己是成功方
- 回滚时找不到统一审计链路
8.2 更合理的思路
不要让两个原服直接互改资产。
更稳妥的做法通常是：
- 引入中心结算服务
- 所有资产变化经过统一事务日志
- 每笔交易有全局事务 ID
- 失败时走补偿或人工审核链路
8.3 这类功能的原则
跨服交易的关键词不是“低延迟”，而是：
- 幂等
- 审计
- 补偿
- 对账
如果这些没做好，跨服交易越复杂，风险越大。
九、跨服功能常见的几个共性问题
9.1 路由问题
你必须知道：
- 玩家当前在哪个服
- 玩家是否在跨服玩法服
- 消息该送给原服还是玩法服
9.2 一致性问题
必须明确：
- 哪些功能是最终一致
- 哪些流程必须强一致
- 哪些失败可以重试
- 哪些失败必须人工介入
9.3 可观测性问题
跨服出问题最怕“链路断在中间但没人知道”。
至少要有：
- 全局请求 ID
- 原服到跨服中心的调用日志
- 中心服务到玩法服的路由日志
- 关键结算流水
9.4 容灾问题
跨服中心如果挂了，不同功能要有不同降级策略：
- 跨服聊天可以短暂不可用
- 跨服排行可以延后更新
- 匹配可以暂停入队
- 正在进行的战场应尽量不受影响
不要用一个中心服务挂掉就把全部跨服功能都拖死。
十、一个更务实的落地顺序
如果要逐步建设跨服能力，更合理的顺序通常是：
阶段 1：先做轻量跨服
- 跨服公告
- 跨服聊天
- 跨服排行榜
这些功能最容易建立跨服基础设施，但风险相对低。
阶段 2：再做关系和匹配
- 跨服好友
- 跨服组队
- 跨服匹配
这一步开始需要统一身份、在线路由和中心关系模型。
阶段 3：最后做实时玩法和资产类
- 跨服战场
- 跨服副本
- 跨服交易
- 跨服拍卖行
因为这些功能的复杂度和风险都明显更高。
十一、总结
跨服系统不是“加一个跨服中心”就结束了。
真正要先分清的是：
- 是消息互通、关系互通，还是实时玩法互通
- 是数据跨服，还是玩家跨服
- 谁是权威源
- 一致性边界在哪里
对大多数 MMO 来说，更稳妥的经验通常是：
- 聊天、排行这类功能做中心汇聚
- 战场、副本这类功能做独立玩法服
- 交易、资产这类功能做中心结算和补偿
不要用一套统一方案覆盖所有跨服需求，否则最后通常会同时失去性能、清晰边界和可恢复性。