V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2913 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

一、活动背景

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

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

过年大家都刷过微信红包和 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 是多少，什么机型，运营状态，操作系统，监控等等。

变更具备交付后不管的能力。

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

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

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

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

体检周期为 5、10、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.1 红包容量评估

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

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

4.2 红包压测

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

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

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

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

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