腾讯云运维干货沙龙-海量运维实践大曝光 （三）

做者丨周小军，腾讯SNG资深运维工程师，负责社交产品分布式存储的运维及团队管理工做。对互联网网站架构、数据中心、云计算及自动化运维等领域有深刻研究和理解。

12月16日，首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师、DevOps专家梁定安，讲师腾讯手机QQ运维负责人郭智文，腾讯高级工程师魏旸，腾讯SNG资深运维专家周小军出席沙龙，并带来精彩的技术分享。为了便于你们学习，特将本次沙龙讲师的演讲内容进行了整理。您也能够在腾讯织云公众号下载本次演讲PPT。

1、活动背景

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

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

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

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

挑战

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

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

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

2、活动计划

2.1 日历表

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

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

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

2.2活动梳理

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

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

3、扩容

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是多少，什么机型，运营状态，操做系统，监控等等。

变动具有交付后无论的能力。

报告根据变动和监控记录，取得变动设备和变动对象列表，而后分析这些变动对象的监控数据，得出体检结果。

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

检查项大致可分为两类：基础特性检查项，业务检查项。

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

体检周期为五、十、20、30分钟。

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

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

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

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

织云高效的实践是，它是以运维标准化为基石，以 CMDB 为核心的自动化运维平台。经过 Web 界面的一键式上云，基于业务原子任务和流程引擎，造成一个完整的运维流程，最后并行执行。一个模块一我的5到10分钟就能够作完全部操做。

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

在DevOps的实践中，织云在后面这二环。开发交付包、配置和模块名称，经过织云完成部署。

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

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

3.3 有状态层的自动扩容

刚才讲到无状态的扩容，如今是讲有状态的数据层扩容。一般来说，数据层扩容是 DBA 工做中工做量最大、最易出故障的变动。但在咱们这边，数据层扩容已经实现了与无状态层同样的灵活性。

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

接入机扩容跟无状态层的扩容方法相似。

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

存储层扩容的原理是，咱们首先把记录 KEY HASH 1万到桶，桶再分配到存储机的存储单元，一般是 1GB 一个内存存储单元，一台 64GB 内存的存储机有56个存储单元。

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

4、压测和演习

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

4.1 红包容量评估

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

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

4.2 红包压测

容量完成扩容先后，咱们会屡次对模块和业务进行压测，来评估容量基准值，扩容以后的水位可否支持到业务高峰。

咱们经过演习的方式来模拟实际的用户请求。

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

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

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

4.3 红包演习

演习不只能验证单个业务，还能验证多个业务的实际支撑能力。譬如QQ、空间、相册和广点通等业务关联性很是强，几大业务经过联合演习来评估大活动峰值的支撑水平。

由于核心支付系统在深圳，为了减小深圳IDC压力，咱们还主动把非春节业务，如音乐等调度到上海，下降深圳IDC和网络的水位。

5、运维策略

5.1 业务错峰部署

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

你们可能会以为这种切换风险比较高，后来通过咱们的验证，咱们的调度能力仍是确保这些多设备的复用达到咱们的预期。咱们经过技术的方式来作，便可以作到业务错峰，也能够进行扩容。

5.2 柔性保护

在活动过程当中还有不少服务故障，咱们还须要对服务的柔性作一些测验。我把咱们”刷一刷红包”分层，针对每一个层出现的问题作一切特殊的过载保护。好比说QQ用户，若是8点准点开放给用户，同时会有2亿的用户涌入这个架构，系统的峰值会很是高。

在用户层咱们作了错峰的开放，譬如在20：00到05分把用户随机放进来，把请求随机分布在300秒区间。

若是接入层这边出现容量和负载太高，咱们会在这里随机丢弃一些请求，根据用户UIN的HASH进行随机丢包。

若是是银行这边的接口出现瓶颈，咱们会下降现金的的派发速度等等。消息系统出现瓶颈，咱们会设置必定比例的用户不发送消息。每个层都会跟研发一块儿考虑这个容量出现问题的时候怎么作柔性保护。

这是咱们运维这边一键下发属性的界面（见PPT），咱们能够选择不一样的模块，而后选择柔性的配置表，经过一键下发的方式将柔性策略实时下发，并实时生效。

6、活动现场

6.1 看监控

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

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

这是大年30运维部门的现场（见PPT），你们都在看视图和快速扩容模块，这是咱们运维主要作的事情。

上图是织云的运维核心视图（见PPT），能够看到集成了各业务核心视图，包括红包大盘、红包相关模块告警，QQ 核心模块容量，红包视图等等，运维主要是看这些视图，看告警来保证活动是正常的。

6.2 现场挑战-热KEY

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

咱们有几种经常使用方法来处理热KEY。首先是拆记录，好比说这个记录的访问量很是大，每秒有十几万，咱们会把 KEY 的 Value 分拆成多份，分布到不一样的表实例。

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

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

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

最后，业务在前端可能会有几十台逻辑设备，业务可在逻辑设备上用内存作前端缓存，减小对后端存储机的访问。

7、回顾

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

相关文章

腾讯云运维干货沙龙-海量运维实践大曝光 （一）

腾讯云运维干货沙龙-海量运维实践大曝光 （二）

沙龙PPT下载地址：

https://share.weiyun.com/5c406a57164ed4cf7e248160aebf74c3