实战：618/双11大促备战全流程点点滴滴

Posted 2022-06-16 生而为人我很遗憾

最近笔者同一些朋友聊天，发现在分布式系统这块的实操经验不是太多同时对于日常工作流程和大促这样的场景也知之甚少。So，笔者总结了一下自己部门大双11、618时是如何做备战准备的，以及如何一步步进行的最终保障每一个大促平稳渡过。

PS：

1. 大厂一般对于基础设施都会自研每个公司全不一样，但原理都差不多；
2. 本文内容描述下真实经历，旨在让大家了解下，观点只代表笔者本人；
3. 因一些涉密原因，文中可能会隐藏一些真实系统的名称；

本文大概分以下几块内容：1、典型分布式系统架构（不同的应用可能会有删减）；2、大促备战流程；3、大促备战需要做哪些工作；

一、系统架构

下图中每一个节点都是集群模式部署的，在部署时一般都会考虑以下几点因素，是否需要：多机房部署、集群逻辑分组、热备、冷备，详细解释下：

• 多机房部署：同一集群对等部署在两个或多个机房共同承担流量。如果IDC有流量分配比例，那么架构师可根据上述信息调整集群规模，即不同机房的集群规模可以不对等；
• 集群逻辑分组：分布式架构的一个功能，同一集群有多个逻辑分组，每个分组承载不同的业务。是系统稳定性设计和逻辑隔离的一种通用方法；
• 热/冷备：这两种模式不是互斥的，可以同时采用：热备是为了无缝扩容，冷备主要是为了处理特殊场景比如大规模的系统掉线等，一般来讲很少能用到这种冷备预案（冷备需要人工操作）；

注意一点，一般在讨论集群规模时我们不说节点数是多少，而是说CPU核数多少。比如不会说A应用有20个节点（机器），而是采用A应用共80C这样的话术描述；

硬盘和内存一般不在考虑范围内，原因是运维部门制定容器时会规定好规格：比如4C8G、8C16G、8C32G等。业务部门只能选择哪一种规格，一般来讲不能申请定制。

上图中的架构就不详细描述了，都比较好理解。

二、备战流程简介

大体上会分4个阶段：启动会、备战、大促、复盘。如下图所示：

• 启动会：一般集团会临时组建一个虚拟小组，全局统筹，在启动会上一般会同步接口人信息、线上流量预估、IDC流量分配、大促活动安排；
• 备战阶段：一个持续的过程，先各部门自行优化系统，然后集团会组织全链路压测和故障演练，这个过程操作的全是线上系统（原因是线下环境没意义），其中故障演练一般只会告知时间并不会同步演练内容。最后集团发结论到各部门，不达标的进行整改；
• 大促期间：大促一般有两个重要时间节点，开门红和通常意义上的大促当天，两者之间会有15天左右缓冲期，比如618大促，在6.1号就会开放一些活动引流旨在发现问题，然后利用这半个月左右的时间来进行系统优化（这时上线要经过严格审批一般会到VP级别）；
• 复盘：以总结为主，收集一些数据等为下次大促提供决策数据，技术同学也会进行一些系统缩容操作，因为大促期间很多系统是按日常的10倍容量来扩容的；

上述这么多技术整改工作，其实就是为了保大促当天0点到0:20左右之间的高峰流量，有些应用流量高峰可能也就3到5分钟，一旦流量回落其实系统上的风险基本就没有了。

每年的大促基本全是这个流程，建设过程都要经历初建、生态、体系建设，最终平台化这个过程，生态层面一般要包括流程、规范、奖惩等多个节点，大体思路如下图所示。看起来有点虚（像汇报用的哈）其实不然这只是一个思路，各执行部门不会大张其鼓的来落地实施，每年都会很贴地气的一点一点进行改进。

三、大促备战内容

其实要做的事很多。先引个头，大促并不只是技术部门的事，全公司各职能部门都要参与，比如：1、食堂要保证24小时餐饮供应；2、人事要保证所有的后勤保证和制定必要的奖罚措施等；3、业务同学和产品同学除做好本职工作外，还要筹划上下游部门信息通畅，而且大促其间一般会和技术同学坐在一起。（因为618是一个流量高峰，新业务的试水和发力是个很好的机会，所以大促前往往也是需求扎堆的时候，技术同学的档期就非常重要，所以一般业务和产品同学还会买很多零食给技术同学。题外话了，其实平时也会买）。

OK，回到正题上来，我们改一下上面的架构图。技术备战就是通过通过各种监控系统抓取数据、评估系统等工作最后使系统达到一个大促状态，下图是笔者公司的监控系统示例：

有三点需要补充一下：

1. 文档的图形表示内部使用的监控系统，用于监控特定的基础设施；
2. 这些监控系统除了监控外还有管理功能，也有的公司做做成一个大的系统，anyway我们只是用功能，好用即可；
3. 公用的管理系统有时会不满足业务部门的述求，这时可以向相关部门提需求，也可以自研一个供部门内部使用最后贡献给对应部门这些都是可以；

四、技术备战流程

回到技术备战这个主题上来，首先需要明确一点，自动化和智能化这些概念是忽悠外行的，在个别场景上会有应用但并不能取代人工，另外在很多场景下并不是技术问题而是不能这么做，比如数据库故障后的主从切换，如果采用mysql这样的库很多时候都要采用手动切换，原因是技术部门不知道哪个从库在业务上承接什么角色，本来主库写出错了你给切到一个供C端使用的从库上来，好吧读也不行了。

一点题外话，大家在了解技术问题时一定要结合业务来讨论，否则讨论有可能就会变成很内卷。

真实的技术备战是半自动化的，数据收集一般是自动化的、数据分析是半自动化的、系统扩容根据容器部门提供的能力而定很多时扩容也是人工操作的、降级/限流这些操作很多时候是手动或半自动的（原因是阈值只是一个固定值无法智能判断线上真实场景，开关的切换也是大促值班时的一些重要工作）。一般技术部门的备战流程如下：

4.1、关于自动化

自动化备战备战过程主要包括模拟数据构建、业务链构建、全链路压测、弹性伸缩、资源调度、自动化预案执行、限流验证。这些过程都可以自动化完成。详细如下：

五、技术备战实操

主要是通过技术手段收集数据，然后从基础设置稳定+应用部署合理+应用性能达标这三大块进行整改。注意应用都是集群方式部署的，流量也是根据负载分配的，单节点有问题不代码整个应用有问题，但单节点有问题可能会影响整个应用，所以要对每个节点都要进行检查后再综合分析集群。

5.1、应用篇

检查的主要是一些主机和中间件的情况，大体包括应用主机、应用情况、网络、db、es、cache等多个方面，对应用进行体检。目的是保障应用的健康，防患于未然。本文中会罗列部分重要的检查项。先看下应用的线上故障画像，也就是应用备战的主要内容：

5.1.1、主机

主要目的是检查平时网络稳定性，比如偶尔会有重传等，可能要做机器替换，为大促期间排除干扰，避免不必要的小问题而引起的蝴蝶效应。

5.1.2、应用

5.1.3、Mysql

主要是查看以下几项

1. ​梳理出慢SQL出现问题，可能导致的蝴蝶效应的薄弱点；
2. 慢Sql日志订阅，覆盖到物理机上的所有数据库，避免被间接影响，对慢Sql优化覆盖到所有数据库；
3. 梳理出那些业务点，强依赖db，能否用es等替换，识别出可能的风险点；
4. 监控是否有缓存穿透的情况；​

后续还有ES、MQ、REDIS等，就不详细描述了，得点的结构摘一部分如下图所示：

2.1、负载篇

来看一个其中一个部门的真实系统的依赖图，出于保密原因放一个缩略图，目的是为了大家以后讨论时一定要带着场景来聊，没有业务场景光聊技术很容易内卷（第二次强调了场景的重要性了）。

负载涉及的点比较杂，一般包括：网络、IDC、CDN、集群、分组、VIP等，还要参考当年的流量分配和流量预估来调整系统部署和配置，比较杂需要掌握的知识点也多，建议由高级工程师或架构师来统筹。负载可初步认为是解决以下问题：

• 消除单机房部署：

1. 评估机房部署方式；
2. 按流量评估集群规模；
3. 若有新机房或者新机器申请时，如何分配；

2、需调整负载不均衡的分组配置，

1. 防止物理上机房分组机器数量不均衡，分组之间机器数量差距过大；
2. 万一多机器的机房网络有问题，切换到机器数量少的机房时，流量扛不住；
3. 逻辑分组均衡，上下游分组调用情况要均衡，

3、机器配置差距的调整：

1. 不能低于集群中的多数机器的配置，统一同一分组中机器为同一配置；

4、vip配置：

1. 主要是web端，不要有遗漏，暂时不向对外提供服务的，可以置成冷备；
2. 需要核实生产负载均衡ip是否已全部挂在了np上；
3. 域名解析方面，运营商网络配置，三大运营商一定要配置vip解析。

2.3、监控篇

这里的监控单指接口方法监控，数据分析后会根据流量和业务重要性等把接口进行分级，再配置监控Dashboard等。需要注意一点，大促当天业务部门的技术同学只监控接口稳定性和性能，并不监控主机、数据库等基础设施。因为基础设置是由专门的部门统筹处理的。如果是重要的应用，可以向运维部门申请资源，比如大促当天需派一个同学和业务部门的同学坐在一起一起来监控系统。这样出了问题好沟通，解决起来也会更效率。监控备战总体可分为：1、收集数据；2、分析梳理；3、优化程序；4、配置监控dashboard；

2.3.1、数据收集

一般公司都有专门的系统可导出方法级别的数据，一般会关心以下指标，如下图，出于保密原因，省略了应用名和接口名称两列。

2.3.2、分析梳理

除了给接口分级外，还要结合监控配置情况来调整监控系统的配置，比如告警的触达方式、触达人、值班人员、阈值是否合理、采集频率等。大体包含以下几个大项：

2.3.3、配置监控面板

这个没啥好说的，下面是笔者公司的一个监控系统的画图，根据分析结果配置即可。

六、稳定性保障

大促备战概括来讲就是稳定性保障工程，所以笔者单抽出一个小节总结下与稳定性相关的内容可能会与上面内容重合，不过没关系，本节就是为了突出重点。

6.1、容量规划

人工估算，线下性能压测估算，线上压测（模拟请求、复制请求、引流），全链路压测这4种方式来演进和设计。公式为预估业务量级/单机能力=最少机器数+BUFFER。这些值最好是在线上进行，因为线下的数值不准不具体同等环境下的参考性。在压测时要事先制定压测上去，一旦达到预定值就停止压测，避免影响正常用户的线上体验。前面几种只是单机压测，仍有很多不确定性。全链路压测是一种全闭环的压测功能，更完善。这种方式一般采用憋单或打标的方式进行。

6.2、线上压测

• 线上模拟压测：适用于新上线或调用量小的业务系统；这种方式的缺点是要清理很多数据；
• 线上请求复制压测：主要用post_action、tcpcopy、tcpdump回放技术来实现。这种方式是复杂性比较高；
• 线上引流压测：一般常用nginx反向代理的负载方式来引流；这是比较推荐的一种方式；

6.3、全链路压测

这个最好是以平台的方式运行，其实现思路可以是动态从线上剥离一部分机器到沙箱环境专用于压测，测试完成后再回归线上集群。另外一种测试方式是通过隔离环境+修改系统时间+影子系统，提前穿越的方式来测试。

链路压测时要注意数据隔离防止污染真实用户数据，数据隔离一般有三种方式：

• 统一存储打标区分，缺点是会污染线上数据；
• 第二种mock数据缺点是真实性存在问题；
• 第三种打标隔离存储，最安全也是工作量比较大的种方案；

6.4、故障演练

首先要分析系统的依赖，把故障控制在可控范围内。在系统实现上可分为重现、演练、突袭多种场景，故障的演练主要是为了解决监控缺失、告警缺失、不及时等一系列问题。这个体系一般是以破坏性的方式，去保证系统的稳定性，系统依赖分析一般如下图内容所示：

6.5、系统自我保护

限流、降级、流量调度、负载保护是采用一种自动化的方式覆盖整个链路的自我保护机制，不需要人为干预。对外限流，对内降级。

• 限流：洪峰限流：对入口流量进行令牌桶方式限制；回调限流：主要是定时任务和消息这样的定时或延时程序。主要是防止堵塞的消息短时间内发现，压跨下流系统，一般采用漏桶算法；
• 降级：需要对依赖进行梳理，对非主流程节点进行融断处理；
• 流量调度：主要是应对机器能力不均衡的情况。均衡是屏蔽软硬件的一种手段；
• 负载保护：主要是方法骗过你于限流阀值设置不合理或出现大面积机器问题后，单机的限流策略。通过减少流量流入保护系统的稳定运行。

七、预案

在上述备战过程中，有些问题是可以优化的、有些是来不及处理或无法处理的。这时就要制定相应预案，一旦出现了预案中的风险问题，可通过指定预案来处理。预案一般会有专门的平台处理，有些可以集成一些自动化功能和操作功能配置能力。也有的是一份纯文档。这里就不详细介绍了。

八、个人感受

个人一点感受：首先大促很累，需要准备2个朋左右时间，大促期间还要有几天到后半夜甚至通宵。但从某种角度上来讲大促更像是一次技术大考，一次全体人员的节日，未经历过是无法体会的，不经历多次是无法全面了解的。所以 Enjoy it。