633      阿裏雲  技術社區[雲棲]

基於阿裏雲產品的全鏈路評估

什麼是全鏈路評估

在突發流量場景或者是新業務上線的場景，在未來某個特定的日期或者時間點將會有一輪大流量的用戶請求的時候，由於沒有真實生產環境運行時候的曆史信息做參考，就特別需要通過鏈路評估來對係統承載能力進行評估，從而保證係統的可靠穩定運行。

我們理解的鏈路評估，是從訪問入口開始，對整條鏈路的所有潛在的瓶頸點，進行全方位的測量，通過改造鏈路結構和容量配比，達到提升整體鏈路性能和可靠性的目的。

這裏麵的鏈路評估是相對單係統調優來說的，單係統調優重點關注的是在“機器操作”的微觀級別上做具體的軟件調整用以挖掘硬件的潛能，單係統調優關注的是單係統的瓶頸，解決的是一個點的問題。而我們說的鏈路評估，希望解決的是一條線上的問題。

整體鏈路評估的工作通過對活動目標進行需求分析、設計測試方案、設計指標監控方案，來完成對整個係統的鏈路測試和優化工作。這四個環節是一個不斷循環不斷迭代的過程，每當活動目標發生變化，業務場景發生變化，指標的測量結果發生變化，都需要給整個環節帶來再平衡。

    現在“發紅包”已經成為除夕之夜上一道必備菜品，每年的春節除夕，支付寶、qq、微博等都會聯合眾多行業，每個行業一個品牌，每個品牌一段固定的時間，進行紅包派發的活動。社交平台借著派發紅包提高了平台人氣，各大知名品牌，通過社交平台完成向自己的網站的引流，達到了推廣自己產品的目的。在整個活動中，社交平台的網民們拚的是手速，而各大知名品牌為了可靠的推廣自己的產品，則拚的是自家網站後台的技術架構。接下來，我們以一個真實案例，來分析一下，紅包大促這種的高並發場景的促銷活動如何進行鏈路評估。

紅包業務背景

首先介紹一下活動背景，金融行業一個互聯網公司，準備在春節除夕，利用與一個大型社交平台合作的機會，進行紅包派發活動，並向自己的app引流，吸引更多的用戶使用自家的app，在自家的app消費，購買產品。

活動期間，社交平台將會在固定的半個小時時段內，為該公司的app開啟專屬的紅包派送通道，用戶可在平台的首頁通過刷一刷參與活動。到時候，將有上億用戶，在這半個小時的時間內，通過在平台的首頁上不停的刷一刷，進入到我們客戶自己的紅包頁麵，參與到3000多萬個現金或者是代金券的秒殺活動中。

按照客戶的活動預期，現有250萬的用戶規模，希望借著這次紅包活動希望能夠吸引到500萬以上的新注冊用戶，也即是說，在搶完紅包之後，預計會有250多萬的既有用戶和500多萬的新注冊用戶，湧入客戶的手機app，進行紅包的查詢和消費操作。

紅包的業務規模如下圖所示。

在如此的業務規模之下，我們麵臨兩大挑戰：

1）         第一大挑戰，3000多萬紅包，半個小時，一億以上的用戶來搶，而且是整點準時搶，到時候瞬間峰值會非常有考驗；

2）         第二大挑戰是，該紅包是線上既可以消費，所以搶完紅包之後，會緊接著帶來線上用戶注冊和線上消費的峰值，搶紅包、登陸注冊、線上交易三種高並發寫入的場景的峰值重疊在了一起，這更是增加了大促活動線上流量的複雜度；

目標需求分析

了解完活動背景，我們首先進行目標需求分析，目標需求分析包括三部分工作：

首先對業務架構進行梳理，確認整套業務架構都由哪些場景組成，各場景的操作流程是什麼樣的，哪些是入口場景，哪些是後續的場景，場景之間的交易路徑和關聯關係是什麼？

其次，我們需要對活動目標進行分析，從而預估出每個場景具體的業務峰值。

第三，輸出整個係統業務模型，包括所有的場景，及對應的目標峰值。

業務架構梳理

通過和客戶的技術人員的調研，我們了解到整體業務架構，包括入口層、服務層、資源層和外部接口層。

入口層指的是發起終端或者調用渠道，該係統的用戶的來源是社交平台進行引流，通過手機瀏覽器在紅包係統上搶完紅包之後，再下載手機app進行注冊登陸並進行一係列消費活動。

    服務層提供了具體的應用模塊的實現，登陸app之後查詢紅包列表，然後會選擇查詢產品列表，查詢產品信息，充值，消費紅包等等。

    資源層則用到了阿裏雲的rds數據庫、redis數據庫、oss存儲等技術組件。

    外部接口包括支付接口、短信網關接口以及紅包接口。

將入口層、服務層、資源層、接口層串起來，得出了完整的業務處理流程，從而描繪出了整個業務架構。

業務架構梳理圖如下。

業務峰值預估方法

    梳理完業務係統，我們需要對整個業務係統的每個場景的峰值進行評估。

對於已上線係統

對於已經上線的係統，我們需要通過該係統的曆史大促峰值流量信息對係統的業務規模進行定量的分析，得出大促活動都有哪些場景構成，各場景的占比關係如何，活動目標與入口業務峰值的比例如何。

     對於入口業務，也就是說在業務流程上，調用完業務，才可以繼續後端的業務流程。需要根據曆史日誌信息計算出活動目標與業務峰值的比例關係，比如說將具體的活動目標，一般包括在線用戶數，新注冊用戶數，多長時間，達成多大的業務目標，轉換成具體的入口業務的峰值目標。

而對於非入口場景，在業務峰值的估算方式上，具體的計算方式可以是考察在曆史日誌信息中，各個場景占總交量的百分比，進而換算統計這些場景之間的比例關係是怎樣的。依據各場景之間的比例轉換關係，計算本次大促活動的各場景的峰值。

對於未上線係統

    對於沒有具體的曆史業務信息作為參考的係統，我們同樣需要麵對兩種情況，入口場景和非入口場景。

    對於入口場景，我們通用的方式是采用八二原則將活動目標轉換成業務峰值。八二原則的定義就是：20%的投入支撐80%的產出。在我們的峰值評估場景裏麵就是20%的時間支撐了80%的業務量。

     對於非入口業務來說，從業務入口進來的流量，在業務不頻繁變更的情況下，一定會以一定的比例落到後端的各業務邏輯上。以業務入口峰值作為基準，按照經驗值，給出業務入口與後續各業務的比例關係，推算出各業務行為的峰值流量。

業務峰值預估

結合本次具體搶紅包業務場景，我們來看下各場景的峰值應該怎麼樣來預估。在半個小時的活動時間內，我們有三個活動目標，3000萬的紅包個數、250萬的老用戶登陸、500萬的新增注冊用戶。對於本次需要評估的係統，搶紅包峰值、注冊登陸峰值活動都沒有曆史信息作為依據，所以采用八二原則，根據活動目標預估峰值tps。

非入口的後端的業務鏈路，參照曆史交易信息的比例進行流量轉換。考慮到紅包場景的特殊性，將某些業務之間的轉換率，根據經驗，提升到了1:1。

建立業務模型

完成了業務架構的分析，得出了活動涉及到的所有場景；完成了對與活動目標和曆史交易信息的分析，我們得出了各場景的業務峰值。於是我們就可以完成業務模型的建立。如表所示，我們看到一共有3個入口業務和10個非入口業務，根據八二原則對3個入口業務的峰值進行了預估，根據曆史交易的比例信息，對非入口業務進行了流量的轉換。最極端情況下，各種業務峰值重疊在一起，最高峰值tps會達到34.36萬

測試方案設計

完成了業務模型的建立，接下來我們就需要根據業務模型來完成測試方案的設計這部分我們要做兩件事情，第一，選取需要測試的業務場景，第二，選擇測試模型

選取業務場景

考慮到盡量模仿真實的用戶邏輯，盡量覆蓋到所有的業務峰值彼此疊加的場景，盡量能夠模擬用戶搶紅包的整條業務鏈路，我們選取了服務層所有業務場景。這張圖就是所有業務場景混合在一起的整條業務鏈路。

我們就會對這張圖的所有場景進行腳本模擬，但是我們怎麼樣對這些場景進行測試呢？

選擇測試模型

考慮到實際的業務場景目標需求，我們選取了以下四種測試模型。單場景基準測試模型、單場景負載測試模型、混合場景的負載測試模型、係統超時流控測試模型。

單場景基準測試模型，單支交易在係統無壓力情況下重複執行多次，檢查該交易是否存在性能缺陷，並獲取每個交易的基準性能，同時為容量測試提供參考數據。

單交易負載測試，。單交易負載測試模型通過逐步增加並發量進行負載測試，獲取單交易業務處理性能峰值，驗證單場景是否存在並發性問題。

混合負載測試是按照業務模型的約定在逐漸增加並發情況下進行測試。通過測試，獲取模擬實際生產環境中被測係統性能表現數據

    係統超時流控測試模型根據對係統中設定流控策略的場景的超時流控功能點有效性、可靠性、穩定性等驗證在模擬實際生產係統情況下，驗證多個超時流控機製並存情況下的正確性

指標監控

製定好了測試方案，接下來要完成指標監控工作，這樣才能在進行壓力測試是實施的時候，能夠對整條鏈路進行一個有數據評估。

數據鏈路梳理

各個業務場景的流量，最終都要量化到數據鏈路的容量上。

每條數據鏈路通常包括訪問渠道、阿裏雲的網絡產品、應用集群、阿裏雲的數據庫產品、第三方接口等，通常，依賴於鏈路跟蹤功能的係統能夠最方便的獲取到關聯鏈路的上下文依賴信息，這裏由於在這裏我們是通過調用地址信息、業務日誌的片段信息、連接配置信息來梳理整條數據調用鏈路，在這裏我們選擇一個鏈路較長的業務，搶紅包的業務為例：

    通過手機瀏覽器發起操作，數據流量首先經過阿裏雲的ddos防護產品，然後經過負載均衡設備，到達ecs上的應用集群，對redis和rds的數據寫入操作，通過統一的nat網關，完成對接口的調用。整條數據鏈路是一條同步鏈路，在對搶紅包業務進行鏈路的能力測量的時候，其中的任何一個環節出現性能問題，都會對整個請求的響應時間造成影響。

確認監控指標和監控方法

對於同一個阿裏雲產品組件，可能承擔了幾個場景的訪問流量，對於服務組件來說，我們需要重點關注哪些相應的度量指標呢？

對於數據鏈路上不同類型的技術組件，我們需要重點關注不同的幾類指標。

1）前端指標：這也是最能夠反映出用戶真實體驗的指標，我們使用阿裏雲的pts產品，在壓測的過程中能夠最直觀的關注到tps，響應時間，成功率等指標。如果前端指標符合預期，而後端的數據邏輯也確實跑通的話，我們認為我們的測試符合預期。

2）對於網絡接入，網絡調度類的技術組件，由於不涉及深入計算及io操作，主要是考量pps、cps、qps、帶寬一類的網絡技術指標；

比如：高防ip、waf防火牆、slb、nat網關等網絡產品都需要重點關注這類指標，在測試評估過程中，在前端指標出現衰減的情況下，首先需要考慮到網絡指標是否存在瓶頸。由於業務訪問量和這些網絡技術指標是可以成正比關係的，如果一旦網絡成為第一瓶頸點，我們可以通過網絡資源的擴展，有效提高業務支撐能力。

3)   對於部署了應用中間件的ecs集群，我們關注三方麵指標，操作係統指標、應用中間件指標和業務指標。應用集群的業務支撐能力取決於三個變量，如果存在後端依賴鏈路的性能問題，單純的對應用集群進行規格擴容，對應用進行線程、內存或者計算優化，都無法提升應用集群的整體並發能力。在這裏我們通過雲監控來關注操作係統的指標，通過開源工具監（Probe、Jconsole

）控應用中間件的指標，通過在日誌裏埋點，通過日誌服務收集日誌，並通過雲監控訂閱日誌的方式，來完成業務指標的監控。

（同時在應用集群上，接受請求的tps、處理時間、成功率，對後端調用的tps、響應時間，調用成功率，是反映數據鏈路健康程度的重要指標，隻有這些指標是健康的，能夠達到目標的，才能說明前端正常處理的tps請求是可信的。）

4)   數據庫類技術組件，涉及深入複雜的計算及io操作，不同的請求會有不同的cpu消耗或者io消耗，所以cpu使用率,qps、內存利用率等都可以通過雲監控來關注。另外通過dms數據管理工具，可以對sql會話進行實時的監控。

鏈路測試和優化

完成了測試方案的製訂，監控方案的製定，那麼最後一步，就可以通過模擬業務壓力，測量整條鏈路的支撐能力，得出鏈路的短板，通過容量配比和鏈路架構優化的手段來達支撐活動目的的最終目的。

根據測試方案的設計，我們的鏈路測試工作也包括如下四輪。

單場景基準測試、單場景的容量測試、混合場景的容量測試、最後一輪，製定超時流控的方案，並進行驗證。

單場景基準測試

單場景基準測試需要達成兩個目的。

1)   保證我們選取的13各場景，在係統沒有壓力的情況下，能夠把數據鏈路跑通，跑通的定義是什麼？就是模擬的腳本跑完之後，在壓測端能看到成功響應，在應用集群上能看到業務日誌，在數據庫上能看到寫入的信息。

2)我們要獲取到每個基準測試的響應時間，根據基準的性能，我們需要讓業務人員評估出一個在用戶看來能夠接受的響應體驗，

根據 並發用戶數=峰值tps*響應時間 這個公式，我們能夠了解到，在這個保守的響應體驗的基礎上，要想達到場景峰值，需要多少並發用戶數。為接下來的單場景的容量測試，提供並發用戶數的依據。

單場景容量測試

在鏈路測試的第二個階段，我們需要對每個場景進行並發數遞增的施壓過程，直到tps達到也場景峰值的需要。

由於這一步是容量測試，也就是說鏈路上並發能力的問題開始暴露出來。

數據緩存熱點問題

我們發現在搶紅包的場景和新用戶注冊的場景出現了大量的調用超時。

通過雲監控查看Ecs所組成的應用集群的資源占用率不高，redis的調用qps也沒有達到redis集群的極限，而從業務日誌監控上來看對於redis的調用卻出現了大量超時。

我們分析了一下具體的業務場景：

redis在這套架構中主要是充當緩存和計數器使用。

我們采用集群模式的redis提供服務，集群模式的redis，後端采用多分片的架構，擴展能力極強，而且可以破除單機redis單線程機製的性能瓶頸。

對於redis多分片的集群，key比較分散的場景可以對資源進行充分的利用。

而在發紅包和注冊的計數器應用上，兩個計數器應用，分別是兩個key，卻承擔了高並發場景所帶來的高並發操作，而一個key的所有qps操作卻分別隻能hash到一個分片上，於是這個計數器的qps和其他場景將這個分片上的能力迅速撐爆。

 我們對客戶提出了將熱點key進行隔離的建議，

1、注冊峰值和紅包峰值的熱點key使用獨立的redis實例；

2、在redis集群上對熱點key進行單獨的集群分片路由；

在優化之後的在此容量測試中，得到了預期的場景峰值。

高並發寫入延遲問題

架構設計：

應用集群采用了基於dubbo的服務化設計，交易中心和注冊登陸中心，分別負責產品下單信息的入庫和注冊信息的入庫。

現象：

我們在進行單場景容量測試的時候，發現搶注冊場景、產品下單信息入庫的兩個場景的響應時間都特別長。

而這個場景對應的集群的業務日誌監控發現，數據庫的寫入時間非常長。而且短信網關的也已經開始調用超時；

場景分析：

1、消費信息峰值、用戶注冊峰值、短信入庫峰值對於數據庫的寫入造成了較大的壓力；

2、短信驗證碼的峰值超過了短信通道的峰值能力

擴展方式

我們通過消息隊列來控製對後端數據庫和網關的調用頻率，盡量降低對後端的高並發壓力，同時也快速響應了前端用戶。

混合場景容量測試

對各個場景分別進行了容量測試，我們從各個單場景的角度進行了鏈路的優化，那麼這些單場景疊加在一起，能否分別達到各自場景的容量峰值呢？

網絡容量問題：

   我們按照實際的業務鏈路的先後順序，依次對各場景進行並發壓力增加的操作。當壓力增長到一定值之後，我們發現，前端指標中，響應時間和tps指標衰減變得非常嚴重，而數據鏈路中，應用集群，數據庫上麵的指標幾乎沒有增長。

場景分析：

我們的網絡接入場景非常簡單如圖所示，采用通過高防ip來進行ddos和cc攻擊的防護，通過slb來實現七層負載均衡的調度。

優化方式：

按照從前往後的順序排查瓶頸點，首先，我們發現高防ip的回源帶寬指標達到了瓶頸，首先對高防ip進行了多實例的擴展；

接下來，我們發現所購買的slb實例已經達到了規格上限，帶寬指標和pps指標已經達到了極限，然後我們又對slb實例進行了多實例的擴展；

由於紅包大促平台要求，各商家要統一使用https接入，對原來的http請求全部進行了https改造，我們也繼續通過slb實例的擴展來抵消掉改造成https所帶來的性能的衰減。

結果：網絡接入是所有業務場景的入口，在確保了網絡接入流量不成為瓶頸之後，後續的容量測試過程中，請求流量順利的從這裏進入應用係統、緩存、消息隊列、數據庫中。

超時流控測試

    由於第三方接口的容量不能隨著我們調用方的峰值要求，進行擴展，甚至還會在高並發場景下進行限流，所以在鏈路測試的最後一個階段，我們要設計好應對流控超時場景下的方案，並進行驗證。

架構設計：通nat網關可以充當一個高可用的SNAT設備，同時能夠使用一個固定的ip池，能夠滿足第三方接口對於白名單的需求，所以全站對外部接口的調用的需求，統一使用NAT網關產品。針對於每個虛擬機交換機下的ECS資源池，可以購買不同規格的的NAT網關的帶寬來滿足不同虛擬交換機下的應用集群的對外調用網絡容量需求。

場景描述：

降級流控策略的設計和驗證：

1）在對於短信網關的調用上，雖然我們采用了異步化的方式，大大降低了對於短信網關的並發調用量，但是短信網關調用對應的業務場景是注冊驗證碼，但注冊驗證碼是有時間限製，對於時間存在一定的敏感度。於是我們建議客戶對於異步化對外接口的調用，通過消息隊列的積壓度來進行降級流控策略，當隊列積壓度達到一定的數量，返回運營頁麵，減緩一下用戶的注冊頻率。

2）對於支付接口的調用的調用上，為了避免線程堆積對應用集群帶來的雪崩，我們采用的降級流控策略是降低超時時間和重試次數，為了在外部接口不可用的時候，快速通過友好的界麵將失敗返回。

鏈路測試實施：

在實際測試的時候，我們將所有場景保持在了一定的水位上，對支付和注冊的場景進行了壓力遞增的測試。通過限製支付場景對外調用的NAT網關的流量，我們成功驗證了在高壓力下支付接口調用超時的流控策略；通過暫停掉注冊場景的隊列消費進程，我們也成功驗證了在隊列積壓度達到一定比率的時候，注冊場景的降級策略。

最終架構設計

幾輪壓力測試下來，我們對每條鏈路上的架構進行了重新的評估。得出了最終的係統架構。

從應用分層的橫向的緯度，這各架構分了四層結構。第一層是網絡層，管理網絡流量的進出，第二層是應用層，第三層通過redis實現了數據緩存，通過阿裏雲消息中間件實現了高並發調用或者寫入的異步化處理，第四層是數據庫和文件存儲層。

    從係統縱向切分的角度，從網絡層上，CDN提供靜態服務，實現了對接入流量的負載均衡，NAT網關實現了對外部接口的統一調用。從應用垂直拆分的角度，通過使用dubbo框架，將不同的業務（或者數據庫）切分到不同的服務器（或者數據庫）之上，將動態靜態業務也進行了拆分，拆分到了不同的應用集群上，進行垂直擴展，將不同的功能和服務分割開來，便於不同模塊的分布式部署。在緩存層麵，不同的業務，也可以使用獨立的緩存實例，對熱點業務進行隔離，在數據存儲層麵，數據庫隨著業務的拆分，同樣進行縱向拆分。

在分布式擴展上麵：將分層和分割的應用和服務模塊或者是阿裏雲的技術組件進行分布式擴展，以便獲取更大的支撐能力。

總結

通過鏈路評估的工作，我們支持客戶做了兩個活動預案：一個是擴容預案，一個是降級預案和降級之後運營頁麵的準備；

1）在整點活動前2個小時完成了對活動係統的擴容準備工作，可以說把錢用到了刀刃上，這麼短的成本周期，隻有在公共雲上才能實現。

2）在活動當晚，所使用的第三方支付平台恰好與別的商家活動發生了重疊，導致支付接口出現了一些波動，我們提前準備的快速失敗的降級策略，避免了線程的堆積，而且返回給了用戶一個比訪問超時較好的體驗；

     活動期間參與紅包活動的用戶高達2億+，成功派發數億現金及卡券紅包

支撐了業內第一的日用戶注冊及充值交易轉化率。客戶非常滿意。

活動峰值持續了5分鍾，活動高峰整整持續了半個小時，在此期間，整個的係統的業務指標表現的非常穩定，外部接口的不可靠也通過降級預案進行了完美的控製。鏈路評估的工作成果也體現在了結果上。

最後更新：2017-06-12 17:31:37

  上一篇：  Wow！Wow！Wow！阿裏巴巴2018財年收入指引遠超市場預期

  下一篇：  網站建設如何將公司的利益最大化