首页 > 其他分享 >生产线上的全链路压力测试

生产线上的全链路压力测试

时间:2024-11-08 15:48:09浏览次数:3  
标签:模块 系统 生产线 测试 链路 Shadow 测试环境 隔离

1. 背景介绍

随着硬件性能越来越强,带宽越来越高,数据越来越多,传统的单机应用已经无法满足用户需求,取而代之的是由各种组件基于网络而构成的软件系统。

但这种软件系统,在带来更强大的计算能力的同时,也引入了单机时代所不具有的复杂性。今天,一个完整的软件系统,模块数量少则几十,多则成千上万。并且,为了提高开发上线速度,这些模块会由不同的团队使用不同的语言开发,这也让模块间的通讯变得更加复杂。

同时,今天的业务模式相比过去也发生了很大的变化,类似双十一的促销活动,会让系统承受数倍、数十倍于日常的压力。所以,压力测试变得日益重要,但传统的测试方法也变得越来越无法适应业务需求。

2. 专用测试环境的问题

在单机时代,使用 1:1 的测试环境,是非常好的压力测试方法。但到了网络时代,这种做法却可能非常不切实际。

首先是成本。要测试单机软件,即使是独立开发者,绝大多数情况下也可以轻松地购买一台独立的测试用计算机;但今天的系统所需的资源太多了,要想1:1的按照生产系统搭建一套测试系统,单是服务器成本就会高的让大多数公司难以承受,更不用说还可能有带宽、电力、机房等费用。

即使公司财大气粗,真的1:1 建起测试环境,保持这个测试环境与生产环境的软件、数据完全一致也充满挑战。

因为是测试环境,大家会在上面不断部署各个模块的测试版本,所以,必然会有程序员测试完自己的模块之后没有将其恢复成生产版本,长期下来,测试环境与生产环境的差异会越来越大,导致测试结果失真。

再者,由于成本实在太高,我认为也没有公司能壕到为每个开发组配置这样一套测试环境,也就是说,大家必须共用同一套环境。这时,如果没有极好的内部协调机制,多个开发组同时进行的测试也会影响测试结果。

还有测试数据的问题,如果不能保证测试环境的数据与生产环境接近甚至相同,测试结果就不可信。比如一个类似微博的系统,像我这种普通用户一般只有几十或几百人关注,所以我发一条消息,随便怎么做都可以很容易地通知所有关注者。但对一个千万大V,情况就会截然不同。所以,我们不能简单地使用模拟数据进行测试。

为了让测试结果真实可靠,最好能够把完整的生产数据导入到测试环境。乍看上去,这只需要简单地备份恢复下数据库,但生产环境包含大量敏感数据,随意复制到测试环境无疑会极大地增加数据泄露的风险。

3. 在生产环境进行测试的问题

因为使用测试环境进行压测存在诸多困难,人们就把目光转向了生产环境,尝试直接利用生产环境上的压力低谷时段进行测试。但这是一种侵入式的解决方案,涉及到修改甚至重新定义业务逻辑,所以同样面临巨大挑战。

如下图所示,蓝色框是原有业务逻辑,橙色框是为实现这一方案而新增的逻辑。表面上看,这些逻辑只需要增加一些 if/else就能实现,但实际情况则要复杂得多。
在这里插入图片描述

假设我们要修改的是一个网购系统,那么用户购物下订单的流程应该会涉及到用户、订单、支付等一系列的模块。

如果我们要修改用户模块,在那个菱形框里,要如何才能判断应该走测试逻辑还是生产逻辑呢?比较常见的方法是预先指定一个用户ID的范围,如果是这个范围的用户,就走测试逻辑,否则走生产逻辑。

用户模块之后,逻辑走到了订单模块,这时,我们可能仍然希望通过用户ID来判断是否应该走测试逻辑,但实际情况却可能是:经过一系列的复杂处理流程,订单模块根本看不到用户信息,所以此路不通。

为了让订单模块能区分出正常订单和测试订单,就要求用户模块在橙色的方框里进行特殊处理,比如给订单号加上特殊标记等。但是,在一个复杂的系统里,用户模块并不容易知道后续流程要经过的所有模块,所以,为了不影响正常的生产逻辑,仅仅保证测试状态的正常传递就需要付出不小的努力,更不用说还要考虑是否要访问不同的数据集,是否要模拟第三方服务等各种情况。

很明显,这种业务逻辑的修改,所需的工作量与功能点数量成正比。但除了巨大的工作量,更严重的问题是,在辛苦的修改之后,有谁能保证所有需要做的修改都改了,并且改对了?而万一有遗漏或错误,就有可能破坏生产系统,这个风险实在是太大了。

4. 解决之道

4.1 一致性和隔离性

从前面的分析可以看出,传统的测试方法或者成本高昂且得不到准确的数据,或者工作量巨大且存在破坏生产系统的风险。因此,MegaEase认为,要解决网络时代的全站压力测试问题,必须使用一种全新的方法,而这种方法的关键在于“三一致”和“四隔离”。

“三一致”是指业务一致、数据一致和资源一致。也就是说,测试系统和生产系统应该完全相同,只有这样,才能得到准确的测试数据。现实地说,100%的一致并不容易做到,比如,我们通常无法要求第三方配合我们进行测试,所以,只能使用模拟的方法替换掉部分第三方依赖。但我们仍然需要尽最大可能保证两个系统的一致性。

“四隔离”是指业务隔离、数据隔离、流量隔离和资源隔离。这些隔离,都是为了将生产系统和测试系统完全分开,避免它们相互影响。 很显然,三一致解决的是测试结果的准确性问题,而四隔离则保证了测试过程不会影响生产系统。

基于上面的理念,MegaEase 在 EaseMesh 中实现了 Shadow Service 功能。使用这一功能,用户可以非常容易地为系统中的所有服务创建一个副本,除了带有shadow标记之外,这些副本与原始服务完全相同,从而保证了业务一致和业务隔离。同时,Shadow Service 还会自动创建一条 Canary 规则,将带有 X-Mesh-Shadow: shadow 头部的请求作为测试请求转发到服务副本,将其它请求发送给原始服务,以实现流量隔离。

在数据方面,Shadow Service 可以根据配置替换掉包括 MySQL、Kafka、Redis 等在内的多种中间件的连接信息,并借此改变数据请求的发送目标,这保证了数据隔离。而用户则可以直接将生产数据复制一份作为测试数据来保证数据一致。

资源一致和资源隔离是指测试系统要使用与生产系统规格相同的资源,但不应该共享同一套资源。这主要是一个硬件问题,但Kubernetes 已经在软件层面给出了非常好的答案,而EaseMesh是建立在Kubernetes之上的,所以,通过将服务副本部署到新的POD中,资源一致和资源隔离就都得到了保证。

4.2 Shadow Service 的使用方法

下面我们以一个简化后的订单支付的场景,介绍一下 Shadow Service 的具体使用方法。这个场景涉及订单(Order)和支付(Payment)两个服务,订单服务会调用支付服务,支付服务最终会调用第三方服务(图中未画出)来完成支付,同时,订单服务还会访问MySQL数据库。 整个系统,通过 EaseMesh 部署在 Kubernetes 中,部署过程中, EaseMesh 会向应用的 POD 中注入的 SideCar (基于Easegress) 和 JavaAgent(基于EaseAgent),从而劫持应用发出的 HTTP 请求和数据请求,实现前面提到的“三一致”和“四隔离”。系统的总体架构如下图所示。
在这里插入图片描述

要对其进行测试,我们需要首先创建数据库的副本。这一步,可以通过数据库的备份恢复功能来完成,因为数据副本和原始数据位于同一个安全域,所以不必对数据进行脱敏处理。

在这里插入图片描述

然后,使用下面的 emct l命令订单服务的 shadow 副本和灰度规则(自动创建,所以没有包含在下面的配置中)。注意,在创建服务的副本时,我们将其使用的数据库指向了刚刚创建的数据库副本。

echo ’
kind: ShadowService
apiVersion: mesh.megaease.com/v1alpla1
metadata:
name: shadow-order-service
spec:
serviceName: order-service
namespace: megaease-mall
mysql:
uris: “jdbc:mysql://172.20.2.216:3306/shadow_order_db…”
userName: “megaease”
password: “megaease”
’ | emctl apply
在这里插入图片描述

最后,因为不想在测试的时候实际支付费用,我们要用下面的命令 Mock 支付服务。注意,调用第三方支付服务时通常会涉及多个非常复杂的安全验证步骤,这导致这个服务难以被直接 Mock 。所以,我们把第三方服务包装成了系统内部的服务,并借此简化了调用接口,下面 Mock 的实际上是这个包装后的服务。

echo ’
kind: Mock
apiVersion: mesh.megaease.com/v1alpha1
metadata:
name: payment-service
registerTenant: megaease-mall
spec:
enabled: false
rules:
- match:
pathPrefix: /
headers:
X-Mesh-Shadow:
exact: shadow
code: 200
headers:
Content-Type: application/json
body: ‘{“result”:“succeeded”}’
’ | emctl apply
这样就完成了整个测试系统的创建,我们可以向其发送带有 X-Mesh-Shadow: shadow 头部的请求来进行压力测试.。最终的系统架构是下面的样子。

在这里插入图片描述

4.3 Shadow Service 的优势

相对于传统的测试方法,使用 Shadow Service 进行压力测试在以下五个方面具有明显的优势:

0代码修改:全部通过配置完整,不需要修改任何代码,没有改出 Bug 的风险。
低成本:在使用云服务器的情况下,测试用的硬件资源随用随申请,用完就释放,仅需要为实际使用时段付费。
业务逻辑与生产环境基本一致:除少数被 Mock 的服务外,测试系统与生产系统完全一致,最大程度避免了业务逻辑的差异导致的误差。
可以使用生产数据进行测试:测试系统和生产系统的数据完全一致,保证了测试结果的准确性。
安全:虽然测试时使用的是生产数据,但测试系统和生产系统处于同一个安全域,所以没有增加数据泄露风险。
最后,欢迎大家下载安装我们的EaseMesh产品并使用Shadow Service 功能。

标签:模块,系统,生产线,测试,链路,Shadow,测试环境,隔离
From: https://blog.csdn.net/2301_79159642/article/details/143591896

相关文章

  • 如何评估焊机测试负载均衡性能
    评估焊机测试负载均衡性能的方法有很多,以下是一些建议:确定测试目标:首先,需要明确评估焊机测试负载均衡性能的目标。这可能包括提高生产效率、降低能耗、减少设备故障率等。明确目标有助于选择合适的评估方法和指标。选择合适的测试方法:根据测试目标和焊机的实际情况,选择合适的测......
  • APP压力测试3--Monkey Script命令
    MonkeyScript执行Monkey的脚本命令:adbshellmonkey-f<编写的脚本文件><执行次数>1、DispatchTrackball轨迹球事件轨迹球事件DispatchTrackball(longdowntime(按键最初被按下的时间),longeventide(事件发生的时间),intaction(具体操作了按下还是弹起),floatx(x的坐标点),flo......
  • 测试用例设计
    1.概念(什么是测试用例?)测试用例(TestCase)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素2.常见的测试用例设计方法等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法。1)等价类划分法等价类划分,就是将......
  • 【Spring Boot安全】Spring Boot 测试技巧
    原创1ang小羊安全屋一、SpringBoot介绍SpringBoot是一个开源的Java框架,旨在简化Spring应用的创建和部署过程。它是Spring平台和第三方库生态的一部分,由Pivotal团队开发。SpringBoot旨在让开发者能够更快速地启动和运行新的Spring应用程序,通过提供默认的配置帮助快速启......
  • 一篇文章带你了解如何测试消息队列
    是什么探讨消息队列的测试,那首先就要了解消息队列是什么。消息队列是一种应用程序之间传递消息的异步通信机制。这里传递的消息指的是需要传输的数据,可以是一些文本、字符串或对象等信息。简述一下消息队列工作模式:消息的生产者将数据存放到消息队列中,消费者进行接收处......
  • C代码单元测试框架
    如何在Windows本地集成unity和CMocka单元测试框架? 一、Cmocka源码下载编译官方网站 https://cmocka.org/ 下载源码。CMocka使用CMake来管理构建过程,它能自动生成适用于MinGW的构建文件(MinGWMakefiles)。如果你想要在Windows上使用MinGW编译CMocka则......
  • 分布式事物传递 NetMQ测试
    usingNetMQ;usingNetMQ.Sockets;usingSystem;usingSystem.Threading;namespace消息传递库_NetMQ服务端{internalclassProgram{publicstaticvoidMain(){using(varpublisher=newPublisherSocket()){......
  • 符合ISO26262的零部件级的软件测试解决方案:目前功能安全零部件测试的困难|软件单元、
    引言在功能安全的开发、测试过程中概念阶段的活动一般都是由主机厂负责,而从系统开发到单元实现则是由供应商负责,对于供应商所做的一系列测试通常称为零部件级测试。根据ISO26262功能安全标准的划分,功能安全在零部件阶段的测试包括:软件单元测试、软件集成测试、硬件集成测......
  • 福禄克DTX,DSX系列内置标准以及生成的测试报告如何解读?
    今日,接到一些朋友的询问?虽然使用了很长一段时间的FLUKEDSX-5000或者DSX-8000,但是对于测试标准和测试生成的报告一知半解,借此咱们一块屡屡清楚。1,经常有的朋友拿到设备后,第一时间就问,咱们福禄克内置的标准的多少?我线的参数(被测的铜缆)达到多少db,才能算过了测试?这些通过一个表......
  • Linux命令行压力测试工具:基准测试与性能优化
    文章目录Linux命令行压力测试工具:基准测试与性能优化Linux安装模拟CPU压力基本用法:高负载模拟:常见选项解析:模拟CPU满负荷模拟I/O瓶颈随机读测试:顺序写测试:初始化与清理操作:模拟大流量网络压力客户端测试命令:服务端命令:模拟端口禁用与防火墙配置查看当前规则:禁用出口端......