前言
上一篇聊到了專案申報和技術調研評估的話題，每個公司採用的技術棧、技術同學的偏好以及具體的業務特性都不一樣，所以最終落地階段的技術方案也會有所不同。
這篇文章，來聊聊業內常見的一些資料隔離和標記透傳的技術方案以及測試如何接入驗證。
常見的技術方案
全鏈路壓測要落地，最大的挑戰是資料安全隔離，業內對於資料隔離，目前已知的技術方案有如下幾種：
底層框架
底層框架改造是目前業內較為常用的一種技術手段，它通過提供一個基礎的服務或者框架，讓業務應用和中介軟體接入即可。
在壓測時候，在請求頭帶入特殊的壓測標記，即可區分正常的業務流量和壓測流量來進行透傳，涉及到的中介軟體和資料庫，也會通過路由的方式透傳下去。
這樣做的優點在於：業務幾乎無需改造，侵入性低，即插即用的方式也更為靈活。
位元組碼增強
位元組碼增強是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擋板過濾；
- 資料落庫或者讀庫的路由邏輯是否正確；
- 接入前後對業務應用以及中介軟體的效能損耗是否在可接受範圍內；