業(yè)務的知名度越高，其背后技術團隊承受的壓力就越大。一旦出現(xiàn)技術問題往扔，就有可能被放大旋膳，尤其是當服務的是對知識獲取體驗要求頗高的用戶群體澎语。
提供知識服務的羅輯思維主張“省時間的獲取知識”，那么其技術團隊在技術實踐方面是如何踐行省時間的理念的呢验懊？本文將還原羅輯思維技術團隊在全鏈路壓測上的構(gòu)建過程擅羞，為您一探究竟。
全鏈路壓測知多少
保障服務的可用性和穩(wěn)定性是技術團隊面臨的首要任務义图，也是技術難題之一减俏。例如，羅輯思維提供的是知識服務碱工，服務的是在高鐵娃承、地鐵和公交車等場所利用碎片時間進行學習，在凌晨怕篷、深夜都有可能打開App历筝，以及分布在海外的全球用戶。這就需要得到App提供7*24的穩(wěn)定高性能的服務和體驗廊谓。
在實際生產(chǎn)環(huán)境中梳猪，用戶的訪問行為一旦發(fā)生，從CDN到接入層蒸痹、前端應用舔示、后端服務、緩存电抚、存儲惕稻、中間件整個鏈路都面臨著不確定的流量，無論是公有云蝙叛、專有云俺祠、混合云還是自建IDC，全局的瓶頸識別借帘、業(yè)務整體容量摸底和規(guī)劃都需要高仿真的全鏈路壓測來檢驗蜘渣。這里的不確定的流量指的是某個大促活動、常規(guī)高并發(fā)時間段以及其他規(guī)劃外的場景引起的不規(guī)則肺然、大小未知的流量蔫缸。
眾所周知，應用的服務狀態(tài)除了會受到自身穩(wěn)定性的影響际起，還會受到流量等環(huán)境因素的影響拾碌，并且影響面會繼續(xù)傳遞到上下游吐葱，哪怕一個環(huán)節(jié)出現(xiàn)一點誤差，誤差在上下游經(jīng)過幾層累積后會造成什么影響誰都無法確定校翔。
因此弟跑，在生產(chǎn)環(huán)境里建立起一套驗證機制，來驗證各個生產(chǎn)環(huán)節(jié)都是能經(jīng)受住各類流量的訪問防症，成為保障服務的可用性和穩(wěn)定性的重中之重孟辑。最佳的驗證方法就是讓事件提前發(fā)生，即讓真實的流量來訪問生產(chǎn)環(huán)境蔫敲，實現(xiàn)全方位的真實業(yè)務場景模擬饲嗽，確保各個環(huán)節(jié)的性能、容量和穩(wěn)定性均做到萬無一失奈嘿，這就是全鏈路壓測的誕生背景喝噪，也是將性能測試進行全方位的升級，使其具備“預見能力”指么。
業(yè)務壓測實施路徑
可見，全鏈路壓測做得好榴鼎，遇到真實環(huán)境的流量伯诬，系統(tǒng)僅僅只是再經(jīng)歷一次已經(jīng)被反復驗證過的場景，再考一遍做“做過的考題”巫财，不出問題在意料之中將成為可能盗似。
壓測的核心要素
實施完整的業(yè)務壓測，路徑很重要平项。
要達成精準衡量業(yè)務承接能力的目標赫舒，業(yè)務壓測就需要做到一樣的線上環(huán)境、一樣的用戶規(guī)模闽瓢、一樣的業(yè)務場景接癌、一樣的業(yè)務量級和一樣的流量來源，讓系統(tǒng)提前進行“模擬考”扣讼，從而達到精準衡量業(yè)務模型實際處理能力的目標缺猛，其核心要素是：壓測環(huán)境、壓測基礎數(shù)據(jù)椭符、壓測流量（模型荔燎、數(shù)據(jù)）、流量發(fā)起销钝、掌控和問題定位有咨。
壓測環(huán)境和壓測基礎數(shù)據(jù)
生產(chǎn)環(huán)境上基礎數(shù)據(jù)基本分為兩種方式，一種是數(shù)據(jù)庫層面不需要做改造蒸健，直接基于基礎表里的測試賬戶（相關的數(shù)據(jù)完整性也要具備）進行座享，壓測之后將相關的測試產(chǎn)生的流水數(shù)據(jù)清除（清除的方式可以固化SQL腳本或者落在系統(tǒng)上）婉商；另一種就是壓測流量單獨打標（如單獨定義的Header），然后業(yè)務處理過程中識別這個標并傳遞下去征讲，包括異步消息和中間件据某，最終落到數(shù)據(jù)庫的影子表或者影子庫中。這種方式詳見阿里的全鏈路壓測實踐诗箍，我們也是選用了這種方式癣籽。此外，生產(chǎn)環(huán)境的壓測盡量在業(yè)務低峰期進行從而避免影響生產(chǎn)的業(yè)務滤祖。
全鏈路壓測的構(gòu)建過程
目前筷狼，羅輯思維已經(jīng)提供了得到APP、少年得到匠童、和微信公眾號得到里的得到商城等多個流量入口埂材。
每一年，羅輯思維都會舉辦跨年演講汤求，第一年是在優(yōu)酷俏险，有200多萬人的在線觀看，第二年是在深圳衛(wèi)視合作直播扬绪，并在優(yōu)酷等視頻網(wǎng)站同步竖独，直播過程中當二維碼放出來的時候，我們就遇到了大量的用戶請求挤牛，在同一時刻莹痢。這就意味著，如果沒有對這個期間的流量做好準確的預估墓赴，評估好性能瓶頸竞膳，那么在直播過程中就有可能出現(xiàn)大面積服務中斷。
對整體系統(tǒng)進行全鏈路壓測诫硕，從而有效保障每個流量入口的服務穩(wěn)定性成為技術團隊的當務之急坦辟。因此，我們在2017年章办，計劃引入全鏈路壓測长窄。期間，也對系統(tǒng)做了服務化改造纲菌，對于服務化改造的內(nèi)容之前在媒體上傳播過挠日，這次我們主要是講下保障服務穩(wěn)定性的核心 - 全鏈路壓測。大致的構(gòu)建過程如下：
2017年10月
啟動全鏈路壓測項目翰舌，完成商城的首頁嚣潜、詳情、購物車椅贱、下單的改造方案設計懂算、落地只冻、基礎數(shù)據(jù)準備和接入，以及得到APP首頁和核心功能相關的所有讀接口接入计技，并在進行了得到APP的第一次讀接口的全鏈路壓測喜德。
2017年11月
商城核心業(yè)務和活動形態(tài)相對穩(wěn)定，進入全面的壓測&攻堅提升期垮媒，同時拉新舍悯、下單和支付改造開始，得到APP開始進入寫改造睡雇，活動形態(tài)初具雛形萌衬，讀寫覆蓋范圍已經(jīng)覆蓋首頁、聽書它抱、訂閱秕豫、已購、拉新观蓄、知識賬本混移，并啟動用戶中心側(cè)用戶部分的底層改造，包括短信等三方的業(yè)務擋板開發(fā)侮穿。
2017年12月
商城進行最后的支付改造補齊歌径，然后是全鏈路壓測&優(yōu)化的整體迭代；得到APP全鏈路壓測接入范圍繼續(xù)增加撮珠，覆蓋全部首頁范圍和下側(cè)5個tab，同時開始部分模塊組合壓測和性能調(diào)優(yōu)的迭代金矛；完成底層支付和用戶中心配合改造芯急，以及支付和短信所有外部調(diào)用的擋板改造；行了多輪次的全鏈路形態(tài)完整壓測驶俊，并從中發(fā)現(xiàn)發(fā)現(xiàn)娶耍，給予問題定位，提升體系穩(wěn)定性饼酿；梳理對焦了風險識別榕酒、預案和值班等等。
經(jīng)過3個多月的集中實施故俐，我們將全鏈路壓測接入鏈路174個想鹰，創(chuàng)建44個場景，壓測消耗VUM1.2億药版，發(fā)現(xiàn)各類問題200多個辑舷。
如果說2017年全鏈路壓測的設施在羅輯是從0到1，那么2018年就是從1到N了槽片。
從2018年開始何缓，全鏈路壓測進入比較成熟的階段肢础，我們的測試團隊基于PTS和之前的經(jīng)驗，迅速地將全鏈路壓測應用于日陈道活動和跨年活動中传轰，并應用于新推出的業(yè)務「少年得到」上。目前谷婆，全鏈路壓測已經(jīng)成為保障業(yè)務穩(wěn)定性的核心基礎設施之一慨蛙。
全鏈路壓測的構(gòu)建與其說是一個項目，不如說是一項工程波材。僅憑我們自己的技術積累和人員配置是無法完成的股淡，在此特別感謝阿里云PTS及其他技術團隊提供的支持，幫助我們將全鏈路壓測在羅輯思維進行落地廷区。下面我們將落地過程中積累的經(jīng)驗以工作筆記的方式分享給大家唯灵。
工作筆記
A. 流量模型的確定：
流量較大的時候可以通過日志和監(jiān)控快速確定。但是往往可能日常的峰值沒有那么高隙轻，但是要應對的一個活動卻有很大的流量埠帕，有個方法是可以基于業(yè)務峰值的一個時間段內(nèi)統(tǒng)計各接口的峰值，最后拼裝成壓測的流量模型玖绿。
B. 臟數(shù)據(jù)的問題：
無論是通過生產(chǎn)環(huán)境改造識別壓測流量的方式還是在生產(chǎn)環(huán)境使用測試帳號的方式敛瓷，都有可能出現(xiàn)產(chǎn)生臟數(shù)據(jù)的問題，最好的辦法是：
在仿真環(huán)境或者性能環(huán)境多校驗多測試：有個仿真環(huán)境非常重要斑匪，很多問題的跟進呐籽、復現(xiàn)和debug不需要再上生產(chǎn)環(huán)境，降低風險蚀瘸。
有多重機制保障：
比如對了壓測流量單獨打標還需要UID有較強的區(qū)分度狡蝶，關鍵數(shù)據(jù)及時做好備份等等。
C. 監(jiān)控：
由于是全鏈路壓測贮勃，目的就是全面的識別和發(fā)現(xiàn)問題贪惹，所以要求監(jiān)控的覆蓋度很高。從網(wǎng)絡接入到數(shù)據(jù)庫寂嘉，從網(wǎng)絡4層到7層和業(yè)務的奏瞬，隨著壓測的深入，你會發(fā)現(xiàn)監(jiān)控總是不夠用泉孩。
D. 壓測的擴展：
比如我們會用壓測進行一些技術選型的比對硼端，這個時候要確保是同樣的流量模型和量級，可以通過全鏈路壓測測試自動擴容或者是預案性質(zhì)的手工擴容的速度和穩(wěn)定性寓搬。在全鏈路壓測的后期显蝌，也要進行重要的比如限流能力的檢驗和各種故障影響的實際檢驗和預案的演練。
E. 網(wǎng)絡接入：
如果網(wǎng)絡接入的節(jié)點較多，可以分別做一些DIS再壓測曼尊，逐個確定能力和排除問題酬诀，然后整體enable之后再一起壓測確定整體的設置和搭配上是否有能力對不齊的情況。
比如骆撇，網(wǎng)絡上使用了CDN動態(tài)加速瞒御、WAF、高防神郊、SLB等等肴裙，如果整體壓測效果不理想的時候建議屏蔽掉一些環(huán)節(jié)進行壓測，收斂問題涌乳，常見的比如WAF和SLB之間的會話保持可能帶來負載不勻的問題蜻懦。當然這些產(chǎn)品本身的容量和規(guī)格也是需要壓測和驗證的，如SLB的CPS夕晓、QPS宛乃、帶寬、連接數(shù)都有可能成為瓶頸蒸辆，通過在PTS的壓測場景中集成相關SLB監(jiān)控可以方便地一站式查看征炼，結(jié)合壓測也可以更好的選擇成本最低的使用方式。
另外負載不勻除了前面說的網(wǎng)絡接入這塊的躬贡，內(nèi)部做硬負載的Nginx的負載也有可能出現(xiàn)不勻的現(xiàn)象谆奥，特別是在高并發(fā)流量下有可能出現(xiàn)，這也是全鏈路拂玻、高仿真壓測的價值酸些。
特別是一些重要活動的壓測，建議要做一下業(yè)務中會真實出現(xiàn)的流量脈沖的情況檐蚜。
阿里云PTS是具備這個能力的魄懂，可以在逐級遞增滿足容量的背景下再觀察下峰值脈沖的系統(tǒng)表現(xiàn)，比如驗證限流能力熬甚，以及看看峰值脈沖會不會被識別為DDOS逢渔。
F. 參數(shù)調(diào)優(yōu)：
壓測之后肯定會發(fā)現(xiàn)大量的參數(shù)設置不合理肋坚，我們的調(diào)優(yōu)主要涉及到了這些：內(nèi)核網(wǎng)絡參數(shù)調(diào)整（比如快速回收連接）乡括、Nginx的常見參數(shù)調(diào)優(yōu)、PHP-FPM的參數(shù)調(diào)整等等智厌，這些網(wǎng)上相關的資料非常多诲泌。
G. 緩存和數(shù)據(jù)庫：
重要業(yè)務是否有緩存；
Redis CPU過高可以重點看下是否有模糊匹配铣鹏、短連接的不合理使用敷扫、高時間復雜度的指令的使用、實時或準實時持久化操作等等。同時葵第，可以考慮升級Redis到集群版绘迁，另外對于熱點數(shù)據(jù)考慮Local Cache的優(yōu)化機制（活動形態(tài)由于K-V很少，適合考慮Local Cache）卒密；
重要數(shù)據(jù)庫隨著壓測的進行和問題的發(fā)現(xiàn)缀台，可能會有索引不全的情況；
H. Mock服務：
一般在短信下發(fā)哮奇、支付環(huán)節(jié)上會依賴第三方膛腐，壓測涉及到這里的時候一般需要做一些特殊處理，比如搭建單獨的Mock服務鼎俘，然后將壓測流量路由過來哲身。這個Mock服務涉及了第三方服務的模擬，所以需要盡量真實贸伐，比如模擬的延遲要接近真正的三方服務勘天。當然這個Mock服務很可能會出現(xiàn)瓶頸，要確保其容量和高并發(fā)下的接口延時的穩(wěn)定性棍丐，畢竟一些第三方支付和短信接口的容量误辑、限流和穩(wěn)定性都是比較好的。
I. 壓測時系統(tǒng)的CPU閾值和業(yè)務SLA
我們的經(jīng)驗是CPU的建議閾值在50到70%之間歌逢，主要是考慮到容器的環(huán)境的因素巾钉。然后由于是互聯(lián)網(wǎng)性質(zhì)的業(yè)務，所以響應時間也是將1秒作為上限秘案，同時壓測的時候也會進行同步的手工體感的實際測試檢查體驗砰苍。（詳細的指標的解讀和閾值可以點擊閱讀原文）
J. 其他
限流即使生效了，也需要在主要客戶端版本上的check是否限流之后的提示和體驗是否符合預期阱高，這個很重要赚导；
全鏈路壓測主要覆蓋核心的各種接口，除此以外的接口也要有一定的保護機制赤惊，比如有默認的限流閾值吼旧，確保不會出現(xiàn)非核心接口由于預期外流量或者評估不足的流量導致核心系統(tǒng)容量不足（如果是Java技術棧可以了解下開源的Sentinel或者阿里云上免費的限流工具 AHAS）
核心的應用在物理機層面要分開部署未舟；
省時間的技術理念
目前圈暗，全鏈路壓測已成為羅輯思維的核心技術設施之一，大幅提升了業(yè)務的穩(wěn)定性裕膀。借助阿里云PTS员串，全鏈路壓測的自動化程度得以進一步提高，加速了構(gòu)建進程昼扛、降低了人力投入寸齐。我們非常關注技術團隊的效率和專注度，不僅是全鏈路壓測體系的構(gòu)建，還包括其他很多業(yè)務層面的系統(tǒng)建設渺鹦，我們都借助了合作伙伴的技術力量扰法，在可控時間內(nèi)支撐起業(yè)務的快速發(fā)展。
當業(yè)務跑的快的時候毅厚，技術建設的路徑和方式迹恐，是團隊的基礎調(diào)性決定的。
