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