『吃鸡』一发新版就停服怎么破?谈游戏公司不得不用的部署方式

1,487 阅读6分钟

本文由吆喝科技 刘泽军 独家授权 转载请通过文末公众号联系原作者谢谢

请问:在中国IM软件领域,谁是Wechat或QQ的对手?

%e8%bf%98%e6%9c%89%e8%b0%81

易信?陌陌?YY?

当然不是,微信们的大敌不是同类竞品而是被称为第九艺术的游戏,是《王者荣耀》、《绝地求生》们,是国际3A大作和天美、光子工作室们,是任天堂、索尼和微软的主机们。越来越多的人们已经厌烦了毫无营养的无谓社交,秉持着“别废话,Just do it”的原则,将大量的时间尽情挥洒在游戏中。

%e5%a5%b3%e5%90%83%e9%b8%a1

今天,您吃鸡了吗?

从《绝地求生》在外网大火到《荒野行动》等一众吃鸡类游戏上线,充分体现了科技互联网的应有之义:快速响应、快速部署、快速上线。正是这种“快”让腾讯和网易们赚得盆满钵满。

可是,这种快却是是无数技术人员三班倒的地狱体验得来的。当前,国内游戏的发布风格还比较粗暴——基本上属于一个劳动密集型产业:

  • 制定版本计划,开发与运营沟通确定版本内容;
  • 所有游戏区全部关闭入口并停止服务器,发布、部署、重启、开放入口。

是不是看似一气呵成,充分体现了互联网『少即是多』的特征——

%e5%91%b5%e5%91%b5

呵呵!

实际上,在版本发布最后一天,开发往往在凌晨 1、 2点时还在开发、修复bug,好不容易打包回家睡觉坐等第二天运维在8点开始停机发布新版本~

duang1

怎么游戏服起不来了,开发请起床,查问题:迷迷糊糊的开发在梦境中惊醒,终于搞定,打包,发版本,启动服务——有时可能要一上午查问题,通知运营方,延长维护时间~

duang2

玩家反馈,新功能有问题...此时,回滚?还是~好汉不回头,哪来的回滚!

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

老司机们这时一般都会拿出保温杯和枸杞,只是笑笑从不说话!

%e8%80%81%e5%8f%b8%e6%9c%ba%e5%b8%a6%e5%b8%a6%e6%88%91

想要解决这个问题,我们得先来熟悉游戏开发的基本架构:

%e6%b8%b8%e6%88%8f%e6%9e%b6%e6%9e%84

游戏架构图

实际上,这份架构图是一个理想化的模型。真实情况只会比这个更“糟糕”:或许数据层也就是单个mysql,没有灾备中心,也不会读写分离,一切都是那么写意、那么佛性。这就为游戏更新买下了巨大的风险隐患。之所以游戏中用户对更新的强感知性还在于game-server环节,请看下图:

%e7%ad%be%e6%89%8b%e6%b5%81%e7%a8%8b

玩家首先登陆游戏运营平台、鉴权完毕、选择区服,通过网关服务器获取到真实game-server信息;接着玩家通过TCP与game-server建立起长连接。对,你没看错!玩家与game-server直接牵手,如果gameserver重启,tcp连接是一定会断的。虽然前端可能尝试重新连接,但是如何才能对玩家无感切换版本呢?

%e6%96%b0%e6%9e%b6%e6%9e%84

实际上,游戏行业为了解决这个问题已经经历了多次技术革新。无论是蓝绿部署还是滚动部署,都是为了解决上面这些问题。今天,我想为大家推荐的是游戏中的灰度发布或者说是金丝雀发布:

%e9%87%91%e4%b8%9d%e9%9b%80

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

灰度发布:有所控制地选择发布的人群及其比例

从产品用户群中选取部分用户投放 A 版本,另一部分投放 B 版本,根据两个版本的用户数据反馈,逐步扩大范围,确定最终放量投放那个版本。

一套完整的灰度发布机制会包括下面这些阶段:

  • 用户标识:主要是区分用户,同时也为数据分析做辅助。
  • 目标用户/流量筛选:需要参考用户特征、用户流量、用户范围及用户体验的一致性,版本迭代针对全部用户还是部分用户,小流量试验通过再放量,一般来说按照内部用户-种子用户-活跃用户-所有用户的顺序就是一种典型的范围控制,体验一致性要求考虑新旧版本的跨度是否过大,用户能否接受。
  • 实时数据监控:监测诸如新版本稳定性、服务器稳定性、使用次数、使用频率等数据与原有数据对比。
  • 一键发布/回滚:从数据反馈结果决定是否发布/回滚。

有人质疑灰度发布是一种浪费。但与其说这是浪费不如说是冗余和弹性,灰度发布能避免新版本全量上线的风险,通过小流量验证的方式,在灰度阶段就能发现、调整并优化产品中的问题,平滑迭代。

那么,问题来了:灰度如何实现?目前,企业内部灰度发布的实现方式有两种——自建灰度发布系统和采用第三方工具。

自建系统

%e8%87%aa%e5%bb%ba%e7%b3%bb%e7%bb%9f

某运营商自建灰度发布系统案例

在这个案例里,通过前端灰度发布,后端数据即时转换,部分营业厅试行,用户无感知升级迭代,实现了前后端、系统层,以及实现过程的灰度发布。

对于开发团队富裕、内部沟通良好的团队可以尝试自建系统。一般自建系统会包括分流控制系统,业务监控系统,服务器负载均衡等,同时还要兼顾拓展性,以及大业务量支持。这也意味着开发和运维成本高昂,一般的企业难以承受。


第三方工具实现

可用的第三方灰度发布工具很多,国内的有吆喝科技,国外的有 Optimizely 、 ABTasty 、 Apptimize 等,使用这些工具可以使我们更加快速、高效的实现灰度发布。

%e5%93%81%e7%89%8c

这里以吆喝科技的灰度发布功能为例,对于 iOS 应用来说,新版本发布要先经过7天的审核,若产品上线出现问题会被退回,更新升级后又要经过7天的审核周期。任何版本发布直接面对全部用户,线上事故/Bug 对用户影响极大,解决问题周期长,用户体验较差。

%e5%8f%91%e5%b8%83

灰度发布功能

接入 SDK 进行小批量用户测试,减少全用户发生线上事故/重大 Bug 概率,保护性开发,一键回滚,无再审核时间,实现绝大多数用户对 Bug 无感知。第三方工具的优势在于快速上手,成本极低。在国内人口红利不再,人力成本高昂的今天,擅用合适的第三方工具能很大程度上提高游戏企业的 ROI和更新发布的稳定性 。

特别鸣谢:码农游戏Jack提供游戏案例分析

%e4%ba%8c%e7%bb%b4%e7%a0%81

欢迎关注吆喝科技微信公众号,发现更多更好地A/B测试内容