阅读《2024 中国开源开发者报告》赢大奖，扫码申请享特权

本文主要介绍网易支付全链路压测平台建设思路，规划一套完整的压测体系和实施过程及最终结果。通过本文可以了解到网易支付目前生产环境的整体架构，生产全链路压测的过程，性能优化的思路等。

受限于篇幅等原因，本文一共分为上下两篇，本篇为上篇，主要介绍网易支付全链路压测的背景，压测平台构建思路以及平台组件的实施方案等。下篇主要介绍接入平台压测工具的业务改造，生产压测实施和性能优化、对外开放能力、生产容量巡检机制、总结和展望等。

一、前言

1.1 背景

在业界中，常见的性能容量评估为搭建一套性能环境，在性能环境进行业务容量评估或性能问题定位；但因环境尤其是硬件资源、链路和数据层面等，无法验证或获得业务系统在生产环境的性能指标，因而无法真实评估线上的容量情况。同时行业内，认为存在重大变更或者领导有要求等情况才发起性能测试，针对紧急项目上线或日常需求等，为保障迭代速度，往往忽略性能测试或直接跳过性能测试。基于上述情况，我们很难真实评估线上业务真实容量，从而在针对活动或大促场景下，为了可平稳支撑，在缺乏实际数据支撑情况下，依照性能数据和业务owner个人评估，对应用进行扩容，但实际是否可支持或是否存在瓶颈点均未能明确。

1.2 现状

网易支付为具有第三方支付牌照的支付公司，为网易集团内部商户提供收单，支付、资金结算和定制化金融方案等能力，为广大用户提供安全快速稳定的支付能力。前期支付也是上述业界较为通用的压测方案，以此来评估线上的整体容量，但是实际上，评估出的整体容量与真实存在较大的差距；同时随着外部监管要求变化、业务的发展和技术架构的升级等，网易支付的整体业务复杂度、技术架构和机房架构等均有重大的调整，为给商户和用户提供更加稳定可用的支付服务；同时在互联网降本提效背景下，需要更加准确评估生产的容量和潜在性能瓶颈，用于决策规划资源。

1.3 何为全链路压测

全链路压测为针对生产环境和真实业务场景，模拟海量商户/用户的请求，来对整个业务系统容量评估和发现潜在性能问题的一个技术手段；相较与传统的压测手段，尤其针对生产复杂的网络架构和复杂的业务场景等，可发现并解决整个业务系统的可用性、扩展性以及容错性。

全链路压测可带来的价值：

• 技术层面：可更真实反馈业务整体容量，推进技术架构演变，提升整体可用率和降低成本；

• 业务层面：可提供更加可用和稳定的对外服务，提升用户体验，创造更大的业务价值（可支持更加复杂的业务场景和支撑大促和活动等）；

1.4 与传统压测的区别

与传统全链路压测相比，因其涉及压测模块等有较大的区别，结合我个人的理解和参考其他公司同事总结，整体如下：

总结：结合这些区别和上面实际遇到的痛点问题，传统压测和全链路压测关键区别也就三点：环境问题、链路差异和成本；

二、整体介绍

2.1 目标

网易支付构建一套全链路压测体系的目标主要是为解决如下核心问题：

• 准确评估生产业务容量，确保可按照与商户约定SLA交付。

• 业务拆分和技术架构演变，可有有效方式评估性能情况和确定容量基线，及时发现潜在的问题。

• 发现生产潜在的容量风险点或瓶颈，为后续技术架构演变提供方向。

  同时在架构时，需要考虑对外开放能力，可支持商户对接网易支付全链路压测，实现商户全链路压测与网易支付全链路压测联动。

2.2 生产架构

为了更好地理解全链路设计思路，首先介绍一下网易支付生产的架构，主要分为两个部分：网络逻辑架构和应用架构。

2.2.1 生产网络逻辑架构

首先为大家介绍网易支付生产为同城双机房双活架构（因金融的特殊性，主数据库仍在一个机房内），在每个机房内部，因监管的要求，划分为入口隔离区、应用隔离区、数据库隔离区和合作方隔离区等；单个机房网络架构如下图所示：

基于整体机房网络架构的复杂性，其影响整体容量的关键不仅仅为应用服务本身，还会涉及到各种硬件资源等。同时因金融的特殊性、网易支付现有的集群规模和现有网易云环境的支持情况，目前网易支付未上云，针对应用机器，主要使用Kvm等虚拟机进行资源分配和隔离。

注：上述为网络逻辑架构，实际物理架构为按照上述逻辑架构进行实施，部分逻辑架构涉及到的基础资源如防火墙和交换机等可能为同一组。

单从机房内部进行压测，我们将无法从用户/商户层面较准确的评估整体的容量情况，需完全模拟用户或商户的请求链路，从BGP外网入口进行压测；

2.2.2 服务流量

支付生产针对商户和用户的流量均通过API网关，其整体的流量调度如下图所示：

针对应用间，采用微服务部署，相互间dubbo实现接口调用，同时服务间按照机房隔离，同机房仅可以订阅和调用到本机房的服务。（后续单元化后，会存在跨机房基础服务的调用，这块后续架构调整后，再单独介绍）

2.2.3 数据库高可用部署架构

网易支付目前线上主要使用MYSQL、DDB和ORACLE（近几年一直在做去O工作，预计2022年可完成去O工作），接下来介绍数据库在网易宝双机房下的部署架构。

2.2.3.1 DDB

DDB为网易自研的分布式数据系统，主要为对单实例数据库，如MYSQL等，提供一套横向扩展和完整管理的能力。基于高可用和稳定性等考量，网易支付目前采用DDB的DBI接入模式。在网易支付双机房架构下，其整个高可用部署架构如下图所示：

其中经过DBA团队后期的演变，针对sysdb和不分片节点均采用内部自研的工具进行高可用切换。

2.2.3.2 ORACLE

ORACLE前期主要做为网易支付核心业务的存储服务，其服务稳定性和数据安全性直接影响到生产核心服务，其整个高可用部署架构如下图所示：

2.2.3.3 MYSQL

MYSQL作为支付业务系统使用最多的关系数据库，针对核心服务一律要求生产环境为一主一从一跨机房从，其整体高可用架构如下图所示：

2.3 整体设计

基于上述的分析，需构建一个全链路压测平台，平台具有完备的链路监控、压测管理、报告输出和推动链路优化等特性；整体平台大致架构如下：（本章节主要构建一个全链路压测平台的方法，对于具体实现落地在下章节介绍）

2.3.1 链路相关

链路相关主要分为三部分，分别为压测前链路梳理、压测中的链路监控和压测后的链路优化。

目前网易支付内部服务微服务化，且还在不断拆分中，同时支付业务场景的多样化，在压测前必须对业务和链路进行系统化梳理。链路梳理因涉及业务复杂的架构和流转，目前业界均无较好的解决方案，更多是采用有限的工具化和人为地梳理，因而这块较难在平台化中去实现。（因而这块更多是形成一定标准或规范，未在平台中具化体现）

在全链路压测过程中，我们需要实时都线上的业务和资源进行监控，防止对生产业务造成影响，同时需要有一个熔断机制，在生产系统业务或资源存在异常时，自动关闭生产压测。基于网易支付自身的特性，我们主要分为五大模块的监控：机器资源监控、业务监控、应用监控、数据库监控和网络监控。

在全链路压测完毕后，需要对整体链路进行分析和对比，基于链路中，rt、错误率等对比，发现潜在的问题并进一步进行分析，推动链路的整体优化。

2.3.2 压测相关

压测相关主要分为三部分，分别为压测前的场景准备和管理、压测全局化管理和压测执行。

基于链路梳理，可具化具体的压测业务场景，比如网易支付SDK余额支付场景等，为全链路后续的可持续化，将这些场景统一管控起来，并完成对应的压测脚本等。

压测全局化管理，支付作为金融业务，对资金安全和系统稳定性等有较高的要求，为应对这些挑战，增加对全局压测的管控，比如全局的压测开关、压测白名单等。

压测执行为全链路压测关键部分，其已包含了具体的压测业务场景，再基于压测计划确定对应的压力，基于此发起压测。在支付业务场景下，流量录制等手段对生产环境有较大的限制，此块采用模拟真实用户请求来发起。

2.3.3 结果相关

结果主要包括两部分，分别为全链路压测报告和报告对比。

在压测执行完毕后，获取对应压测的结果，比如TPS、RT、MRT等，同时还需要获取链路上涉及的结果，并智能化分析潜在的风险和问题。

报告比对，主要为与同场景同并发下，压测结果和链路资源结果等进行比对，发现本次结果与历史结果的偏差和分析偏差的主要原因等。

2.3.4 数据铺底

在生产环境进行压测，因用户属性的特殊性和防止对真实用户造成影响，一般会对用户、商户或商品等信息进行铺底，该用户、商户或商品等均在压测环境生效。在网易支付实践中，为可真实反馈线上压测链路，也需要对用户进行铺底，尤其涉及用户余额、绑卡信息和钱包等。铺底涉及的业务系统和链路较为复杂，且在网易支付铺底多为一次性工作，因而这块未在平台化中进行体现。

2.4 基础设施建设

在上章节中，介绍了全链路压测平台的大致功能划分和职责，对比图中很重要的下半部分未进行介绍，这块主要依赖基础设施的建设，在本章节中，进行展开介绍。

全链路压测系统涉及多系统和多中间件等，为了确保压测规范的落地和减少各个业务系统的改造等，需要提供一个统一化和可快速接入的设施。同时通过全链路压测可发现潜在的问题，也需提前规划这些问题的通用技术解决手段，进而推进我们整体技术基础设施完善。

2.4.1 全链路追踪系统

在全链路压测规划阶段时，已经在为后续技术架构演变方向中，明确构建和完善网易支付技术基础设施，其中包含全链路追踪系统。

全链路追踪系统针对链路信息透传，已经有一套通用的解决方案，因而可在全链路压测系统中新增一个压测模块，负责压测相关逻辑的处理，比如压测场景和压测标校验，中间件影子库切换等。

2.4.2 API网关

网易支付线上约90%流量经过自研的API网关中，作为流量的最前站，需要对流量染色进行区分和合法性校验，因而会在API网关中设计一个压测模块，负责对压测流量的管控，同时对压测流量标识打通压测平台的管控，对压测进行精细化的区分。

2.4.3 基础组件

网易支付基础组件建设主要目标为解决网易支付共性的技术问题，提供一套标准化、可监控的技术解决方案。在全链路压测中，也会推进此技术组件的建设和完善。

三、实施方案

本章节将基于上述的整体方案，结合网易集团内部的产品，最终压测平台的整体如下图所示：

为快速支持生产全链路压测工作，此平台目前未完全实现，目前其中如自动化监控和熔断，报告智能分析等仍依托于负责人判断。

3.1 压测工具

3.1.1 开源压测工具

对业界常见的开源压测工具进行比对，针对分布式场景下，其中jmeter、ngrinder和funtester表现更为突出。

但是针对搭建压测平台化，针对各类复杂的场景，尤其针对存在复杂鉴权和接口复杂度较高的场景，ngrinder可以提供更大的灵活性；同时针对分布式场景下，可以通过扩展agent等来实现自动化部署压测机器。funtester在链路编排、可读性等表现较好。后续要研发压测平台可基于ngrinder或funtester来进行开发。

3.1.2 压测工具选择

结合网易支付自身的需求，规划出压测工具应具备完善的脚本管理、场景维护、压力机器扩展和稳定施压等功能，同时可针对压测结果进行时间分析和指标分析等。

对比业界常见的压测平台和公司内部的压测平台NPT，其中NPT平台与网易支付的契合度很高。其提供较完善的压测功能，如脚本管理，压测场景管理和压测机器管理等，并对压测结果的指标提供分析能力。同时NPT平台提供较为完备的API接口，可实现网易支付全链路压测平台对压测平台进行统一管控。

3.1.3 压测机器

对比历史压测需求等分析，对线上的压测不会频繁的发起，同时压测需求不同，压测机器数量要求不同。因而压测机器需要可快速动态调整，同时考虑机器成本，基于此最终选择使用网易蜂巢机器，通过创建网易支付定制压测镜像，在压测前批量创建出需要的压测机器，压测完成后进行释放。

特别注意：生产服务一般均具有防ddos功能，这儿需要提前维护白名单。

3.2 监控服务

为保障全链路压测在生产环境的安全执行，需要对线上全链路进行监控，及时发现潜在的问题或风险，并自动触发链路压测的停止，避免生产问题或扩大生产问题。基于监控的维度和现有工具的支持情况，主要分为三部分的监控：哨兵监控、网络设备监控和业务监控。

3.2.1 哨兵监控

哨兵监控为网易杭研运维部推出的一款偏APM监控系统，包含机器、应用和数据库等各个维度的监控系统。同时提供很好的扩展能力，可支持通过脚本或编码方式来自定义监控维度。

基于哨兵现有的能力，需完善整体化监控和报警机制，主要包含如下几个方面：

• 机器维度：物理机、虚拟机等均全部确保接入哨兵系统，并包含基础机器监控和有报警。

• 应用维度：针对java应用，统一接入哨兵的应用监控，包含JVM、URL和方法等监控，同时对gc、耗时等增加报警。

• 中间件维度：针对第三方中间件，比如zk、kafka等，增加对应自定义采集器，采集其特有指标，比如zk节点和主切换等，并增加报警。

• 存储相关：针对redis、memcache和数据库等，增加对应自定义采集器，采集其特有指标，比如连接数、索引使用和慢请求等，并增加报警。

3.2.2 网络设备监控

生产机房涉及各类网络设备，比如交换机和防火墙等。目前针对网络设备的监控主要在网管侧，其监控数据未与整体监控系统打通。针对防火墙的监控依赖防火墙设备厂商自带的监控功能，暂时未接入整体监控中。为保障生产压测和日常针对生产的监控，此块目前主要由网管对各个进行监控，存在异常时自动通知到业务侧。

3.2.3 业务监控

除了上述针对运行时状态的监控，还需要对业务或业务链路进行监控，这儿主要介绍针对压测的场景下补全的监控，主要包含如下几个方面：

• 压测安全性监控：针对携带压测标识，但是不在白名单或压测场景下的压测流量监控等。

• 压测数据监控：针对压测流量确保其数据按照预期落到影子库中，资金对账和业务对账等类似的监控。

• 限流降级监控：针对生产整体的限流阈值或触发限流降级的监控，防止对生产造成影响。

• 链路监控：对整个调用链路的指标，比如异常，耗时RT等进行监控。

3.3 压测平台

上面已经介绍了构建压测平台两个关键的方向，可基于API接口包装为平台的统一功能，并可基于监控数据做智能化决策等，此部分不展开介绍。本章节主要介绍提供统一化方案和工具，支持生产环境快速接入全链路压测。

3.3.1 流量染色和透传

生产压测与线下压测最大不同在于，生产压测要保证压测行为安全且可控，不会影响用户的正常使用，并且不会对生产环境造成任何的数据污染。首先要解决压测标识的设别，设别压测标识后，各服务与中间件就可以依据标识来进行压测服务分组与隔离方案的实施。

3.3.1.1 流量染色

流量从入口链路进行染色，在http接口中新增一个流量标识，标识可体现该流量对应的压测场景。API设别到该流量标识后，会对该流量进行校验，当前压测场景时间校验、接口和商户白名单校验和压测签名校验，仅当所有校验都通过后，会转换为网易支付内部的压测标识，在后续系统中对该标识和压测场景时间进行校验即可。如果校验失败，则依据API网关配置的策略，实施拒绝请求或丢弃压测标识。

3.3.1.2 压测标识透传

在单服务内，压测标识可从请求入口处获取，比如Http请求，可将流量标识放在header中；在入口链路中，支付使用内部链路系统trace，自动化增强http和dubbo等框架，解析并初始化上下文。针对调用外部的http请求，统一拦截httpclient，并设别外部域名为白名单内，则自动转换压测标为外部压测标，并填充到http header中。

3.3.1.3 压测标识跨线程透传

对于涉及多线程调用的服务来或存在异步调用场景的服务，要保证测试标识在跨线程的情况下不丢失。为减少各个业务侧的改造，此处由trace系统统一拦截线程池的提交方法，并对执行任务进行包装，保存当前上下文信息到任务中，在任务执行时，对上下文进行恢复。

trace利用javaagent对类ThreadPoolExecutor和ScheduledThreadPoolExecutor进行增强，对于入参包含Runnable和Callable的方法，对入参统一包装一次，然后继续执行原方法。

3.3.2 压测服务隔离

网易支付为同城双机房架构下，日常业务流量大部分集中在一个机房内，另一个机房承担了较少流量。在入口处设别出压测流量下，API网关将基于标识路由到特定的机房，进而实现机房间的压测流量隔离。

后续网易支付内部服务容器化后，压测服务隔离将采用独立创建压测集群实现隔离，进一步减少对生产服务的影响。（此块内部服务路由可参考之前环境治理文章：https://kms.netease.com/article/41539）

3.3.3 压测数据隔离

压测过程中，会产生大量的压测数据，需要对压测产生的数据进行隔离，防止对生产环境造成影响。主要介绍数据库和消息队列等隔离方案，针对其他的数据隔离，均采用类似的思路去实施，不再一一进行介绍。

3.3.3.1 数据库隔离

相较于业界，比如阿里和美团等公司采用的影子表的方案，其在大流量或容量上限压测场景下，可能会直接对生产数据库服务造成影响，进而对生产服务造成影响；基于此考虑，网易支付生产数据库全部采用影子库的方案，使用独立的物理机部署压测数据库。同时支付内部技术栈未完全统一，新老技术栈迭代，采用影子库方案对整体设计成本也更低。

提供统一使用包装的数据源组件，其底层设别出压测流量后，自动路由到压测数据源中，进而实现数据库隔离。

注：在后续压测过程中，有发生数据库未知原因宕机的情况，此方案可保证生产正常业务的稳定性。

3.3.3.2 消息队列隔离

网易支付内部消息队列为kafka，并由组件提供具备跨机房动态切换的消息发送组件。在trace中，对消息发送进行切入，支持三类操作：丢弃当前消息、发送消息到压测topic和正常发送，默认为丢弃当前消息。

业务侧可自行选择需要的方式，针对压测场景下，均会自动在kafka消息头中带上当前的压测标识，在消费端消费时，会自动恢复压测标识。

受限篇幅，其余内容将在下篇介绍，请关注后续文章的推出！