正文
在活动现场，产品、开发和运维全部在第一线保障红包，一直坚守到大年初一的凌晨一两点钟。
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走完整个流程。
