百亿次QQ红包背后的运维实力

《百亿次QQ红包背后的运维实力》要点：
本文介绍了百亿次QQ红包背后的运维实力，希望对您有用。如果有疑问，可以联系我们。

 

作者简介

周小军

腾讯SNG社交网络运营中心高级运维工程师

资深运维专家,拥有十几年的IT运维经验,擅长互联网网站架构、云计算平台及运维、自动化运维开发等领域,具有十万台级规模的基础设施规划及运营能力,腾讯学院讲师. 目前在腾讯社交网络运营中心负责数据运维和接入运维工作.

前言

本文来自于 GOPS 2017 深圳站的演讲“从腾讯社交平台春节大活动的背后看运维自动化”.

2016年除夕夜,QQ 在线用户峰值 2.6亿,这一晚全球QQ用户共刷了 72 900 000 000 次红包.我们好奇什么样的运维技术才能撑得住如此巨大的流量冲击,带着这个疑问,听腾讯运维老兵为我们揭开谜底.

一、活动背景

运维有三座大山：大活动、大变更、大故障.这几个运维场景是最消耗运维人力的.特别是大活动,非常考验弹性能力,对运维自动化挑战很大.

我今天所分享的主题就是深入百亿次红包大活动的背后,解析腾讯运维的方法体系,了解织云平台如何帮助运维实现大活动高效运维,如何减少运维人海战术.

过年大家都刷过微信红包和 QQ 红包,QQ 红包的业务主要有几种产品形态：刷一刷红包、拼手气红包、AR红包和空间红包等.2016年跨年除夕这天有2.6亿的在线用户刷了729亿次的红包.这么大的体量给整个架构体系带来的冲击是非常大的.

今天将从”刷一刷红包”的业务架构、活动背景、计划扩容、压测和演习、运维策略及活动现场这几个方面来分享我们的活动型背后的运维支撑工作,希望给大家在产品大活动时提供参考和帮助.

挑战

大活动前的二个月,产品会给研发和运维提供详细的产品运营指标,今年春节前”刷一刷”红包所规划的产品指标预估为峰值每秒800万,同时活动及节假日也带来相关QQ消息量和空间说说量2-5倍的上涨.

根据运营指标,运维按历史性能数据、容量模型和业务架构,评估出春节活动需要2万台虚拟机和3千台数据库服务器扩容支撑.

节前恰好遇到厂商内存供货问题,服务器供应非常紧张,采购比原计划延期了一个多月.甚至有个别型号的服务器到春节封网前一天才到货.紧张的设备供给运维增加了扩容压力.

二、活动计划

2.1 日历表

运维有2个月时间来准备和实施红包活动,上图是活动日程表.在确定产品策略和活动方案后,12月进入资源采购流程,元旦前后进入扩容部署.

业务扩容有两周时间,到1月的中旬,也就是离春节还有2周的时间开始进行业务和模块压测,以及活动演习及预案,大年三十我们开始进入活动现场.

在活动现场,产品、开发和运维全部在第一线保障红包,一直坚守到大年初一的凌晨一两点钟.

2.2活动梳理

由于活动涉及业务多,模块核心链条关系错踪复杂,运维在前期的活动梳理中,要做好基础能力、外部服务压力和支撑等复杂的评估准备工作.

支撑工作梳理包括内网专线穿越流量梳理,因为业务均为多地部署(深圳、天津和上海),同城也有几个大的核心IDC,业务不仅有同城跨IDC 部署,也有跨城异地部署,评估同城、跨城的专线容量是容量评估重点之一,如果超出阈值有什么应急方案,跨城调度与容灾怎么做,柔性与过载保护策略等,这些都是运维要考虑的核心保障工作.

三、扩容

3.1 刷一刷红包架构

在分享扩容之前,我先从刷一刷红包的系统架构开始,先让大家对业务进一步的了解.

业务架构由抽奖系统、消息系统和支付系统三个核心架构组成.

• 接入层SSO统一接入：手Q自身系统与客户端唯一连接.
• 抽奖主逻辑：含抽奖相关逻辑、数据上报等、排行榜、订单管理等.路由采用L5(自研内部路由系统简称)的HASH一致性功能,保证同一个用户的不同请求会落到同一台机器.
• 存储：中奖记录和奖品等信息统一存储.统一使用公共组件Grocery(自研NoSQL分布式存储系统)进行存储.
• 礼包发货：现金外的其他奖品发货,包括公司内外业务的礼券.
• 公众号消息：负责用户中奖以及发货通知.
• 支付系统：现金和奖品发货,还包括后端的银行接口等.
• CDN 资源：用于奖品图片信息等资源下载.

根据这三个层,架构分成无状态层和有状态层,无状态层为接入层和逻辑层；有状态层即数据存储层,数据持久化存储.

扩容包括无状态层和有状态层的设备扩容.

上图是系统的架构图

3.2 无状态服务自动扩容

3.2.1 传统扩容流程

下面讲一下怎么做无状态的扩容,这是传统的扩容流程,传统运维的扩容流程一般是通过脚本来部署.我们把流程拆解下,可以看到它主要由以下核心步骤组成,包括部署操作系统、服务部署、配置下发、业务模块关联、业务代码包发布、业务权限管理、启动服务、模块测试、服务上线和加入监控告警.

蓝色圆圈是流程执行的时间消耗,这里一台设备约消耗半小时.如果扩容一千台机器需要两个人/月.如果用脚本或开源运维工具批量的扩容,一个模块按一人一天,这样的工作量还是非常繁琐的,非常依赖人海.

蓝色圆圈是流程执行的时间消耗,这里一台设备约消耗半小时.如果扩容一千台机器需要两个人/月.如果用脚本或开源运维工具批量的扩容,一个模块按一人一天,这样的工作量还是非常繁琐的,非常依赖人海.

蓝色圆圈是流程执行的时间消耗,这里一台设备约消耗半小时.如果扩容一千台机器需要两个人/月.如果用脚本或开源运维工具批量的扩容,一个模块按一人一天,这样的工作量还是非常繁琐的,非常依赖人海.

3.2.2 全自动扩容

在我们强大的织云自动化运维平台支撑下,我们的业务模块都是一键式扩容模式,也称一键上云.一个模块下的上百台设备,整个扩容流程跑完只消耗5分钟时间.

我们来看一下我们这边是怎么做的,这是我们基于CMDB的全自动扩容,CMBD 是我们非常核心的扩容系统,包括资产、模块、业务对象、软件包、配置等等的数据信息都在这里面.

新部署服务器从 CMBD 获取属性以后,会进入到服务包的部署,之后到告警屏蔽,下面有发布自检,会检测装的包是否正常的.然后到业务测试,灰度上线,体检报告.整个流程效率比较高,一般来讲部署一台设备或一个模块也就5分钟,因为它是并发来做扩容的.织云已经把运维操作抽象成几百个流程.

整个春节期间走了700多次扩容流程,每天都有上百个业务模块并行,春节我们扩容了200多个模块,平均一个模块是100多台设备.

上图是织云的一键上云页面,左边是管理列表,右边是服务器属性.包括它属于哪个模块,IP是多少,什么机型,运营状态,操作系统,监控等等.

当我们点击”新增设备”按纽,下面就是扩容流程,就会弹出一个界面,会显示出要扩什么样的机型,系统支持Docker、虚拟机等等五种类型.下面就是设备责任人,IDC等等.点击发布完,就会根据参考IP自动化把扩容批量IP走完整个流程.

刚刚说到我们扩容的最后流程是变更体检报告,变更体检报告是变更系统和监控系统的融合,依赖于变更系统的变更日志和监控系统的监控数据和监控告警.变更系统需要把每次现网变更记录下来,变更体检报告根据这个记录,取得变更设备和变更对象列表,然后分析这些变更对象的监控数据,得出最终结果.

体检报告的检测结果为正常,需关注,异常.正常表示本次变更正常；需关注表示此次变更中有一些监控指标波动比较大,需要相关人员关注下,对业务本身没有造成重要影响；异常表示本次变更造成了现网故障,需要立即回滚.正常的体检报告不发送任何通知,需关注的体检报告发送邮件通知,异常的体检报告既发送邮件也发送短信通知.

检查项大体可分为两类：基础特性检查项,业务检查项.

• 基础特性检查项是指与机器相关的监控项,如cpu,流量,包量等.
• 业务检查项则是与业务相关的服务间调用(简称模调),自动化测试等.

体检周期为5、10、20、30分钟.

7个检查特性包括CPU、网外卡流量、内外网卡包量、CPU超过80%的设备数、自动化测试告警、模调告警等,并分别进行评分.评分为0则正常,小于一定值则需要关注,总分大于一定值为异常.

上图里面,变更5分钟,告警数,容量告警、DLP 告警都是零,第10分钟也是这个告警,到了第20分钟出现四条模调告警,就触发一条告警信息给运维,运维通过邮件把这个发给业务负责人.保证这个变更是闭环,从设备的申请到发布自检到报告都是一个闭环的流程,这个运维是非常高效的.

刚才说过的传统的扩容跟织云扩容的对比,传统扩容基于用 Excel 或 Word 来管理业务信息和资源信息,稍进步一点的用数据库来管理.运维要登录跳板机或总控台,在总控台用命令行或页面跑各种安装脚本,脚本之间需要人工确认.

比如说装一个 MySQL,安装完成以后要手工把IP、端口等信息粘贴到下一个脚本或流程来由运维继续执行,脚本间没有全流程概念,需要人工去更新信息.一个业务工程师同时只能做一个模块的变更或扩容,如果并发同时做多个变更,极易出错出现故障.

织云高效的实践是,它是以运维标准化为基石,以 CMDB 为核心的自动化运维平台.通过 Web 界面的一键式上云,基于业务原子任务和流程引擎,形成一个完整的运维流程,最后并行执行.一个模块一个人5到10分钟就可以做完所有操作.

高效扩容的背后是基于一套标准化的理念.包括分层标准化、可运维规范、软件标准化,并且标准化以 CMDB 落地.

我们以 CMDB 为核心,把资产配置、硬件配置、软件配置、运营配置,比如说这个IP是在哪个地方部署的,因为我们有容灾,还有权限的管理,我们模组之间有管理,把这些配置都打包到 CMDB 里面,通过引擎实现自动化发布机制.到线上服务以后,后面还会有监控告警、一致性、变更体检等等闭环的服务.从 CMDB 到线上服务,整个流程都是闭环的.

这是运维标准化的实践.把架构、配置、监控、软件包、工具等等先实现标准化,然后落实到 CMDB 配置中心,通过工具或流程快速交付.标准化是要落地,如果没有这些跟 CMDB 的实践,标准化就是一个纸面的东西,是没有办法实现的,这四步缺一不可.

3.3 有状态层的自动扩容

刚才讲到无状态的扩容,现在是讲有状态的数据层扩容.通常来讲,数据层扩容是 DBA 工作中工作量最大、最易出故障的变更.但在我们这边,数据层扩容已经实现了与无状态层一样的灵活性.

我们的数据层分两层架构,上层是无状态接入机,负责数据路由配置,下层是存储机,负责数据存储.

接入机扩容跟无状态层的扩容方法类似.

存储层通过数据搬迁,同时并行修改接入机路由表来实现扩容.

存储层扩容的原理是,我们首先把记录 KEY HASH 1万到桶,桶再分配到存储机的存储单元,通常是 1GB 一个内存存储单元,一台 64GB 内存的存储机有56个存储单元.

桶是搬迁最小单元,通过桶搬迁方式来实现记录的扩缩容,整个桶搬迁是全自动化,运维只要指定一台或一批目标存储机,桶和记录就会自动搬迁分布到目标存储机之上,搬迁过程中代理机的路由表是实时更新的,因此搬迁过程中业务的访问不受任何影响,只是搬迁过程中的KEY不能删除,但这个过程只有数秒时间,业务基本无感知.

上图是数据层的架构,存储层分内存存储和固态盘存储二级,数据可以自动根据冷热规则在内存和存储之间分布,以节省内存成本.目前我们共有2万多台 DB,人均管理两千多台 DB,存储机扩容的效率很高,但由于数据搬迁速度较慢,通常是一台 64GB 内存的内存存储机在生产环境下需要1小时完成搬迁,因此3千台 DB 花了两三周时间来完成扩容.

四、压测和演习

运维摆脱了设备扩容的人海战术后,就像特种部队一样,把精力聚焦到有价值的工作中,譬如业务架构评审、资源评估和规划,压测及演习、应急预案、监控等等和业务相关的事情,这是业务运维应该更关注的地方.

4.1 红包容量评估

如何评估活动容量?我们会根据四个维度来评估容量.首先是IDC 的容量,像电力、机柜、专线的容量等等.以服务器为维度,会关注四个核心指标,CPU、网络的磁盘IO、网卡流量、网卡包量,判断这个设备的整体容量水平.这是基础的维度.

业务这边,我们会有业务维度的评估,譬如红包业务的每秒红包容量.根据设备的能力来推导出业务容量的水平,譬如模块单机能抗3千个 QPS,假设模块下有一百台设备,那么该模块的 QPS 就能支撑30万 QPS,并且这个容量负载必须是线性的增长.

4.2 红包压测

容量完成扩容前后,我们会多次对模块和业务进行压测,来评估容量基准值,扩容之后的水位能否支持到业务高峰.

我们通过演习的方式来模拟实际的用户请求.

我们的业务是多地部署的,譬如 QQ 是分布到深圳、上海和天津三地.那么,我们把全国流量调度到其中一地,譬如深圳,观察容量、延迟等指标,因为我们业务关键链路会有几十个模块,在这个过程中,有些模块如果有问题会出现异常或告警,比如说有些模块 CPU 会过热,会上到 80%-90% 的高水位,或者失败率开始增加.业务会根据这些模块的容量,根据高负荷的模块做一些性能的优化或扩容.保证这些模块负载都是合理范围.

第二部分是线上灰度,我们会逐渐放开抢红包的活动,譬如对华南区域的用户放开”刷一刷红包”的入口,用户有提示先去刷,刷的时候发现这个产品的测试是否符合预期,关键模块的容量是不是达到我们的标准.我们会有灰度逐步放量,最后全部放量.还有一个小年夜的多时段,比如说在晚上定点来分别放开”刷一刷”这个活动的流量.

这是有一个压测出问题的例子,我们在压测的时候发现有一些存储机的网卡流量被压爆了,这是一台网卡流量的巅峰,平时是 200-300Mb 的水平,到了压测的时候压满 1Gb 的带宽.我们分析发现,这个是存储器上有热 KEY,然后我们根据压测出的情况继续推动各种优化.

4.3 红包演习

上图是红包演习的范例,我们把手Q的深圳 IDC 1000 万用户调到天津去,以模拟深圳的IDC挂后天津的压力.运维日常以及节假日前会通过各种调度来做各种演习.

五、运维策略

5.1 业务错峰部署

业务策略多变,之前评估供给的设备不一定能满足实际产品指标,因此我们还做了业务错峰部署,在一批服务器上同时部署了红包和空间的服务,一台机器会部署两套服务.在红包活动时这些设备用于红包活动,红包活动结束后,通过调度快速把机器调度到空间服务进程上,这样错峰来重用服务器计算资源.

大家可能会觉得这种切换风险比较高,后来经过我们的验证,我们的调度能力还是确保这些多设备的复用达到我们的预期.我们通过技术的方式来做,即可以做到业务错峰,也可以进行扩容.

5.2 柔性保护

在活动过程中还有很多服务故障,我们还需要对服务的柔性做一些测验.我把我们”刷一刷红包”分层,针对每个层出现的问题做一切特殊的过载保护.比如说QQ用户,如果8点准点开放给用户,同时会有2亿的用户涌入这个架构,系统的峰值会非常高.

在用户层我们做了错峰的开放,譬如在20：00到05分把用户随机放进来,把请求随机分布在300秒区间.

如果接入层这边出现容量和负载过高,我们会在这里随机丢弃一些请求,根据用户UIN的HASH进行随机丢包.

如果是银行这边的接口出现瓶颈,我们会降低现金的的派发速度等等.消息系统出现瓶颈,我们会设置一定比例的用户不发送消息.每一个层都会跟研发一起考虑这个容量出现问题的时候怎么做柔性保护

这是我们运维这边一键下发属性的界面(见PPT),我们可以选择不同的模块,然后选择柔性的配置表,通过一键下发的方式将柔性策略实时下发,并实时生效.

六、活动现场

6.1 看监控

前面的扩容、压测和应急预案等已经做完了,到了春节活动现场,运维主要有三类工作,一是看现场视图,二是扩容过热模块,三是处理热KEY.

有些业务模块,通过压测手段是没有办法模拟现网的,在现网情况下会出现容量超过阈值的情况.运维会通过视图或告警快速发现,经过简单评估后从备用资源池中紧急提取设备,对模块进行扩容,把容量负载降到正常水位.

这是大年30运维部门的现场(见PPT),大家都在看视图和快速扩容模块,这是我们运维主要做的事情.

上力量是织云的运维核心视图(见PPT),可以看到集成了各业务核心视图,包括红包大盘、红包相关模块告警,QQ 核心模块容量,红包视图等等,运维主要是看这些视图,看告警来保证活动是正常的.

6.2 现场挑战-热KEY

数据存储在活动高峰面临的挑战之一是热 KEY.即某一些热点记录的访问量过大,高峰期甚至上涨百倍.

我们有几种常用方法来处理热KEY.首先是拆记录,比如说这个记录的访问量非常大,每秒有十几万,我们会把 KEY 的 Value 分拆成多份,分布到不同的表实例.

其二是限制记录的长度,有些 KEY 的 Value 很长,在热点访问时会给存储机内存拷贝、网卡造成压力.我们会查找出过长的 KEY-Value,让业务通过字段压缩、删除冗余字段等方式来减少记录长度.

第三是把千兆的存储机换成万兆的存储机,让网卡流量突破1Gb限制,在现网万兆存储机能跑到 5-6Gb 的水平.

第四是记录打散,快速通过搬迁方式,把集中的热点 KEY 分布到十几台存储机来支撑.

最后,业务在前端可能会有几十台逻辑设备,业务可在逻辑设备上用内存做前端缓存,减少对后端存储机的访问.

七、回顾

回顾整个红包的活动策略,万台级设备扩容仅用了2天时间,极大解救了运维.运维从扩缩容的工作量中解脱出来后,可以把更多的时间和精力更深入理解业务,为业务在质量、成本和速度几个方面给用户提供更多的价值,为业务保驾护航.

原文来自微信公众号：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/2710.html