第一波在線教育的流量高峰是在1月底，這時，很多企業把緊急擴容作為應急措施，但是後來會發現擴容也沒用！這是為什麼呢？又該怎麼做呢？
上週五，聽雲聯合網宿科技進行了《聽你 聽我 在線賦能團——在線教育專場》的直播，分享了這個問題的解決方案。 很多小夥伴沒能按時進入到直播間，或者錯過直播。今天給大家整理了本場直播乾貨，值得收藏！ 以下是直播乾貨分享： 大家好，我是聽雲高級客戶成功經理王彬冰，今天想和大家分享一下《在線教育高可用架構建設重要環節》。 現在疫情已經成為一個全球性的問題，高流量高併發可能成為一種常態。這個時候，我們必須開始重新審視現在的基礎設施是否能支撐未來業務發展。 下面主要分享我在高可用架構建設過程中的一些實踐，主要分為以下四個部分：架構設計
容量規劃
一體化監控
常態化演練
01
架構設計實現架構的可視化 要對架構進行設計，第一步一定是要對架構做可視化。 一張好的架構圖，應該明確系統所包含的各個組件，以及各個組件之間的調用關係。這些組件的集合，就是我們系統處理的邊界，同時在一定程度上也表明了我們業務的邊界。 另外在故障發生的時候，我們開發人員可以根據架構圖去確定問題來源，極大地縮短我們的修復時間，這些都是架構可視化的優點。 有以下三種可視化方法：
手工繪製
埋點式繪製
自動化架構可視化
可視化的下一步，就是對我們的強弱依賴去進行梳理和應對。 梳理強弱關係，就是對拓撲圖分層，來看這個圖例。
第一行用顏色標記了應用性能的好壞和告警的標識。 第二行，從左到右依次是不同的層級。最左邊是一個業務系統，用蜂窩的形式表示，由一個服務組構成的。服務組下面是具體的應用，應用可能會調用組件，或者是被組件調用。網絡的數據、APP的數據以及頁面的數據等，都可以被繪製在這張圖中，同時用線條的粗細來表示吞吐率的高低。
當我們以這種層級的方式梳理後，展現在眼前的，不再是一張龐大的圖形調用網絡，而是3-5個業務系統。當我們發現其中一個業務系統出問題的時候，再去做下鑽，從而定位具體的問題，就比較高效。
02
容量規劃外網仿真壓測+全鏈路壓測 做完架構可視化之後，我們就需要對具體容量做規劃了，規劃主要通過壓測來制定。 常見壓測有兩種類型：
外網仿真壓測
全鏈路壓測
兩種壓測的類型雖然不一樣，但是流程其實是一樣的。 首先第一步就是準備架構的可視化，也就是上一章講的內容； 第二步是壓測環境的準備，我們需要去複用真實的線上環境，這樣測出來的問題才真實； 第三步是
數據的準備。我們把線上真實數據作為數據源，但是要經過採樣、過濾和脫敏，並且保持同量級作為壓測的數據。比如，在線教育行業，核心數據一般會有學生、教師、和課程。 準備數據之後，就可以進行壓測了。壓測完之後，要對瓶頸進行定位，對容量進行微調。之後，一般還會進行幾次壓測，進一步驗證容量是否可以滿足預期。 活動結束之後，還要對整個壓測進行分析和總結，對容量做閉環，這樣才是一次完整的容量規劃。 以上是針對直播形式的在線教育的壓測流程。其實針對非直播的在線教育，還會有一個小步驟，那就是在壓測之前，可以進行一次小規模的、全量的壓測，也稱為“預熱”。03
一體化監控實現端到端數據的“監、管、控” 在大流量的衝擊下，以往的小問題就會放大，監測重要性在這裡就不多說了。如果沒有好的監控手段，排查問題就比較麻煩。而在排查問題的時間裡，你的客戶很可能被其他人搶走了。 在這裡我列舉了幾個應用如果突然發生報警，可能出現的原因：
- 程序Bug：如代碼問題導致空指針、頻繁Fu‖GC等。
- 上游依賴出問題：上游某個接口出了問題導致本應用出現接口超時、調用失敗等。
- 單機故障：某個容器受宿主機應用導致Load、CPU突然升高，最終導致超時、線程池滿等情況發生。
- 中間件故障：常見的如 Cache、DB抖動導致一段時間內RT增長、超時增多。不過這裡需要注意的是，單機Load高同樣會引發單機讀寫 Cache、DB出現問題。
我們這裡講的一體化監控，包括業務監控、應用監控和系統監控。監控重要的不是“監”，而是“控”，嚴格來說是監、管、控三大部分。 下面是聽雲的一個應用性能的架構圖。
我們通過打探針、非嵌入的方式可以採集到用戶數據，但是這樣直接採集到的大量的數據是沒有意義的，數據只有在被分析後才有意義。那如何做到管理數據呢？方式就是告警➕大屏，兩者作用都是對數據聚焦，如圖所示。
告警平臺主要分為兩種：
自研告警平臺
第三方告警平臺
不管哪種方式的告警，告警閾值才是關鍵。如果設置過高，會有漏報的現象，但是如果設置過低，就會產生大量無效告警。 而且告警閾值應該是一個動態的，因為應用性能不是一成不變的。而AI告警可以解決這個問題，它可以基於數據的變化，自動計算閾值，能極大的提升準確率並減少工作量。藉助大屏，可以展示整體的業務數據和性能數據，幫助工作人員宏觀地掌握應用性能。 這裡再分享一個監控直播卡頓的方法，這個方法來自一個用戶，非常簡單粗暴，但是很有效。 在直播的時候，這個用戶會提取彈幕或者留言區裡面的關鍵字，比如說：“卡”、“卡了”、“看不見”、“聽不見”等，當這些關鍵詞到一定數量的時候，他就去調整直播的線路，結果很有效果，幾乎不需要外部的報警了。 但是很多人都知道，即使是用了智能告警，告警的數量還是會比較多，這時候就需要用到告警收斂。 告警收斂首先需要兩個能力，一個是數據採集能力，一個是告警收斂能力。如圖所示：
告警收斂聽起來很簡單，但是要達到高收斂比和準確性，還是很困難的，而且即使做了收斂，可能還是達不到理想的效果。比如一週有5000個告警，我們的收斂比為90%（已經很高了），那還剩下500個告警。 500個告警還是很多的。我們理想狀態為，5000個告警收斂為1-2個告警。那告警收斂就需要具備第三個能力：根因分析。根因分析可以幫助歸類剔除有關聯性的一系列告警。
“控”就是通過各種手段解決問題。
04
常態化演練傳統測試無法覆蓋客戶端負載均衡、微服務容錯保護、API服務網關、分佈式鏈路跟蹤等特性，同時也無法模擬例如網絡延遲、CPU滿載、請求異常、依賴故障、硬件故障等場景。 如果想要構建一個高可用性架構，僅僅用常規測試是不夠的。 而混沌工程以實驗的方式，儘早揭露系統的弱點。它更像是一種探索性的測試，試驗本身沒有明確的輸入和結果，而是通過一種混亂的方式對系統進行干預，去發現能力的邊界。 以上就是所有直播內容重點乾貨，經過以上四個步驟，相信我們的系統性能會得到很大提升。
下圖是聽雲智能業務感知平臺，一站式具備以上提到的架構設計、容量規劃、一體化監控能力，幫助提升用戶體驗。
更詳細版本的視頻和PPT可以通過識別下方二維碼免費獲取。
掃描觀看直播視頻回放
閱讀更多 聽雲 的文章
