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