業務的知名度越高，其背后技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤其是當服務的是對知識獲取體驗要求頗高的用戶群體。
提供知識服務的羅輯思維主張“省時間的獲取知識”，那么其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思維技術團隊在全鏈路壓測上的構建過程，為您一探究竟。
全鏈路壓測知多少
保障服務的可用性和穩定性是技術團隊面臨的首要任務，也是技術難題之一。例如，羅輯思維提供的是知識服務，服務的是在高鐵、地鐵和公交車等場所利用碎片時間進行學習，在凌晨、深夜都有可能打開App，以及分布在海外的全球用戶。這就需要得到App提供7*24的穩定高性能的服務和體驗。
在實際生產環境中，用戶的訪問行為一旦發生，從CDN到接入層、前端應用、后端服務、緩存、存儲、中間件整個鏈路都面臨著不確定的流量，無論是公有云、專有云、混合云還是自建IDC，全局的瓶頸識別、業務整體容量摸底和規劃都需要高仿真的全鏈路壓測來檢驗。這里的不確定的流量指的是某個大促活動、常規高并發時間段以及其他規劃外的場景引起的不規則、大小未知的流量。
眾所周知，應用的服務狀態除了會受到自身穩定性的影響，還會受到流量等環境因素的影響，并且影響面會繼續傳遞到上下游，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積后會造成什么影響誰都無法確定。
因此，在生產環境里建立起一套驗證機制，來驗證各個生產環節都是能經受住各類流量的訪問，成為保障服務的可用性和穩定性的重中之重。最佳的驗證方法就是讓事件提前發生，即讓真實的流量來訪問生產環境，實現全方位的真實業務場景模擬，確保各個環節的性能、容量和穩定性均做到萬無一失，這就是全鏈路壓測的誕生背景，也是將性能測試進行全方位的升級，使其具備“預見能力”。
業務壓測實施路徑
可見，全鏈路壓測做得好，遇到真實環境的流量，系統僅僅只是再經歷一次已經被反復驗證過的場景，再考一遍做“做過的考題”，不出問題在意料之中將成為可能。
壓測的核心要素
實施完整的業務壓測，路徑很重要。
要達成精準衡量業務承接能力的目標，業務壓測就需要做到一樣的線上環境、一樣的用戶規模、一樣的業務場景、一樣的業務量級和一樣的流量來源，讓系統提前進行“模擬考”，從而達到精準衡量業務模型實際處理能力的目標，其核心要素是：壓測環境、壓測基礎數據、壓測流量（模型、數據）、流量發起、掌控和問題定位。
壓測環境和壓測基礎數據
生產環境上基礎數據基本分為兩種方式，一種是數據庫層面不需要做改造，直接基于基礎表里的測試賬戶（相關的數據完整性也要具備）進行，壓測之后將相關的測試產生的流水數據清除（清除的方式可以固化SQL腳本或者落在系統上）；另一種就是壓測流量單獨打標（如單獨定義的Header），然后業務處理過程中識別這個標并傳遞下去，包括異步消息和中間件，最終落到數據庫的影子表或者影子庫中。這種方式詳見阿里的全鏈路壓測實踐，我們也是選用了這種方式。此外，生產環境的壓測盡量在業務低峰期進行從而避免影響生產的業務。
全鏈路壓測的構建過程
目前，羅輯思維已經提供了得到APP、少年得到、和微信公眾號得到里的得到商城等多個流量入口。
每一年，羅輯思維都會舉辦跨年演講，第一年是在優酷，有200多萬人的在線觀看，第二年是在深圳衛視合作直播，并在優酷等視頻網站同步，直播過程中當二維碼放出來的時候，我們就遇到了大量的用戶請求，在同一時刻。這就意味著，如果沒有對這個期間的流量做好準確的預估，評估好性能瓶頸，那么在直播過程中就有可能出現大面積服務中斷。
對整體系統進行全鏈路壓測，從而有效保障每個流量入口的服務穩定性成為技術團隊的當務之急。因此，我們在2017年，計劃引入全鏈路壓測。期間，也對系統做了服務化改造，對于服務化改造的內容之前在媒體上傳播過，這次我們主要是講下保障服務穩定性的核心 - 全鏈路壓測。大致的構建過程如下：
2017年10月
啟動全鏈路壓測項目，完成商城的首頁、詳情、購物車、下單的改造方案設計、落地、基礎數據準備和接入，以及得到APP首頁和核心功能相關的所有讀接口接入，并在進行了得到APP的第一次讀接口的全鏈路壓測。
2017年11月
商城核心業務和活動形態相對穩定，進入全面的壓測&攻堅提升期，同時拉新、下單和支付改造開始，得到APP開始進入寫改造，活動形態初具雛形，讀寫覆蓋范圍已經覆蓋首頁、聽書、訂閱、已購、拉新、知識賬本，并啟動用戶中心側用戶部分的底層改造，包括短信等三方的業務擋板開發。
2017年12月
商城進行最后的支付改造補齊，然后是全鏈路壓測&優化的整體迭代；得到APP全鏈路壓測接入范圍繼續增加，覆蓋全部首頁范圍和下側5個tab，同時開始部分模塊組合壓測和性能調優的迭代；完成底層支付和用戶中心配合改造，以及支付和短信所有外部調用的擋板改造；行了多輪次的全鏈路形態完整壓測，并從中發現發現，給予問題定位，提升體系穩定性；梳理對焦了風險識別、預案和值班等等。
經過3個多月的集中實施，我們將全鏈路壓測接入鏈路174個，創建44個場景，壓測消耗VUM1.2億，發現各類問題200多個。
如果說2017年全鏈路壓測的設施在羅輯是從0到1，那么2018年就是從1到N了。
從2018年開始，全鏈路壓測進入比較成熟的階段，我們的測試團隊基于PTS和之前的經驗，迅速地將全鏈路壓測應用于日常活動和跨年活動中，并應用于新推出的業務「少年得到」上。目前，全鏈路壓測已經成為保障業務穩定性的核心基礎設施之一。
全鏈路壓測的構建與其說是一個項目，不如說是一項工程。僅憑我們自己的技術積累和人員配置是無法完成的，在此特別感謝阿里云PTS及其他技術團隊提供的支持，幫助我們將全鏈路壓測在羅輯思維進行落地。下面我們將落地過程中積累的經驗以工作筆記的方式分享給大家。
工作筆記
A. 流量模型的確定：
流量較大的時候可以通過日志和監控快速確定。但是往往可能日常的峰值沒有那么高，但是要應對的一個活動卻有很大的流量，有個方法是可以基于業務峰值的一個時間段內統計各接口的峰值，最后拼裝成壓測的流量模型。
B. 臟數據的問題：
無論是通過生產環境改造識別壓測流量的方式還是在生產環境使用測試帳號的方式，都有可能出現產生臟數據的問題，最好的辦法是：
在仿真環境或者性能環境多校驗多測試：有個仿真環境非常重要，很多問題的跟進、復現和debug不需要再上生產環境，降低風險。
有多重機制保障：
比如對了壓測流量單獨打標還需要UID有較強的區分度，關鍵數據及時做好備份等等。
C. 監控：
由于是全鏈路壓測，目的就是全面的識別和發現問題，所以要求監控的覆蓋度很高。從網絡接入到數據庫，從網絡4層到7層和業務的，隨著壓測的深入，你會發現監控總是不夠用。
D. 壓測的擴展：
比如我們會用壓測進行一些技術選型的比對，這個時候要確保是同樣的流量模型和量級，可以通過全鏈路壓測測試自動擴容或者是預案性質的手工擴容的速度和穩定性。在全鏈路壓測的后期，也要進行重要的比如限流能力的檢驗和各種故障影響的實際檢驗和預案的演練。
E. 網絡接入：
如果網絡接入的節點較多，可以分別做一些DIS再壓測，逐個確定能力和排除問題，然后整體enable之后再一起壓測確定整體的設置和搭配上是否有能力對不齊的情況。
比如，網絡上使用了CDN動態加速、WAF、高防、SLB等等，如果整體壓測效果不理想的時候建議屏蔽掉一些環節進行壓測，收斂問題，常見的比如WAF和SLB之間的會話保持可能帶來負載不勻的問題。當然這些產品本身的容量和規格也是需要壓測和驗證的，如SLB的CPS、QPS、帶寬、連接數都有可能成為瓶頸，通過在PTS的壓測場景中集成相關SLB監控可以方便地一站式查看，結合壓測也可以更好的選擇成本最低的使用方式。
另外負載不勻除了前面說的網絡接入這塊的，內部做硬負載的Nginx的負載也有可能出現不勻的現象，特別是在高并發流量下有可能出現，這也是全鏈路、高仿真壓測的價值。
特別是一些重要活動的壓測，建議要做一下業務中會真實出現的流量脈沖的情況。
阿里云PTS是具備這個能力的，可以在逐級遞增滿足容量的背景下再觀察下峰值脈沖的系統表現，比如驗證限流能力，以及看看峰值脈沖會不會被識別為DDOS。
F. 參數調優：
壓測之后肯定會發現大量的參數設置不合理，我們的調優主要涉及到了這些：內核網絡參數調整（比如快速回收連接）、Nginx的常見參數調優、PHP-FPM的參數調整等等，這些網上相關的資料非常多。
G. 緩存和數據庫：
重要業務是否有緩存；
Redis CPU過高可以重點看下是否有模糊匹配、短連接的不合理使用、高時間復雜度的指令的使用、實時或準實時持久化操作等等。同時，可以考慮升級Redis到集群版，另外對于熱點數據考慮Local Cache的優化機制（活動形態由于K-V很少，適合考慮Local Cache）；
重要數據庫隨著壓測的進行和問題的發現，可能會有索引不全的情況；
H. Mock服務：
一般在短信下發、支付環節上會依賴第三方，壓測涉及到這里的時候一般需要做一些特殊處理，比如搭建單獨的Mock服務，然后將壓測流量路由過來。這個Mock服務涉及了第三方服務的模擬，所以需要盡量真實，比如模擬的延遲要接近真正的三方服務。當然這個Mock服務很可能會出現瓶頸，要確保其容量和高并發下的接口延時的穩定性，畢竟一些第三方支付和短信接口的容量、限流和穩定性都是比較好的。
I. 壓測時系統的CPU閾值和業務SLA
我們的經驗是CPU的建議閾值在50到70%之間，主要是考慮到容器的環境的因素。然后由于是互聯網性質的業務，所以響應時間也是將1秒作為上限，同時壓測的時候也會進行同步的手工體感的實際測試檢查體驗。（詳細的指標的解讀和閾值可以點擊閱讀原文）
J. 其他
限流即使生效了，也需要在主要客戶端版本上的check是否限流之后的提示和體驗是否符合預期，這個很重要；
全鏈路壓測主要覆蓋核心的各種接口，除此以外的接口也要有一定的保護機制，比如有默認的限流閾值，確保不會出現非核心接口由于預期外流量或者評估不足的流量導致核心系統容量不足（如果是Java技術棧可以了解下開源的Sentinel或者阿里云上免費的限流工具 AHAS）
核心的應用在物理機層面要分開部署；
省時間的技術理念
目前，全鏈路壓測已成為羅輯思維的核心技術設施之一，大幅提升了業務的穩定性。借助阿里云PTS，全鏈路壓測的自動化程度得以進一步提高，加速了構建進程、降低了人力投入。我們非常關注技術團隊的效率和專注度，不僅是全鏈路壓測體系的構建，還包括其他很多業務層面的系統建設，我們都借助了合作伙伴的技術力量，在可控時間內支撐起業務的快速發展。
當業務跑的快的時候，技術建設的路徑和方式，是團隊的基礎調性決定的。
