游戏灰度发布

背景

快速可以说是互联网的最大特点了,唯快不破,快速响应,快速发布,快速部署,快速上线

但上线,毕竟还是有风险的,怎么能又快速响应,又能降低风险范围呢

前人,现人,后人们都在寻找着银弹

部署方式就进化了有很多次,蓝绿部署、滚动部署、灰度发布、金丝雀发布。。。

这些都是为了应对互联网的快速响应需求

游戏的发布现在还是比较粗暴的,对开发,运维也比较简单。

制定一个版本计划,开发,与运营沟通,确定版本内容,到了时间,所有游戏区全部关闭入口,停止服务器,发布,部署,重启,开放入口,一气呵成,快哉!

等等,理想很丰满,现实很骨感

在版本发布最后一天,开发人员在凌晨1、 2点时,还在开发,修复bug,好不容易打包,回家睡觉

第二天运维在8点开始停机发布新版本;

duang,怎么游戏服起不来了,开发请起床,查问题

迷迷糊糊的开发在梦境中惊醒,终于搞定,打包,发版本,启动服务(有时可能要一上午查问题,通知运营方,延长维护时间)

duang,玩家反馈,新功能有问题…

此时,回滚?还是。。。;好汉不回头,哪来的回滚

紧急停机,再寻找问题,修复,上线…

整个游戏的链条上,似乎大家都已经习惯,开发习惯,玩家也习惯

习惯麻痹了一切,没有提出更好的策略,大家都这么玩啊,无所谓啦~

方案

细思极恐,我们应该,也需要做得更好

灰度发布/金丝雀发布

灰度发布是在原有版本可用的情况下,同时部署一个新版本应用作为“金丝雀”(金丝雀对瓦斯极敏感,矿井工人携带金丝雀,以便及时发发现危险),测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。

灰度发布

灰度发布/金丝雀发布由以下几个步骤组成:

  1. 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
  2. 从负载均衡列表中移除掉“金丝雀”服务器。
  3. 升级“金丝雀”应用(排掉原有流量并进行部署)。
  4. 对应用进行自动化测试。
  5. 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
  6. 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

游戏架构

image

这个架构图比现实丰满不少,真实情况组件可能是单点的,数据层也就是单个mysql,一切都是那么脆弱。

流程图

流程图

玩家首先登陆游戏运营平台,鉴权完毕,选择区服,通过网关服务器获取到真实game-server信息,通过TCP,玩家与game-server建立起长连接。

通过这个流程,就知道玩家与game-server直接牵手,强依赖的,如果gameserver重启,tcp连接是一定会断的,虽然前端可能尝试重新连接,但对玩家是有感的,不可能对玩家透明。

改进

怎么才能对玩家无感,切换版本呢?

image

在之前的架构图中,稍作修改,在玩家与Gameserver之间增加一层ha-proxy,这样就有了灰度发布的基础

玩家不再直接与game-server直连,而是与ha-proxy

透明性

对玩家来说,发版本就是透明的,发版本时,不再需要停机,入口也不需要关闭,7*24玩耍

流量灵活切换

灰度百分比,可以灵活控制,这里面又涉及到路由规则,复杂了,可以先百分百切换

快速迭代

玩家无感,出现bug,可以快速修复,快速上线

快速回滚

一旦新版本有问题,可以马上切回老版本,版本之间无逢切换

难点

加了ha-proxy,多了更多的灵活性

ha-proxy的难点,高可用,高可靠,高性能

高可用

最重要的一点,不能单点;

如果ha-proxy挂了,怎么办?就算game-server正常运行,也不能再提供服务,自己坑了自己

所以ha-proxy不能单点,哪是集群,还是主从?

每台物理机上都部署,还是集中几台部署?

高可靠

在新旧版本同时在线时,流量是否平滑过渡? 玩家操作是否保持完整性?

一个玩家操作横跨新旧版本时,数据一致性如何保障?

高性能

游戏服都是尽量压榨单台服务的能力,现在多了一层通讯,IO会不会影响性能?

结论

对于以上方案,不论是哪一种实现方式,仁者见仁,条条大路通罗马。

也可能你觉得这种想法本身就是个多余。

能卖1块钱的豆腐,为什么要卖5毛?

朱兴生 wechat
最新文章尽在微信公众号『码农戏码』