返回目录：电脑怎么了
更多腾讯【深圳市腾讯计算机系统有限公司成立于1998年11月，由马化腾、张志东、许晨晔、陈一丹、曾李青五位创始人共同创立。】海量技术文章，请关注腾讯云【腾讯云有着深厚的基础架构，并且有着多年对海量互联网服务的经验，不管是社交、游戏还是其他领域，都有多年的成熟产品来提供产品服务。】技术社区：https://cloud.tencent.com/community
作者：wincent
导语： 敢于对过去的脚本说不
前言
QQ飞车作为一款竞速游戏，从08年至今十年光阴，依然坚挺，能运维一款这样的产品，非常的荣幸，压力和动力都是有的，有压力才有动力。接手飞车运维以来，在扩缩容上耗费了比较多的精力，于是有了我们今天的主题，飞车扩容改造。
扩容之殇
QQ飞车一年有4次大的活动节点，春节，五一，暑假，国庆。活动的量级都是百万级别的，而由于成本和资源的限制，我们的机器不能长期保有在扩容期间的量级，因此，扩容缩容便成为了飞车运维工作中一项重要的工作。运维在活动前准备的时间相对比较长。通常分为以下几个阶段：
1）资源申请。通常需要提前1个月将预算提供给SA同事，经过评估确定能支持的虚拟机，docker【Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。】机器以及物理机的量和交付的时间，一般情况下，需要预留两周的时间来扩容，一周用于扩容，一周用于观察；
2）周知周边同事支撑。由于活动量级很大，因此需要周边同事的支持。计算tgw，推送邮件给架平，让架平同事分配足量的专用vip；其次是，通知网平，参照之前活动的流量数据，确保活动期间有足够的流量支撑；再次是通知安平，确保vip都在宙斯【宙斯（Zeus）希腊众神之神，是奥林匹亚(Olympia)的主神，为表崇拜而兴建的宙斯神像是当世最大的室内雕像，宙斯神像所在的宙斯神殿则是奥林匹克运动会的发源地。】的防护之下；最后通知计平，能够有充足的资源保障充值的正常。得益于重大活动保障平台的建设，目前这部分工作，已经大大的简化；
3）资源到位，扩容准备。扩容准备工作主要是需要将新来的机器加入到TCM【TCM是一个英文缩写，有多种含义，一指金万维终端行为管理系统，二指汽车自动变速箱控制模块，三指可信密码模块等。】的管理，让新的机器的bin文件和现网都能保持一致；其次，tgw申请，根据架平同事给的vip组，为新的gamsvr申请tgw端口；
4）扩容。机器准备就绪之后，就可以开始扩容了，QQ飞车现目前扩容有一整套完善的标准云扩容模版，这就是我们今天要讨论的主题，请各位看官接着往下看。
现有扩容模版的缺陷
经过两次独立的扩容之后，发现了现有模版的缺陷。
首先，不支持多模块扩容；
其次，一次扩容的机器数量不能超过30；
最后，是扩容脚本的学习成本比较高，新手上手比较慢，这也从一个侧面增加了扩容的风险。
想想，假设我们需要扩300台机器，那我们得分至少10次调用模版才能扩容完成，按照现有扩容一次保守估计30分钟计算，这时间量是相当恐怖的，运维还要不要干活儿了，光在扩容上就把人耗死了。
从扩容脚本说起
飞车现有的扩容脚本是一代一代运维流传下来的，经过每一代运维哥哥的改造与优化，到现在已经是一个很稳定的版本了。今天我们只说扩容，对扩容做一次深入的剖析。众所周知，我们自研的业务，都是通过TCM来管理进程的，因此扩容无非是准备好这三个文件，别出错，每个业务都有自己的一套扩缩容生态，现在飞车扩容要维护六个初始文件
后端维护文件:dxother.txt dx2【dx2是论坛程序Discuz! X2的简称，是php程序和sql数据库相结合的大型网络论坛程序。】other.txt,wtother.txt
前端文件:dxfront.txt,dx2front.txt,wtfront.txt
问题转换为维护这六个文件，一般情况下，后端是不需要动的，于是变成了维护这三个文件，先来梳理下现有的扩容脚本：
1）config.sh 核心脚本，这个脚本主要完成备份、输入参数转换、调用扩容脚本、生成vip信息、更新反外挂列表;
2）kuorong.sh 扩容脚本，这个脚本主要完成实例id【ID是英文IDentity的缩写，身份标识号码的意思。】的计算以及更新前端文件;
3) vip.sh 调用cc【Creative Commons （创作共用）是网络上的数字作品（文学、美术、音乐等）许可授权机制，它致力于让任何创造性作品都有机会被更多人分享和再创造，共同促进人类知识作品在其生命周期内产生最大价值】接口，更新vip信息；
4）get_ip_la.sh 主要用于反外挂列表的更新
他们之间的调用关系可以用下图来表示：
现有模版的输入参数是 大区号 模块名 ip列表。之前说过，一个是只能单模块扩容，而且不能多任务，因为这样会导致文件错乱；另外是机器ip数的限制，同模块得分多次才能完成调用。
改造开始
基于上述的问题，我们需要找到一些新的方法，避免这样重复的多次劳动。无论是config.sh脚本还是标准云的接口，都只能支持单模块的扩容，那我们的多模块扩容到底有什么实现思路呢？
首先，我们来解决标准云模版中批量修改主机名和批量移动主机模块的问题，在单模块扩容的时候，因为输入的模块和大区名只有一个，因此修改主机名和移动模块不会有问题，而多模块扩容的是呢？我们需要扩容的模块都是未知的，不能通过设定多个变量名来解决，这只是添油战术，指标不治本，另外，参数重载也不是行不通的。
通过标准云来操作这条路，我们是走不通了，我们就换一种思路。基于蓝鲸的接口，我开发了一个小型的app，这个app中封装了几个接口（当然也可以通过心云开发接口）
接口1：修改主机名接口
接口2：修改主机模块接口
接口3：刷新vip/vport接口
以上三个接口，都支持多个模块，多个主机同时操作，而且返回特别的快，大大的节省时间。以后可以有更多的原子操作扩展，慢慢丰富，因为接口完全独立于业务，所以更加灵活，一定程度上实现了解耦。
有了这个app的接口，接下来就可以专心的处理参数的初转换工作了，只要我的参数是按照app的接口以及config.sh脚本要求的形式传入，总是能返回正确的结果。
接下来我们来解决参数处理的问题，现在就不通过标准云传参了，我们准备一个文件，这个文件的格式是：大区名|模块名|扩容ip，再写一个包裹脚本auto【C++的auto_ptr所做的事情，就是动态分配对象以及当对象不再需要时自动执行清理。】_diliation_wrapper.py，这该脚本的功能如下：
1 init_parms函数：转换输入参数为json格式：
初始化参数输入：dx|gsvrd1|ip1dx|gsvrd2|ip2dx|gsvrd1|ip3【在磷脂酰肌醇途径中，胞外信号分子与其相应的G蛋白偶联受体结合后，激活膜上的Gp蛋白（一种作用于磷脂酰肌醇系统的G蛋白），然后由Gp蛋白激活磷酸酯酶Cβ （phospholipase Cβ，PLC）， 将膜上的4，5-二磷酸脂酰肌醇（phosphatidylinositol biphosphate， PIP2）分解为两个细胞内的第二信使： DAG和IP3，最后通过激活蛋白激酶C（protein kinase C，PKC），引起级联反应，进行细胞的应答。】wt|gsvrd1|ip4wt|gsvrd2|ip5wt|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在这个过程中的提供的帮助。希望可以把飞车运维工作干得更好。