支付系统:全链路压测

Page content

全链路压测是支付全系统每个环节都参加的实战演习,主要对零点峰值流量进行评估,以及对承压能力进行测试,是大促前为系统查缺补漏的重要一环。

要实现全链路压测,涉及的产品很多,包括网络、应用、中间件、数据库、安全、数据等都需要改造,涉及的应用范围很广。

采集压测数据

为了模拟尽可能真实,全链路压测以线上数据为数据源,进行采样、过滤和脱敏,作为全链路压测的基础数据,数据量与线上数据保持同一个数量级,在数据库上进行区间隔离。

数据安全

为了保证安全,可以根据user_id进行隔离,压测用户集跟线上用户id不重合,防止出现意外,修改线上用户数据。

正常用户应该访问不了测试数据,测试账户也访问不了正常数据,防止数据错乱。

在实际大流量压测开始前,应进行小规模验证,确保数据读写是符合预期的。

压测流量平台

在早期,需要通过Jenkins手动触发压测流量;有了压测流量平台后,大大简化了压测的工作量。

流量平台是全链路压测的CPU,主要由两大部件构成:

  • 全链路压测操控中心,进行压测的case、压测流量大小配置以及对压测集群的管控。
  • 压测引擎,由控制台统一管控,最好部署在外网CDN集群,进行登录、session同步,能发送各种协议(如rpc/http)的压测请求、状态统计。

我们基于locust构建了内部的压测引擎。基于Grafana进行压测流量监控。

业务改造

全链路压测有不少地方需要在业务系统针对压测流量进行相应改造。

  • 比如如何区分压测请求和,和正常的请求
  • 如何跟上下游、中间件交互

影子库 - shadow db

全链路压测的链路有读有写,并且在线上进行,为了不污染到线上的正常数据, 对于数据库,可以新建一个完全一样的影子库来进行数据的隔离;通过db name前缀加以区分:

  • payment_db:真实线上用户请求写payment_db
  • shadow_payment_db: 压测请求写shadow_payment_db

内部自研的ORM能自动检测压测参数,读写shadow db。研发只需要添加好对应的shadow db配置。

中间件 - 区分压测请求

全链路压测的流量通过在链路上带上特定的压测参数进行区分,如果缺乏相应中间件的支持,在调用到下游系统的时候,压测标志就丢失了。 因此需要所有中间件的协议都支持对压测流量的识别,使得压测标识能够随着调用传递下去,使得下游的应用、基础中间件和存储都能够识别压测流量。

  • 对于Http请求,可以在header中携带压测信息。
  • 对于Golang RPC请求,通常在ctx中携带压测信息。
  • 对于缓存,我们没有用单读的缓存集群,业务使用cache key前缀来区分处理压测的请求:
    • cache key: user_info:user_id
    • shadow cache key: shadow:user_info:user_id

链路验证

链路验证往往会耗费压测项目组大量的时间和精力,电商业务具备复杂的业务特性,有上百条链路,每一条链路都需要确保能够让全链路压测引擎跑通。

本文由 络壳 原创或整理,转载请注明出处