灰度更新的核心思想是：在不中断整体服务的前提下，分批次对服务器进行更新，从而将更新风险降到最低。
更新流程示例
假设当前有服务器组 A、B、C。更新流程如下：
- 将全部流量引导到服务器组 A，等待玩家向 A 迁移完成（短则几分钟，长则数小时）。
- 对服务器组 B、C 执行更新（重启等操作）。
- 更新完成后，将流量引导到 B、C，等待组 A 上的玩家自然迁移过来。
- 组 A 玩家迁徙完成后，对组 A 执行更新（重启等操作），随后重新上线。
- 至此，整个更新流程完成。
注意事项
- 新旧客户端版本共存问题：新进入的客户端会触发客户端更新，因此新登录的玩家使用的是新版本。如果服务器内部没有做版本兼容处理，就需要阻止新旧版本玩家之间的不兼容交互。
- 负载均衡需具备屏蔽灰度区的能力：服务器内部的负载均衡算法应能屏蔽仍处于旧版本的服务器，避免新登录的客户端被分配到旧版本服务器上。多级星形结构天然具备这种优势——新登录玩家直接分配到新版本服务器，旧服务器上的玩家等待自然下线即可。
- 过程应当自动化：整个灰度更新周期较长，操作过程中对错误的容忍度极低，因此最好通过自动化脚本来处理。
玩家交互问题的解决方案
在新旧版本共存期间，玩家之间的交互可能产生兼容性问题，常见的处理方案有以下几种：
- 直接屏蔽跨版本交互功能：例如《刺激战场》的做法——组队邀请旧版本玩家时，直接提示"版本过低，无法邀请"。
- 服务器内部双向兼容：实现难度极高，通常不予考虑。
- 由低版本客户端忽略请求：变相于方案一。将被接收方（低版本）改为忽略邀请请求。由于这类场景通常同时涉及服务器与客户端，可以通过使用不同的消息名来让低版本客户端自动忽略该消息。
- 带反馈的拦截处理：若需要向玩家弹窗说明原因，可在客户端登录时携带版本号，针对不同版本中需要屏蔽的特定 RPC 单独进行拦截处理。这种方式简单灵活，且整套拦截规则可以通过配置表来维护。
TODO