上一篇聊到了项目申报和技术调研评估的话题,每个公司采用的技术栈、技术同学的偏好以及具体的业务特性都不一样,所以最终落地阶段的技术方案也会有所不同。这篇文章,来聊聊业内常见的一些数据隔离和标记透传的技术方案以及测试如何接入验证。
全链路压测要落地,最大的挑战是数据安全隔离,业内对于数据隔离,目前已知的技术方案有如下几种:
底层框架改造是目前业内较为常用的一种技术手段,它通过提供一个基础的服务或者框架,让业务应用和中间件接入即可。在压测时候,在请求头带入特殊的压测标记,即可区分正常的业务流量和压测流量来进行透传,涉及到的中间件和数据库,也会通过路由的方式透传下去。这样做的优点在于:业务几乎无需改造,侵入性低,即插即用的方式也更为灵活。
字节码增强是Java的一种特性,JVM针对各种操作系统、平台都进行了定制。无论在什么平台,都可以编译生成固定格式字节码(.class文件)供JVM使用。之所以被称之为字节码,是因为字节码文件由十六进制值组成,而JVM以两个十六进制值为一组,即以字节为单位进行读取。在Java中一般是用javac命令编译源代码为字节码文件,一个.java文件从编译到运行如下图所示:
字节码增强技术是一类对现有字节码进行修改或者动态生成全新字节码文件的技术,它可以在运行时对JVM中的类进行修改并重载,示意图如下:
Java的字节码技术可以应用的场景很多,比如:
而在全链路压测的数据隔离方面,可以通过提供一个探针的方式,让业务应用接入即可。
改造业务代码,顾名思义,就是通过修改所有涉及到的业务应用代码,让每个应用可以统一识别到压测的标记流量,通过这种手段来实现数据安全隔离。但这样做有很多不足,比如:
数据安全隔离的技术方案中,除了应用级别的识别透传,还有中间件和缓存以及数据库的识别和透传,业务常见的技术手段主要是如下几种:
组件名称 | 改造方案 |
---|---|
分布式锁 | 影子key,前缀perfshadow_ |
Redis | 影子key,用前缀区分如perfshadow_ |
Elasticsearch | 影子索引,前缀perfshadow_ |
Hbase | 影子namespace,前缀perfshadow_ |
Mongodb | 影子collection,前缀perfshadow_ |
Mysql | 影子表、影子表等方式都可,下游路由会进行相应路由 |
Kafka | 不分topic,下游路由会进行相应路由(影子topic/影子group) |
Rocketmq | 不分topic,下游路由会进行相应路由(影子topic/影子group) |
一般来说,技术方面的改造都是由基础架构团队来进行的,但改造完成后,最终还是要落地到业务应用上。如何在业务团队落地,是个很大的挑战。我个人的实践经验,主要有如下几点供参考:
推动全链路压测在业务团队落地,不能一味大而全,而应该先挑选非核心的业务进行接入。接入的风险和接入成本是一定要考虑的。风险主要在于出问题后的修复效率以及对业务的影响是否足够低,技术的改造往往会伴随着大量的变更,降低变更带来的线上问题风险,对一个团队或企业来说,永远是最重要的。
如何理解验证范围?技术改造接入后,为了避免大量的资源人力耗费在验证上,一定要在接入时候考虑验证的方式和手段。比如:
完成了上诉几个步骤,在测试环境验证阶段,主要关注如下几点: