最近笔者同一些朋友聊天，发现在分布式系统这块的实操经验不是太多同时对于日常工作流程和大促这样的场景也知之甚少。So，笔者总结了一下自己部门大双11、618时是如何做备战准备的，以及如何一步步进行的最终保障每一个大促平稳渡过。
PS：
- 大厂一般对于基础设施都会自研每个公司全不一样，但原理都差不多；
- 本文内容描述下真实经历，旨在让大家了解下，观点只代表笔者本人；
- 因一些涉密原因，文中可能会隐藏一些真实系统的名称；
本文大概分以下几块内容：1、典型分布式系统架构（不同的应用可能会有删减）；2、大促备战流程；3、大促备战需要做哪些工作；
下图中每一个节点都是集群模式部署的，在部署时一般都会考虑以下几点因素，是否需要：多机房部署、集群逻辑分组、热备、冷备，详细解释下：
注意一点，一般在讨论集群规模时我们不说节点数是多少，而是说CPU核数多少。比如不会说A应用有20个节点（机器），而是采用A应用共80C这样的话术描述；
硬盘和内存一般不在考虑范围内，原因是运维部门制定容器时会规定好规格：比如4C8G、8C16G、8C32G等。业务部门只能选择哪一种规格，一般来讲不能申请定制。
上图中的架构就不详细描述了，都比较好理解。
大体上会分4个阶段：启动会、备战、大促、复盘。如下图所示：
上述这么多技术整改工作，其实就是为了保大促当天0点到0:20左右之间的高峰流量，有些应用流量高峰可能也就3到5分钟，一旦流量回落其实系统上的风险基本就没有了。
每年的大促基本全是这个流程，建设过程都要经历初建、生态、体系建设，最终平台化这个过程，生态层面一般要包括流程、规范、奖惩等多个节点，大体思路如下图所示。看起来有点虚（像汇报用的哈）其实不然这只是一个思路，各执行部门不会大张其鼓的来落地实施，每年都会很贴地气的一点一点进行改进。
其实要做的事很多。先引个头，大促并不只是技术部门的事，全公司各职能部门都要参与，比如：1、食堂要保证24小时餐饮供应；2、人事要保证所有的后勤保证和制定必要的奖罚措施等；3、业务同学和产品同学除做好本职工作外，还要筹划上下游部门信息通畅，而且大促其间一般会和技术同学坐在一起。（因为618是一个流量高峰，新业务的试水和发力是个很好的机会，所以大促前往往也是需求扎堆的时候，技术同学的档期就非常重要，所以一般业务和产品同学还会买很多零食给技术同学。题外话了，其实平时也会买）。
OK，回到正题上来，我们改一下上面的架构图。技术备战就是通过通过各种监控系统抓取数据、评估系统等工作最后使系统达到一个大促状态，下图是笔者公司的监控系统示例：
有三点需要补充一下：
回到技术备战这个主题上来，首先需要明确一点，自动化和智能化这些概念是忽悠外行的，在个别场景上会有应用但并不能取代人工，另外在很多场景下并不是技术问题而是不能这么做，比如数据库故障后的主从切换，如果采用mysql这样的库很多时候都要采用手动切换，原因是技术部门不知道哪个从库在业务上承接什么角色，本来主库写出错了你给切到一个供C端使用的从库上来，好吧读也不行了。
一点题外话，大家在了解技术问题时一定要结合业务来讨论，否则讨论有可能就会变成很内卷。
真实的技术备战是半自动化的，数据收集一般是自动化的、数据分析是半自动化的、系统扩容根据容器部门提供的能力而定很多时扩容也是人工操作的、降级/限流这些操作很多时候是手动或半自动的（原因是阈值只是一个固定值无法智能判断线上真实场景，开关的切换也是大促值班时的一些重要工作）。一般技术部门的备战流程如下：
自动化备战备战过程主要包括模拟数据构建、业务链构建、全链路压测、弹性伸缩、资源调度、自动化预案执行、限流验证。这些过程都可以自动化完成。详细如下：
主要是通过技术手段收集数据，然后从基础设置稳定+应用部署合理+应用性能达标这三大块进行整改。注意应用都是集群方式部署的，流量也是根据负载分配的，单节点有问题不代码整个应用有问题，但单节点有问题可能会影响整个应用，所以要对每个节点都要进行检查后再综合分析集群。
检查的主要是一些主机和中间件的情况，大体包括应用主机、应用情况、网络、db、es、cache等多个方面，对应用进行体检。目的是保障应用的健康，防患于未然。本文中会罗列部分重要的检查项。先看下应用的线上故障画像，也就是应用备战的主要内容：
主要目的是检查平时网络稳定性，比如偶尔会有重传等，可能要做机器替换，为大促期间排除干扰，避免不必要的小问题而引起的蝴蝶效应。
主要是查看以下几项
后续还有ES、MQ、REDIS等，就不详细描述了，得点的结构摘一部分如下图所示：
来看一个其中一个部门的真实系统的依赖图，出于保密原因放一个缩略图，目的是为了大家以后讨论时一定要带着场景来聊，没有业务场景光聊技术很容易内卷（第二次强调了场景的重要性了）。
负载涉及的点比较杂，一般包括：网络、IDC、CDN、集群、分组、VIP等，还要参考当年的流量分配和流量预估来调整系统部署和配置，比较杂需要掌握的知识点也多，建议由高级工程师或架构师来统筹。负载可初步认为是解决以下问题：
2、需调整负载不均衡的分组配置，
3、机器配置差距的调整：
4、vip配置：
这里的监控单指接口方法监控，数据分析后会根据流量和业务重要性等把接口进行分级，再配置监控Dashboard等。需要注意一点，大促当天业务部门的技术同学只监控接口稳定性和性能，并不监控主机、数据库等基础设施。因为基础设置是由专门的部门统筹处理的。如果是重要的应用，可以向运维部门申请资源，比如大促当天需派一个同学和业务部门的同学坐在一起一起来监控系统。这样出了问题好沟通，解决起来也会更效率。监控备战总体可分为：1、收集数据；2、分析梳理；3、优化程序；4、配置监控dashboard；
一般公司都有专门的系统可导出方法级别的数据，一般会关心以下指标，如下图，出于保密原因，省略了应用名和接口名称两列。
除了给接口分级外，还要结合监控配置情况来调整监控系统的配置，比如告警的触达方式、触达人、值班人员、阈值是否合理、采集频率等。大体包含以下几个大项：
这个没啥好说的，下面是笔者公司的一个监控系统的画图，根据分析结果配置即可。
大促备战概括来讲就是稳定性保障工程，所以笔者单抽出一个小节总结下与稳定性相关的内容可能会与上面内容重合，不过没关系，本节就是为了突出重点。
人工估算，线下性能压测估算，线上压测（模拟请求、复制请求、引流），全链路压测这4种方式来演进和设计。公式为预估业务量级/单机能力=最少机器数+BUFFER。这些值最好是在线上进行，因为线下的数值不准不具体同等环境下的参考性。在压测时要事先制定压测上去，一旦达到预定值就停止压测，避免影响正常用户的线上体验。前面几种只是单机压测，仍有很多不确定性。全链路压测是一种全闭环的压测功能，更完善。这种方式一般采用憋单或打标的方式进行。
这个最好是以平台的方式运行，其实现思路可以是动态从线上剥离一部分机器到沙箱环境专用于压测，测试完成后再回归线上集群。另外一种测试方式是通过隔离环境+修改系统时间+影子系统，提前穿越的方式来测试。
链路压测时要注意数据隔离防止污染真实用户数据，数据隔离一般有三种方式：
首先要分析系统的依赖，把故障控制在可控范围内。在系统实现上可分为重现、演练、突袭多种场景，故障的演练主要是为了解决监控缺失、告警缺失、不及时等一系列问题。这个体系一般是以破坏性的方式，去保证系统的稳定性，系统依赖分析一般如下图内容所示：
限流、降级、流量调度、负载保护是采用一种自动化的方式覆盖整个链路的自我保护机制，不需要人为干预。对外限流，对内降级。
在上述备战过程中，有些问题是可以优化的、有些是来不及处理或无法处理的。这时就要制定相应预案，一旦出现了预案中的风险问题，可通过指定预案来处理。预案一般会有专门的平台处理，有些可以集成一些自动化功能和操作功能配置能力。也有的是一份纯文档。这里就不详细介绍了。
