羅輯思惟在全鏈路壓測方面的實踐和工做筆記

業務的知名度越高，其背後技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤爲是當服務的是對知識獲取體驗要求頗高的用戶羣體。

提供知識服務的羅輯思惟主張「省時間的獲取知識」，那麼其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思惟技術團隊在全鏈路壓測上的構建過程，爲您一探究竟。

全鏈路壓測知多少
保障服務的可用性和穩定性是技術團隊面臨的首要任務，也是技術難題之一。例如，羅輯思惟提供的是知識服務，服務的是在高鐵、地鐵和公交車等場所利用碎片時間進行學習，在凌晨、深夜都有可能打開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，全鏈路壓測的自動化程度得以進一步提升，加速了構建進程、下降了人力投入。咱們很是關注技術團隊的效率和專一度，不只是全鏈路壓測體系的構建，還包括其餘不少業務層面的系統建設，咱們都藉助了合做夥伴的技術力量，在可控時間內支撐起業務的快速發展。

當業務跑的快的時候，技術建設的路徑和方式，是團隊的基礎調性決定的。