首页 > 其他分享 >全链路压测(3):技术改造和测试验证

全链路压测(3):技术改造和测试验证

时间:2023-03-19 19:56:16浏览次数:46  
标签:字节 验证 压测 业务 接入 链路 技术改造

转载:https://www.cnblogs.com/imyalost/p/15733148.html

上一篇聊到了项目申报和技术调研评估的话题,每个公司采用的技术栈、技术同学的偏好以及具体的业务特性都不一样,所以最终落地阶段的技术方案也会有所不同。

这篇文章,来聊聊业内常见的一些数据隔离和标记透传的技术方案以及测试如何接入验证。

 

常见的技术方案

全链路压测要落地,最大的挑战是数据安全隔离,业内对于数据隔离,目前已知的技术方案有如下几种:

底层框架

底层框架改造是目前业内较为常用的一种技术手段,它通过提供一个基础的服务或者框架,让业务应用和中间件接入即可。

在压测时候,在请求头带入特殊的压测标记,即可区分正常的业务流量和压测流量来进行透传,涉及到的中间件和数据库,也会通过路由的方式透传下去。

这样做的优点在于:业务几乎无需改造,侵入性低,即插即用的方式也更为灵活。

字节码增强

字节码增强是Java的一种特性,JVM针对各种操作系统、平台都进行了定制。

无论在什么平台,都可以编译生成固定格式字节码(.class文件)供JVM使用。之所以被称之为字节码,是因为字节码文件由十六进制值组成,而JVM以两个十六进制值为一组,即以字节为单位进行读取。

在Java中一般是用javac命令编译源代码为字节码文件,一个.java文件从编译到运行如下图所示:

字节码增强技术是一类对现有字节码进行修改或者动态生成全新字节码文件的技术,它可以在运行时对JVM中的类进行修改并重载,示意图如下:

Java的字节码技术可以应用的场景很多,比如:

  1. Mock:测试时候对某些服务做Mock;
  2. 热部署:不部署服务而对线上服务做修改,打点、增加日志等操作;
  3. 诊断工具:比如arthas就是利用Instrument,无侵入跟踪正在运行的JVM,监控到类和方法级别的状态信息;

而在全链路压测的数据隔离方面,可以通过提供一个探针的方式,让业务应用接入即可。

改造业务代码

改造业务代码,顾名思义,就是通过修改所有涉及到的业务应用代码,让每个应用可以统一识别到压测的标记流量,通过这种手段来实现数据安全隔离。但这样做有很多不足,比如:

  1. 业务改造成本太大,且风险较高;
  2. 工作量较多,和业务的快速迭代有冲突;

中间件和数据库改造

数据安全隔离的技术方案中,除了应用级别的识别透传,还有中间件和缓存以及数据库的识别和透传,业务常见的技术手段主要是如下几种:

组件名称

改造方案

分布式锁

影子key,前缀perfshadow_

Redis

影子key,用前缀区分如perfshadow_

Elasticsearch

影子索引,前缀perfshadow_

Hbase

影子namespace,前缀perfshadow_

Mongodb

影子collection,前缀perfshadow_

Mysql

影子表、影子表等方式都可,下游路由会进行相应路由

Kafka

不分topic,下游路由会进行相应路由(影子topic/影子group)

Rocketmq

不分topic,下游路由会进行相应路由(影子topic/影子group)

 

测试验证四部曲

推动:让业务接入

一般来说,技术方面的改造都是由基础架构团队来进行的,但改造完成后,最终还是要落地到业务应用上。如何在业务团队落地,是个很大的挑战。我个人的实践经验,主要有如下几点供参考:

  1. 找到业务团队的痛点;
  2. 从利益诉求出发,找到合作的共同点;
  3. 尽可能降低接入成本和验证过程,而不是秀技术;

评估:接入风险和成本

推动全链路压测在业务团队落地,不能一味大而全,而应该先挑选非核心的业务进行接入,接入的风险和接入成本是一定要考虑的。

风险主要在于出问题后的修复效率以及对业务的影响是否足够低,技术的改造往往会伴随着大量的变更,降低变更带来的线上问题风险,对一个团队或企业来说,永远是最重要的。

确认:验证范围很重要

如何理解验证范围?技术改造接入后,为了避免大量的资源人力耗费在验证上,一定要在接入时候考虑验证的方式和手段。比如:

  1. 能否快速接入;
  2. 采用自动化的方式来快速验证一些接口链路是否正常;
  1. 接入的链路涉及到的外部调用或者下游调用,是否有mock手段;
  2. 梳理的业务场景和测试场景是否都匹配了接入的业务范围等等;

验证:功能正确性和性能损耗

完成了上诉几个步骤,在测试环境验证阶段,主要关注如下几点:

  1. 压测标记是否完整的透传到了数据库表;
  2. 下游或外部调用是否都被mock挡板过滤;
  3. 数据落库或者读库的路由逻辑是否正确;
  4. 接入前后对业务应用以及中间件的性能损耗是否在可接受范围内;

 

建了一个全链路压测沟通交流群,目前群人数已超过100,想加群的同学请公众号回复关键字:全链路压测。

添加我好友,我邀请进群,加群请备注说明来意。——公众号二维码在我博客主页右上角。

 

标签:字节,验证,压测,业务,接入,链路,技术改造
From: https://www.cnblogs.com/ceshi2016/p/17234037.html

相关文章

  • 换个角度,聊聊全链路压测
    转载:https://www.cnblogs.com/imyalost/p/14244184.html前言之前自己也写过好几篇关于全链路压测的文章或者博客,最近看了infoQ上infoQ-数列科技杨德华的专栏,复盘了下自己......
  • 全链路压测落地和演进之路
    转载:https://www.cnblogs.com/imyalost/p/14204484.html前言笔者所在的公司是一家快速发展的互联网电商公司,在保证业务快速稳定发展的同时,对于系统稳定性、可用性和扩展......
  • <转>二十问全链路压测干货汇总(上)
    本文转载自:微信公众号-数列科技《二十问全链路压测干货汇总(上)》 最近几年全链路压测无疑成为了一个热门话题,在各个技术峰会上都可以看到它的身影。一些大型的互联网......
  • 计算机网络与通信之数据链路控制
    今天的内容主要讲的是如何保证广域网中计算机的通信的可靠性:数据链路层概述点对点协议:PPP点对多点协议:CSMA/CD差错控制技术1.数据链路层概述链路层中的信道数据链路层使......
  • 全链路压测探索实践之路
    转载:https://www.cnblogs.com/imyalost/p/12524078.html背景去年双十一,为了应对零点的峰值流量冲击,我们在八月下旬启动了全链路压测第一次实践。由于从零开始,因此单独搭......
  • go微服务开发:go-zero链路追踪
    在之前的go-zero教程里,我们介绍了使用演示工程开发user模块和search模块,为了更直观的呈现请求的生命周期,我们引入:链路追踪,这里我们使用的链路追踪工具是jaeger,如果你想了解......
  • 压测工具Jmeter介绍及使用
    一、压测工具选型1.1、前言压力测试是每一个Web应用程序上线之前都需要做的一个测试,他可以帮助我们发现系统中的瓶颈问题,减少发布到生产环境后出问题的几率;预估系统的承载......
  • 再谈全链路压测
    转载:https://www.cnblogs.com/imyalost/p/10525766.html之前的博客,有对业内比较出名的几家互联网大厂的全链路压测方案进行过整理和总结,传送门:聊聊全链路压测。时隔一年......
  • 数据链路层
    3.1数据链路层概述链路:就是从一个结点到相邻结点的一段物理线路,而中间没有任何其他的交换结点。数据链路:是指把实现通信协议的硬件和软件加到链路上,就构成了数据链路......
  • 基于OFDM+STBC通信链路的误码率matlab仿真
    1.算法描述      空时分组码(STBC)与正交频分复用(OFDM)相结合的STBC-OFDM技术可以有效对抗多径效应和频率选择性衰落,在复杂通信环境中提高传输效率,降低误码率,并且编译......