Q26: KBEngine 消息路由机制：Gateway、Proxy、CellApp 之间如何高效转发？
核心结论
这类架构的关键不是“消息经过了几跳”，而是“谁负责连接锚点，谁负责会话语义，谁负责场景逻辑”。
在典型 KBEngine 风格设计里，可以把职责粗略理解为：
Gateway负责接入和连接承载Proxy/BaseApp负责玩家会话锚点与路由决策CellApp负责场景内权威逻辑
高效转发的重点不在于让所有消息都最短路径，而在于稳定维护这三层边界。
一、为什么不能让客户端直接和 CellApp 乱连
如果客户端直接绑定场景逻辑节点，会立刻带来几个问题：
- 场景迁移时连接关系难切换
- 登录、社交、邮件等非场景逻辑没有稳定锚点
- 公网连接和高频场景逻辑耦合过深
所以系统通常需要一个长期稳定的玩家会话入口。
二、三层职责分别是什么
1. Gateway
接入层更关注：
- 连接建立
- TLS 或协议握手
- 基础限流
- 连接负载分摊
它通常不应该承载太多业务语义，否则网关会变成大杂烩。
2. Proxy / BaseApp
这是玩家会话的核心锚点，通常负责：
- 账号与角色绑定
- 请求鉴权
- 路由到当前权威逻辑节点
- 承接场景迁移前后的会话连续性
很多“客户端到底该把消息发给谁”的答案，本质上都是先发给 Proxy。
3. CellApp
CellApp 负责：
- 场景和空间逻辑
- 移动、战斗、AOI
- 实体权威状态推进
它不适合承担海量公网连接管理，但非常适合做场景内高频逻辑。
三、典型消息流是什么
1. 客户端上行
常见路径：
Client -> Gateway -> Proxy -> CellApp
其中：
- Gateway 保证连接可达
- Proxy 判断当前玩家应路由到哪个逻辑节点
- CellApp 执行真正场景逻辑
2. 服务端下行
场景内结果通常会回到玩家锚点，再由网关发回客户端：
CellApp -> Proxy -> Gateway -> Client
这样做的好处是客户端只需要维持一套稳定会话关系。
四、为什么 Proxy 很关键
Proxy 的价值不只是“转发一下消息”，而是解决玩家会话和场景逻辑分离的问题。
它让系统可以做到：
- 玩家在不同场景间迁移时，客户端连接不必频繁重建
- 非场景请求仍有稳定入口
- 玩家相关状态有统一锚点
如果没有 Proxy，很多跨服、切图、断线重连流程会复杂很多。
五、高效路由的关键点
1. 路由表要稳定
系统需要快速知道：
- 某个玩家当前绑定哪个 Proxy
- 某个实体当前由哪个 CellApp 权威管理
- 某个场景或空间归哪个节点负责
这通常意味着要有稳定的注册与发现机制，而不是靠临时广播查找。
2. 少做无效转发
并不是所有消息都要绕完整路径。
例如：
- 场景内广播可以在逻辑层聚合后统一下发
- 服务间内部同步不应再绕公网接入链路
要区分“会话锚点路径”和“内部逻辑同步路径”。
3. 避免转发层同时做重逻辑
一旦 Gateway 或 Proxy 承担太多业务判断，就会出现：
- 扩容困难
- 故障域扩大
- 路由与业务代码耦合
转发层应该知道“发给谁”，但不必承担过多“怎么打、怎么算”的逻辑。
六、迁移和重连为什么都依赖这套路由
当玩家切场景或跨 Cell 迁移时，理想状态下不应让客户端感知太多内部节点变化。
更稳妥的方式通常是：
- Proxy 会话保持不变
- Proxy 更新玩家当前逻辑节点映射
- CellApp 间完成权威迁移
断线重连时也是类似思路：
- 先恢复到玩家会话锚点
- 再由锚点接回当前逻辑节点
七、常见误区
1. Gateway 就是总路由中心
不完全对。Gateway 更偏连接承载和接入，真正理解玩家会话和逻辑归属的通常是 Proxy。
2. 跳数越少越高效
不一定。少一跳如果换来强耦合、迁移复杂、重连脆弱，整体并不更优。
3. Proxy 只是多余中转
对带场景迁移和复杂会话语义的游戏来说，Proxy 往往是系统稳定性的关键组成部分。
参考资料
- KBEngine 架构资料中的 BaseApp / CellApp / Proxy 职责说明