golang做为长连接游戏服务端,如何解决热更新问题?

1. 快速迭代开发 2. 运营需要的新活动 3. 上线前期的bug紧急修复
已邀请:

Akagi201 - http://akagi201.org

1. 前面加个负载均衡, 或者运维进行切换连接, 旧的连接继续服务, 新的连接切换到新的版本程序上.当旧的连接都断了, 就停掉旧的程序.
2. 另外, 加个定时器, 如果很久旧的程序都还再提供, 就找个半夜的时候停止掉.
3. 另外, 客户端必须要有重连机制.
这个问题我我再设计mqant的时候有考虑过,不过目前也并没有什么好的方案。就代码本身的热更新来说目前新版本的golang也支持加载so库了,因此要设计一个模块化的加载机制也不是难事,跟java的osgi架构一样。但我想长连接的服务跟HTTP服务有一些本质的区别。
1. 是否应该给golang设计一个模块化的加载机制?
我的想法是尽量不要,golang直接编译一个执行文件就可以部署运行对运维来说是天大的好处,如果新增一个模块化机制的话又得去维护一个插件版本
2. 长连接服务的特点
1. 无状态服务器
可以执行代码热替换,对业务没有影响
2. 有状态保留的服务器
对于一些战斗场景服务器来说,一些临时数据可能就保存在内存中,在热更新的时候是否能真正保证把当前的业务数据迁移到新的代码中来?这是一个设计难点
3. 哪些需要热更新
1. 紧急修复代码BUG
2. 运营需要的新活动 比如加一些道具,新增一个公告什么的
这类需求应该可以单独做一个业务模块,将数据放到数据库里面增删改查
3. 新功能
服务器更新应该慎重一点,频繁更新可能对整体系统的稳定性也不可控
可以 谷歌 搜索关键字 `go 优雅重启`, 前几条有一个 `平滑升级/优雅重启` 方面的内容, 不知道有用不.
关于 "运营需要的新活动" 这种东西可以效仿 `游戏开发` 用 `脚本` 来做, 但是执行效率 我不做评论. 还有就是这种东西如果不是 `核心业务` 建议拆分出独立的服务去处理, 不要因为这种易变的东西参插到 `核心代码` 内, 看看是否 "软件设计" 有待改善.
关于 `长连接负载` 的问题, 说实话很难做. `七层负载` 软件/设备不能做这个(NGINX 这样的), 因为 `应用层` 的负载是一个 `反向代理` 模式, 这种模式受到机器出口端口量限制. 好的负载解决方法是 `客户端负载`, 客户端做好 `重连`.
我以前有一个想法,后端做一个内存共享,如果有服务器要更新,那么新开一个同样的服务器进程,让它对接老服务器共享内存,同时老服务器停止接收消息(这个时候客户端消息都会缓存但rpc队列里面,有5秒钟等待处理的时间),新服务器读取完内存数据以后,开始接收rpc的请求,完成了迁移

要回复问题请先登录注册