游戏对外服动态扩容，限流，分流问题
HAZYUHE opened this issue · comments
你的问题 | 使用场景
问题１：假设一台游戏对外服务A容量为1000个用户，在用户量达到800的时候新增游戏对外服B，如何让A服务器达到1000用户的时候，将1001之后的用户流量导入到新的服务器B，并不再对A服务器进行用户导入。
问题２： 新增对外服A之前用户是和游戏对外服连接的，使用websocket连接，通过ip和10100端口 ，在新增对外服B之后，如何在客户端不重新打包更新的情况下，让用户连接到对外服B。
预期值
期望的预期值
实际值
实际值
可以在用户连接到游戏对外服之前，先获取需要连接的游戏对外服信息；比如我们可以启一个 web 服务器，用于提供给当前用户所需连接的游戏对外服信息（如，游戏对外服的 ip:port ...等）。
那么，我们只需要在该 web 服务器中启动一个游戏逻辑服用于内部通信，并使用通讯方式 - 获取游戏对外服的数据与扩展 (yuque.com) 来得到所有游戏对外服的信息及人数。（可以在 web 服务器中定时的更新这些信息）
关于如何在 web 服务器中启动一个游戏逻辑服，可以参考 GM 后台与逻辑服交互 (yuque.com)。
当 web 服务器有了各游戏对外服的信息及人数后，可以优先将人数较少的游戏对外服信息给到用户。当用户从 web 服务器中得到一个可以连接的游戏对外服时，那么客户端也就不需要重新打包了。
是否可以理解为，新增一个GM后台服务，记录对外服的ip,端口以及人数信息，用户通过GM后台的游戏逻辑服自己定义的负载均衡和限流等逻辑，获取到一个合适的对外服返回给客户端，然后客户端通过得到的对外服信息去做websocket连接，实现动态扩容和限流分流操作。
是的，用时分配，既能解决人数相关问题，又能解决 ip 更换问题。此外，还能隐藏 ip（即不过多的暴露所有能连接的服务器，通常在某些领域的游戏中，会使用这一策略）；
除非真有这方面的需要，才建议做这些扩展。
通常情况下，使用 #78 中的策略就足够了，不需要控制得这么细。因为具体的业务是游戏逻辑服在处理，所以游戏对外服所占用的机器资源会很少。游戏对外服只持有用户连接（Netty 能支持很多的用户连接）及一些简单的功能扩展）
好的