4.2.3 大促保障的五大技术要素
4.2.3.1 技术梳理&准入
护航是围绕业务全局架构、高可用（诊断、优化、防护、演练）等技术栈对整体活动进行评测、加固、监控等，了解业务的目标、场景、特征是做好护航保障的第一要素。
图23：护航业务技术梳理
4.2.3.2 架构梳理&评估
根据快递行业主链路及业务特性进行架构梳理，对护航关键业务和核心组件进行重点保障。
接下来我们看下某快递公司的技术架构，这里我只画了核心业务系统订单、把枪、分拣主体链路和关联关系。通过梳理业务架构图，我们识别到主体链路为：
1)订单渠道→订单网关→MQ解耦→订单入库→推送订单信息给到下游业务。
2)给到把枪系统→生产消息给到MQ→生成轨迹数据并回传。
3)给到分拣系统MQ进行分拣业务。
图24：护航业务架构梳理示意图
4.2.3.3 全链路场景压测
全链路压测是以全链路业务模型为基础，将前端系统、后端应用、中间适配层、DB等整个系统环境，完整得纳入到压测范围中，以http请求为载体，模拟真实的用户行为，在线上构造出真实的超大规模的访问流量，以全链路压测模型施压，直至达到目标峰值，在压测过程中发现系统瓶颈和验证系统能力。
4.2.3.3.1 全链路压测核心流程
4.2.3.3.1.1 确定压测目标
压测目标主要包括压测范围、策略、目的，往往与业务、技术目标息息相关。例如：
压测范围：用户注册加登录，为大规模拉新做准备。
压测策略：高仿真生产环境压测，提前经历真实的业务高峰。
压测目的：探测业务吞吐极限，验证架构能力、探测性能瓶颈。
4.2.3.3.1.2 梳理系统架构
梳理清楚端到端的请求链路、技术架构、分层结构、模块划分，以及RPC、消息、缓存、数据库等中间件的使用情况，分析潜在的瓶颈点，并针对性的增加监控指标、制定应急预案。
4.2.3.3.1.3 梳理业务模型
压测的业务模型对压测结果的准确性至关重要。全链路压测的链路代表要压测的业务范围，同一条链路需要构造海量的参数集合代表不同用户的不同行为，系统的基础数据、系统预热情况等代表系统的状态。链路范围、链路的访问量级、链路的参数集合、基础数据、预热情况一起构成了压测的业务模型。
通常从以下维度梳理业务模型：
1.用户行为维度
1)确定业务接口的范围、接口的目标量级、接口的参数集合、压力曲线等。
2)根据业务特性确定压测数据的分布。例如用户的规模和地域、商品的种类和数
量、是否制造热点商家和商品等。
1.系统状态维度
1)根据业务和场景的特性，确定各组件（例如缓存）的状态。例如拉新场景，缓存命中率非常低，而日常高峰场景，缓存命中率非常高，需要根据不同的场景来准备不同的缓存预热策略。
2)根据业务和场景的特性，确定基础数据的量级和范围。例如拉新场景，需要考虑老用户召回的情况，而日常高峰场景，一般准备与活跃用户相当量级的基础数据。
总之，业务模型与业务强相关，压测的业务模型对压测结果的准确性至关重要。
4.2.3.3.1.4 准备压测脚本
根据业务场景编写压测脚本，也可以直接复用已有脚本，建议将脚本录入PTS场景，便于做场景调试。
4.2.3.3.1.5 改造升级环境
在生产环境进行全链路压测，最核心的是线上写操作不能污染正常的业务数据。因此，需要针对存储做影子库表，即正常业务库表的镜像，让压测流量的数据流转到影子库表，正常业务流量流转到正常业务库表，在逻辑上隔离两种流量，使之互不影响。
4.2.3.3.1.6 正常流量联调
常通过执行功能回归用例完成联调，是需要将正常回归流量打上流量标（例如在请求中添加Headerx-pts-test=2），这样在查找调用链路时可以精准定位。该环节主要关注点如下：
验证探针对正常业务逻辑无影响，用例的测试结果均符合预期。
验证探针对依赖组件的适配情况，无遗漏的RPC调用、采集的数据准确无误；调用链完整性是全链路压测数据安全的核心。
4.2.3.3.1.7 准备压测数据
1.确认影子库表范围
影子库表的范围就是压测链路涉及到的应用使用到的库表。在梳理过程中，需要包括库名、表名、数据量级、核心业务字段（例如商品ID、用户ID等），表与表之间字段的关联性（外键、JSON字段中的引用等均包括在内）。
2.确认偏移字段、脱敏字段
偏移字段：字段偏移可以极大的保证业务数据的安全。偏移字段一般选择用户ID、商品ID等关联字段，如果有用到Sequence类的分布式ID组件，也需要进行偏移。根据业务的实际增长选择不同的偏移量，一般会选择10年以上都不会用到的值作为偏移量。
4.2.3.3.1.8 联调压测流量
根据步骤七：准备压测数据中梳理的库表情况，在控制台填写影子规则，不同规则需要填写的字段不尽相同。
根据步骤六：正常流量联调中梳理的第三方服务依赖情况在控制台配置Mock规则。如果需要使用复杂的动态响应结果，需要申请部署MockServer。
与正常流量联调的方式基本一致，联调过程中需要将压测流量打上流量标（例如在请求中添加Header1x-pts-test=1），在查找调用链时可以精准定位。该环节主要关注点如下：
1)验证业务逻辑是否正常，用例的测试结果均需符合预期。此环节受基础数据影响比较大，容易出现某个字段不符合某些校验逻辑而导致业务进行不下去。
2)验证压测流量产生的调用链是否与正常流量一致，如果不一致需要相关人员介入排查原因。
验证影子隔离和Mock规则是否有效，如果有正式表存在测试数据写入或者影子表有正常数据写入，则需要相关人员介入排查原因。
4.2.3.3.1.9 单链路小流量试压
不同的业务、压测目标往往对应不同的压测节奏和方法，不可一概而论。除了注意以下要点之外，还需根据业务、架构、人员等自身情况，制定不同的压测计划，在尽量避免线上故障的前提下，发现更多的线上问题。
1.制定明确的压测计划、压测通过标准，相关人员必须现场支持，分工明确，统一指挥。
2.线上压测应在业务低峰时段进行，并制定应急预案。
3.应当具备监控大盘，密切关注相关监控指标。
4.遵循循序渐进的原则，单链路压测>小流量验收>全链路验收。
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.3 大促保障的五大技术要素（下） https://developer.aliyun.com/article/1224038?groupCode=supportservice
