SPEED 飞车扩容改造:敢于对过去说不

导语: 敢于对过去的脚本说不

前言

QQ飞车作为一款竞速游戏,从08年至今十年光阴,依然坚挺,能运维一款这样的产品,非常的荣幸,压力和动力都是有的,有压力才有动力。接手飞车运维以来,在扩缩容上耗费了比较多的精力,于是有了我们今天的主题,飞车扩容改造。

扩容之殇

QQ飞车一年有4次大的活动节点,春节,五一,暑假,国庆。活动的量级都是百万级别的,而由于成本和资源的限制,我们的机器不能长期保有在扩容期间的量级,因此,扩容缩容便成为了飞车运维工作中一项重要的工作。运维在活动前准备的时间相对比较长。通常分为以下几个阶段:

1)资源申请。通常需要提前1个月将预算提供给SA同事,经过评估确定能支持的虚拟机,docker机器以及物理机的量和交付的时间,一般情况下,需要预留两周的时间来扩容,一周用于扩容,一周用于观察;

2)周知周边同事支撑。由于活动量级很大,因此需要周边同事的支持。计算tgw,推送邮件给架平,让架平同事分配足量的专用vip;其次是,通知网平,参照之前活动的流量数据,确保活动期间有足够的流量支撑;再次是通知安平,确保vip都在宙斯的防护之下;最后通知计平,能够有充足的资源保障充值的正常。得益于重大活动保障平台的建设,目前这部分工作,已经大大的简化;

3)资源到位,扩容准备。扩容准备工作主要是需要将新来的机器加入到TCM的管理,让新的机器的bin文件和现网都能保持一致;其次,tgw申请,根据架平同事给的vip组,为新的gamsvr申请tgw端口;

4)扩容。机器准备就绪之后,就可以开始扩容了,QQ飞车现目前扩容有一整套完善的标准云扩容模版,这就是我们今天要讨论的主题,请各位看官接着往下看。

现有扩容模版的缺陷

经过两次独立的扩容之后,发现了现有模版的缺陷。

首先,不支持多模块扩容;

其次,一次扩容的机器数量不能超过30;

最后,是扩容脚本的学习成本比较高,新手上手比较慢,这也从一个侧面增加了扩容的风险。

想想,假设我们需要扩300台机器,那我们得分至少10次调用模版才能扩容完成,按照现有扩容一次保守估计30分钟计算,这时间量是相当恐怖的,运维还要不要干活儿了,光在扩容上就把人耗死了。

从扩容脚本说起

飞车现有的扩容脚本是一代一代运维流传下来的,经过每一代运维哥哥的改造与优化,到现在已经是一个很稳定的版本了。今天我们只说扩容,对扩容做一次深入的剖析。众所周知,我们自研的业务,都是通过TCM来管理进程的,因此扩容无非是准备好这三个文件,别出错,每个业务都有自己的一套扩缩容生态,现在飞车扩容要维护六个初始文件

后端维护文件:dxother.txt dx2other.txt,wtother.txt

前端文件:dxfront.txt,dx2front.txt,wtfront.txt

问题转换为维护这六个文件,一般情况下,后端是不需要动的,于是变成了维护这三个文件,先来梳理下现有的扩容脚本:

1)config.sh 核心脚本,这个脚本主要完成备份、输入参数转换、调用扩容脚本、生成vip信息、更新反外挂列表;

2)kuorong.sh 扩容脚本,这个脚本主要完成实例id的计算以及更新前端文件;

3) vip.sh 调用cc接口,更新vip信息;

4)get_ip_la.sh 主要用于反外挂列表的更新

他们之间的调用关系可以用下图来表示:

现有模版的输入参数是 大区号 模块名 ip列表。之前说过,一个是只能单模块扩容,而且不能多任务,因为这样会导致文件错乱;另外是机器ip数的限制,同模块得分多次才能完成调用。

改造开始

基于上述的问题,我们需要找到一些新的方法,避免这样重复的多次劳动。无论是config.sh脚本还是标准云的接口,都只能支持单模块的扩容,那我们的多模块扩容到底有什么实现思路呢?

首先,我们来解决标准云模版中批量修改主机名和批量移动主机模块的问题,在单模块扩容的时候,因为输入的模块和大区名只有一个,因此修改主机名和移动模块不会有问题,而多模块扩容的是呢?我们需要扩容的模块都是未知的,不能通过设定多个变量名来解决,这只是添油战术,指标不治本,另外,参数重载也不是行不通的。

通过标准云来操作这条路,我们是走不通了,我们就换一种思路。基于蓝鲸的接口,我开发了一个小型的app,这个app中封装了几个接口(当然也可以通过心云开发接口)

接口1:修改主机名接口

接口2:修改主机模块接口

接口3:刷新vip/vport接口

以上三个接口,都支持多个模块,多个主机同时操作,而且返回特别的快,大大的节省时间。以后可以有更多的原子操作扩展,慢慢丰富,因为接口完全独立于业务,所以更加灵活,一定程度上实现了解耦。

有了这个app的接口,接下来就可以专心的处理参数的初转换工作了,只要我的参数是按照app的接口以及config.sh脚本要求的形式传入,总是能返回正确的结果。

接下来我们来解决参数处理的问题,现在就不通过标准云传参了,我们准备一个文件,这个文件的格式是:大区名|模块名|扩容ip,再写一个包裹脚本auto_diliation_wrapper.py,这该脚本的功能如下:

1 init_parms函数:转换输入参数为json格式:

初始化参数
输入:
dx|gsvrd1|ip1
dx|gsvrd2|ip2
dx|gsvrd1|ip3
wt|gsvrd1|ip4
wt|gsvrd2|ip5
wt|chatsvrd|ip6
输出
{
"dx":{
"gsvrd1":[ip1,ip3],
"gsvrd2":[ip2],
},
"wt":{
"gsvrd1":[ip4],
"gsvrd2":[ip5],
"chatsvrd":[ip6,ip5],
}
"dx2":{
}
}

2 auto_dilatation函数:

1)移动ip到指定的cc模块 _chg_host_moudle函数 2)修改主机名为:SPEED-dx-gavrd1形式 _chg_host_name函数 3)刷新机器的vip/port _update_vip_vport函数 4)生成配置,调用生成脚本:config.sh dx gsvrd1 ip1 ip2 ip3 ....ipn

至此,我们多模块扩容的核心功能就改造完成了。我们来回顾一下解决的思路

1 简化输入,不重复调用模版 --于是我们定义了包裹脚本,来转换输入以及完成脚本调用;

2 绕过标准云的限制,定制符合业务需求的接口

改造之后,我们不过度的依赖于标准云,更灵活一些了,经过改造现在我们的扩容变成了这个样子:

增量扩缩容

以上就是在现有的基础脚本上就行了包裹转换,现在飞车的配置生成,是全量生成,前后两个版本的文件无法对比,运维每次扩容后要小心翼翼的去对比操作。这种扩容风险实际上还是比较大,因此增量更新脚本就应运而生了,增量更新脚本集成了扩容、缩容和变更的所有操作,运维只需要专心维护gen.sh脚本即可。具体如图所示(nosea画):

增量更新的脚本的思路是:基础脚本负责备份回滚、检查变更、异常处理以及变更操作等(小组的nosea大神已经写好了这样一套稳定的基础脚本),业务侧只需要按照脚本要求,做好输入转换以及少量修改配置生成脚本即可。总结起来,新版本的脚本的特点如下:

配置是增量的,这样可以diff差异;

  • 完善的通知机制,让运维能在任何配置更改后看到配置差异;
  • 完善的备份回滚机制。操作之前先备份,有错误能立刻回滚;
  • 原子操作脚本,不支持拆分,有错误立马回滚;
  • 完善的日志,任何的关键信息都有记录,出错时可以通过日志定位问题;
  • 严格的check,变更之后必须检验,以保证每次的变更都是正确的。
  • 核心脚本的工作示例如

经过改造之后,我们的扩容,缩容,变更都可以通过这一套脚本来实现,扩缩容模版就可以变得更简单。

扩缩容生态建设

有了基础的脚本支撑,我们就依托于标准运维对之前的扩缩容“生态”工具进行改造,得益于D+的日趋成熟,飞车的镜像扩容模版也已经完成建设,镜像扩容省去了业务传包和一些初始化的工作,可以节约大部分的时间。

后期工作

改造后的脚本,已经在今年的国庆扩容中使用,但是仍然存在一些小问题,总结以下几点后期的方向:

1)工具的不断测试。通过扩缩容不断的验证工具的正确性,确保工具的万无一失;

2)效果评估。尤其是引入D+之后的镜像扩容,相比于传统的扩容在时间成本上能有多大的提升;

3)文档与版本建设。

致谢

至此我们的改造就基本上完成了。改造过程中遇到很多的问题,都逐一解决,感谢nosea在这个过程中的提供的帮助。希望可以把飞车运维工作干得更好。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

wincent的专栏

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

【Go 语言社区】linux常用网络服务端口一览表及详细分析

端口号码 / 层 名称 注释 1 tcpmux TCP 端口服务多路复用 5 rje 远程作业入口 7 echo Echo 服...

3167
来自专栏HBStream流媒体与音视频技术

实现输出h264直播流的rtmp服务器 flash直播服务器

  RTMP(Real Time Messaging Protocol)是常见的流媒体协议,用来传输音视频数据,结合flash,广泛用于直播、点播、聊天等应用,...

3647
来自专栏腾讯Bugly的专栏

TRIM:提升磁盘性能,缓解Android卡顿

在业内,Android 手机一直有着“越用越慢”的口碑。根据第三方的调研数据显示,有77%的 Android 手机用户承认自己曾遭遇过手机变慢的影响。他们不明白...

4169
来自专栏java一日一条

SQL vs NoSQL:如何选择?

在前一篇文章中,我们讨论了 SQL 与 NoSQL 数据库之间基本的区别。接下来,我们我们将应用我们在特定场景中的知识来确定最佳的选择。

502
来自专栏更流畅、简洁的软件开发方式

增删改查不是万能的,但是万万不能没有增删改查——限信息管理类

  感谢大家对我的支持,上一篇(【角色】——分离开代码和权限需求,即实现代码和权限需求的解耦。 )的推荐数达到了37 。这是大家对我的认同、鼓励、支持、和期望。...

2059
来自专栏杨建荣的学习笔记

system表空间不足的问题分析(r6笔记第66天)

很多事情见多了也就有了麻木的感觉,报警短信就是如此,每天总能收到不少的报警短信,可能很多时候就扫一眼,如果没有严重的问题自己是不会情愿打开电脑处理的。 对于此,...

2444
来自专栏CSDN技术头条

五个解决方案让MongoDB拥有RDBMS的鲁棒性事务

【编者按】在分布式存储解决方案中谈事务一直是件很痛苦的事情,而事务也成了大部分NoSQL解决方案短板所在。近日,MongoDB公司的Antoine Girbal...

1825
来自专栏韩伟的专栏

开源服务器端软件的接口风格和分歧

前言 开源运动风起云涌,现在已经成为IT技术最重要的表现形式。从早期的GNU运动,到Apache基金会项目,到GitHub,开源项目已经几乎覆盖了全部的较通用的...

4136
来自专栏ThoughtWorks

物联网测试地图

物联网的出现,给测试带来了很多有意思的挑战,使得众多QA开始重新思考传统的测试过程。 例如,我最近测试了一个产品,在这个产品中的移动APP会跟连接的机器产生会话...

3306
来自专栏java一日一条

内存不足:杀死进程还是牺牲子进程

早上6点,我不得不开始处理“叫醒”我的一些问题。因为当这些问题发生的时候,我的手机铃声响了。昏睡中的我非常不情愿地拿起了手机,检查我是否疯狂到将叫醒闹钟设在了早...

481

扫码关注云+社区