欢迎大家前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

作者： wincent
导语： 敢于对过去的脚本说不

前言

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在这个过程中的提供的帮助。希望可以把飞车运维工作干得更好。

##阅读推荐

一站式满足电商节云计算需求的秘诀
DCDB让秒杀更从容、购物更狂欢
织云团队告诉你，故障过后如何全面地制定规避措施

此文已由作者授权腾讯云技术社区发布，转载请注明文章出处
原文链接：
cloud.tencent.com/community/a…