前言
上一篇聊到了項目申報和技術調研評估的話題，每個公司采用的技術棧、技術同學的偏好以及具體的業務特性都不一樣，所以最終落地階段的技術方案也會有所不同。
這篇文章，來聊聊業內常見的一些數據隔離和標記透傳的技術方案以及測試如何接入驗證。
常見的技術方案
全鏈路壓測要落地，最大的挑戰是數據安全隔離，業內對於數據隔離，目前已知的技術方案有如下幾種：
底層框架
底層框架改造是目前業內較為常用的一種技術手段，它通過提供一個基礎的服務或者框架，讓業務應用和中間件接入即可。
在壓測時候，在請求頭帶入特殊的壓測標記，即可區分正常的業務流量和壓測流量來進行透傳，涉及到的中間件和數據庫，也會通過路由的方式透傳下去。
這樣做的優點在於：業務幾乎無需改造，侵入性低，即插即用的方式也更為靈活。
字節碼增強
字節碼增強是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擋板過濾；
- 數據落庫或者讀庫的路由邏輯是否正確；
- 接入前后對業務應用以及中間件的性能損耗是否在可接受范圍內；
建了一個全鏈路壓測溝通交流群，目前群人數已超過100，想加群的同學請公眾號回復關鍵字：全鏈路壓測。
添加我好友，我邀請進群，加群請備注說明來意。——公眾號二維碼在我博客主頁右上角。