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 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

给Linux小白看的命令行极简教程

1、命令行真的好吗 程序员的使命 维基百科的解释: 命令行界面(英语:command-line interface,缩写:CLI)是在图形用户界面得到普及之前使...

3126
来自专栏

记录服务上线一年来的点点滴滴

2015年12月,也就是在一年前,开发了半年的云存储服务上线。这对于付出了半年努力的我们来说,是一件鼓舞人心的事件。因为这个服务在我们手上经历了从0到1的过程。...

1745
来自专栏EAWorld

全面对比指南:Service Mesh能否成为下一代SDN

作者:James Kelly 译者:月满西楼 原题:Are Service Meshes the Next-Gen SDN? 全文7500字,阅读约需要18...

4316
来自专栏智能计算时代

Salesforce架构师的网络最佳实践

对于在Salesforce平台上实现应用程序的架构师或开发人员来说,在分析应用程序性能时,网络性能测试变得越来越重要。本指南涵盖了帮助您识别风险并找到网络相关挑...

722
来自专栏即时通讯技术

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

本文引用了简书作者“骑小猪看流星”技术文章“Cookie、Session、Token那点事儿”的部分内容,感谢原作者。

902
来自专栏跟着阿笨一起玩NET

C#轻量级高性能日志组件EasyLogger(六)

1372
来自专栏EAWorld

DevOps平台中的自动化部署框架设计

本文目录: 一、背景 二、我们的需求是什么? 三、概念澄清 四、概念模型 五、总体设计 六、关键点设计 七、总结 一、背景 说到自动化部署,大家肯定都会想到一些...

3564
来自专栏腾讯云技术沙龙

黄文俊:Serverless小程序后端技术分享

今天讲的是怎么使用Serverless做后端技术分享。我的职业偏向是后端,可能不是写前端,不是使用Node.js,更多是使用CR做后端语言,今天关注的微信小程序...

1.1K12
来自专栏Netkiller

高级软件工程师(面试题)

高级软件工程师(面试题) 出题者:netkiller 出处:http://www.netkiller.cn/ 高级软件工程师 下面的面试题不分语言,适用于所有...

3103
来自专栏微信公众号:Java团长

做一个完整的Java Web项目需要掌握的技能

最近自己做了几个Java Web项目,有公司的商业项目,也有个人做着玩的小项目,写篇文章记录总结一下收获,列举出在做项目的整个过程中,所需要用到的技能和知识点,...

751

扫码关注云+社区