Q29: KBEngine CellApp 之间如何通信？如何发现自己的空间位置？
核心结论
CellApp 之间通信，核心不是“有没有 TCP 直连”，而是它们如何知道：
- 自己负责哪一块逻辑空间
- 邻接节点是谁
- 某个实体现在归谁管理
所谓“发现自己的空间位置”，更准确地说是发现自己的逻辑负责范围和邻接关系，而不只是几何坐标。
一、CellApp 之间为什么必须通信
只要世界被拆到多个 CellApp，上游就不可避免会出现这些需求：
- 实体跨边界移动
- 邻区 AOI 感知
- Ghost 同步
- 迁移交接
所以 CellApp 之间通常需要长期内部通信链路，而不是完全彼此隔绝。
二、通信内容通常包括什么
常见包括：
- 节点注册与心跳
- 空间归属信息
- 邻区节点信息
- 实体迁移数据
- Ghost 更新
- 边界事件通知
这些消息里，真正高频的往往是邻区协作和实体同步，不只是启动时的一次注册。
三、它们如何知道自己负责哪一块
常见方式是：
- 启动后向管理节点注册
- 管理节点分配逻辑区域或空间职责
- 节点保存自己的负责范围
- 同时获知邻接节点信息
因此“空间位置”本质上是一份调度和归属元数据。
四、为什么这不是简单的物理坐标问题
很多人容易把它理解成：
CellApp1负责x=0~100CellApp2负责x=100~200
但真实系统通常更复杂，因为还会涉及：
- 多个独立 Space
- 副本和房间
- 动态负载均衡
- 热点迁移
所以节点知道的往往不是单一矩形，而是一套逻辑空间归属关系。
五、CellApp 之间如何建立通信关系
常见思路是：
- 先由中心管理组件维护节点信息
- 再让 CellApp 按需建立内部连接
- 后续用内部协议交换迁移和同步消息
重点不在于一定是全连接还是按需连接，而在于：
- 节点发现是否稳定
- 邻区切换是否及时
- 故障后是否能重建关系
六、迁移时为什么尤其依赖这套发现机制
实体跨边界移动时，源节点必须知道：
- 新目标节点是谁
- 如何把状态交给它
- 何时完成主从切换
如果邻接和归属信息不准确，迁移过程就容易出现：
- 迁移到错误节点
- Ghost 同步丢失
- 双 Real 并存
七、工程上更重要的不是“怎么连”，而是“怎么维护拓扑”
内部通信协议只是表层，真正困难的是：
- 空间划分如何更新
- 热点区域如何迁移
- 邻接关系如何增删
- 节点异常时如何收敛
这些决定了系统是否能在动态世界里长期稳定运行。
八、常见误区
1. CellApp 之间通信就是普通 RPC
不完整。它们的通信和空间边界、实体归属、Ghost 同步强耦合。
2. 空间位置就是地图坐标
不准确。它更多是节点的逻辑负责范围与邻接关系。
3. 只要启动时分一次区就够了
对静态小场景也许够，但对热点迁移和动态扩缩容通常不够。
参考资料
- KBEngine 架构资料中的 CellAppMgr、CellApp、Space 管理说明