前言
全鏈路壓測從零開始系列的第一篇文章介紹了全鏈路壓測的背景、定義、和傳統壓測的差異以及如何解決差異帶來的不穩定性，
落地要面臨的挑戰和完整的壓測實踐流程以及長期的能力建設演變，算是對全鏈路壓測有了一個比較系統和全面的介紹。
本篇是系列的第二篇，從這篇文章開始，我會基於自己的個人落地實踐經驗，給大家分享從零開始落地全鏈路壓測，要做哪些事情，以及這個過程中遇到的挑戰、踩過的坑以及該如何解決這些問題。
申報立項
一般來說，像生產全鏈路壓測這種複雜的需要多個技術團隊參與的複雜技術專案，在企業內部都會有一個專案申報和評估立項的過程。
專案申報
下面是一個專案申報的模板，大家可以參考下：
|
背景 |
為什麼要做這件事？（線上故障頻發，效能問題凸顯，雲資源成本太高） |
|
目的 |
為了解決什麼問題？（降低線上故障率和損失，降低硬體成本） |
|
方案 |
具體的解決方案是什麼？（生產環境全鏈路壓測） |
|
價值 |
做這件事帶來的價值是什麼？（提高使用者體驗，團隊練兵，保障業務價值的實現） |
|
資源 |
做這件事需要什麼資源？（研發、運維、DBA、測試等） |
|
時間 |
什麼時候開始，什麼時候上線？ |
評估立項
專案申報後，就是多方評估是否立項的環節，在這個環節，主要有如下幾件事：
- 目前存在的問題是否真的有這麼嚴重？
- 這些問題如果不解決是否會對業務造成影響？
- 做這件事，能否解決目前存在的問題？
- 做這件事，要投入的時間資源和對業務及團隊的價值，有多大？
- 這件事的優先順序有多高？
調研評估
在專案正式啟動前會有個調研環節。這裡的調研主要指的是基於自身當前所處階段及面臨的問題和實現生產全鏈路壓測之間的差異，以及如何解決差異的解決方案。
我個人總結下來，方案調研可以分為如下四個階段：
看：大廠都是怎麼做的？
全鏈路壓測是個技術複雜度比較高的跨團隊的技術專案，最初也是大廠的自留地。
在調研方案時候，有必要看看大廠都是如何做的，避免走太多彎路。前面提到了落地生產全鏈路壓測的幾個挑戰，下面我從這幾個挑戰點來做個梳理對比，幫大家快速的瞭解，大廠是如何做的。
|
挑戰點/大廠 |
阿里 |
美團 |
京東 |
滴滴 |
餓了麼 |
|
核心鏈路梳理 |
鷹眼系統 |
/ |
trace系統 |
/ |
|
|
資料安全隔離 |
流量/執行緒染色透傳 影子庫表 |
流量/執行緒染色透傳 影子庫表 |
流量/執行緒染色透傳 影子庫表+特殊標記 |
流量/執行緒染色透傳 影子庫表 |
流量/執行緒染色透傳 特殊標記(邏輯隔離) |
|
避免業務侵入 |
/ |
/ |
/ |
/ |
/ |
|
效能定位分析 |
/ |
/ |
/ |
/ |
/ |
|
服務安全保護 |
/ |
/ |
/ |
/ |
/ |
PS：針對上表的一些術語和“/”內容，這裡做個說明。
1、鏈路梳理
現在大多數企業都是採用微服務架構來設計系統，且業務場景多樣化，導致了系統架構異常複雜。
要覆蓋所有壓測範圍內的場景，就需要對涉及的所有應用及其呼叫關係進行梳理，手工來梳理，耗時且費力。
上面提到的幾家大廠的鷹眼啊Mtrace系統之類的，實際上都是基於分散式鏈路追蹤工具自研或二次開發的。
分散式鏈路追蹤工具，推薦開源的Jaeger，Jaeger是Uber推出的一款開源分散式追蹤系統，相容OpenTracing API。
分散式追蹤系統用於記錄請求範圍內的資訊，例如，一次遠端方法呼叫的執行過程和耗時。是排查系統問題和系統效能的利器，同時在鏈路梳理方面，能提高很多效率。
Jaeger的UI相較於Zipkin更加直觀和豐富，還有則是sdk比較豐富，go語言編寫，上傳採用的是udp傳輸，效率高速度快。
- Github地址：jaegertracing/jaeger
- 官方地址：Jaeger: 開源分散式端到端鏈路追蹤系統
2、資料隔離
- 流量染色：對於單服務來說，識別壓測流量只要在請求頭中加特殊壓測標識即可，HTTP和RPC服務是一樣的。
- 影子庫表：核心思想是使用線上同一個資料庫例項，包括共享資料庫例項中的記憶體資源，因為這樣才能更接近真實場景，只是在寫入資料時會寫在另一個“影子庫表”中。大概原理如下：
3、避免業務侵入
如果要通過修改業務應用或者採用資料庫表資料標記的方式來實現，勢必會對生產業務造成一定影響（要改造需要大量資源和時間）。
4、效能定位分析
全鏈路壓測的初衷還是為了發現並解決系統在峰值流量衝擊下的穩定性問題，因此效能定位分析的工具和完善的監控體系是必備的。一般在企業級技術監控領域，大體分為五種型別的監控：
- 基礎監控：包括頻寬、CDN、伺服器CPU、Memory、DiskIO、Network、Load5等指標；
- 指標監控：服務+介面維度，常見指標有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指標；
- 業務監控：拿電商來說，常見的有同比下單量、支付量、履約率、DAU、GMV、支付取消率等多重指標；
- 鏈路追蹤：如上面提到的Jaeger，是排查系統問題和系統效能的利器，同時在鏈路梳理方面，能提高很多效率；
- 輿情監控：主要指對外部的一些訊息的監控，比如某APP突然掛了、下不了單、有BUG可以刷單、客訴等一些列對企業或者品牌不利的因素，便於快速處理甚至公關；
5、服務安全保護
全鏈路壓測是在生產環境進行，壓測過程中，要考慮不對生產服務造成影響。因此需要一套完整的機制來保證，壓測在正常實施的同時，不對生產服務應用造成影響。一般都會通過熔斷和流量干預的機制來保證。
聽：SaaS服務商怎麼說？
國內全鏈路壓測的SaaS服務商，目前只有2家：數列科技和perfma。這裡以我比較熟悉的數列的SaaS產品舉例子，他們的全鏈路壓測產品主要優勢有如下幾點：
- 業務程式碼0侵入：在接入、採集和實現邏輯控制時，不需要修改任何業務程式碼；
- 鏈路自動梳理：僅需部署客戶端，無需對應用進行任何改造，就可以看到所有的服務呼叫關係，快速理解系統架構，並且通過鏈路架構圖可以詳細瞭解鏈路經過的應用、快取、中介軟體、DB，甚至第三方的API，每條鏈路的所有走向都一目瞭然；
- 資料安全隔離：在不汙染生產環境業務資料情況下進行全鏈路壓測，可以對寫型別介面進行直接的效能測試；
- 安全效能壓測：在生產環境進行效能壓測，對業務不會造成影響；
- 效能瓶頸快速定位：效能測試結果直接展現業務鏈路中效能瓶頸的節點；
而且今年他們已經將自己的全鏈路壓測產品開源了，並且支援多環境壓測，下面是他們的壓測多環境支援流程圖：
Github地址：開源全鏈路壓測平臺Takin
做：小範圍接入改造看效果
看完大廠是怎麼做的，以及SaaS服務商的產品，接下來就是要進行小範圍驗證了。一般進行小範圍接入改造，主要有如下幾點需要注意：
- 環境：如果有多套測試環境，可以選擇一套使用率較低的，否則建議臨時單獨搭建一套縮容的環境進行改造接入以及測試驗證；
- 業務：前期在調研驗證階段，建議選擇核心業務對應的應用服務來進行驗證，這樣更方面瞭解具體的效果是否達到預期（當然，在落地階段，剛開始建議選擇非核心業務）；
- 資源：這裡主要指人力資源，在專案立項後，建議有專門的人手資源來做這件事，否則專案很容易延期甚至無疾而終，在工作產出考核上，也不太好；
評：自研或SaaS產品的ROI
經過上述三個階段的調研和驗證，這裡需要對專案最終的整套解決方案做一個選型確定：是選擇自研還是SaaS服務商的全鏈路壓測產品。
從我個人的落地實踐經驗和了解來說，無論是自研，還是選擇SaaS服務商，需要考量的因素主要有如下幾點：
1.研發能力：一般來說，大廠或者中大型獨角獸公司，研發能力和資源相對會比較強，且出於造輪子和KPI的目的，選擇自研是相對來說比較好的方案。
當然對於中小型企業來說，研發能力和資源會弱一些，這種情況我建議還是選擇三方服務商的SaaS服務或者開源產品，價效比會更高一些；
2.業務接受能力：如果是自研，特別是選擇改造業務程式碼的方案時，一定要考慮到業務的接受能力。因為每次變更都會對線上帶來新的不穩定因素，且改造佔用的時間和資源會和業務需求迭代有所衝突。
如果是中介軟體層面改造或者採用的是無侵入的SaaS產品及開源產品，那麼相對來說這個矛盾就僅限於技術團隊內部；
3.專案預算投入：這裡的預算包括時間、風險、需要投入的人力物力等。
4.ROI(投入產出比)：實際上一個專案到了最後，要不要做的最終考慮因素就是投入產出比，以更低的風險和成本解決更大範圍的嚴重問題，永遠是優先順序最高的。
總結
本篇主要對全鏈路壓測的專案立項和調研環節要考量的點以及業內的一些方案&SaaS及開源產品做了介紹。
下一篇開始，會介紹落地實踐過程中具體要做的一些事情，包括工具選型、流量評估等，會結合具體的業務場景來為大家分享如何從零開始的落地全鏈路壓測。
建了一個全鏈路壓測學習溝通群，感興趣的可以掃碼進群一起交流學習。
