受疫情影響，全國各學(xué)校的開(kāi)學(xué)均被延期。為避免耽誤學(xué)生的課業(yè)，教育部推出了“停課不停學(xué)”政策，鼓勵師生積極開(kāi)展線(xiàn)上教學(xué)模式。
趕考狀元（上海億山睦教育科技有限公司）為此積極響應政府號召，向湖北全省一年級到高三的學(xué)子免費開(kāi)放教材的同步在線(xiàn)教學(xué)課程，后來(lái)進(jìn)一步擴大至全國范圍。這一公益活動(dòng)獲得了很大反響，網(wǎng)站用戶(hù)注冊量和瀏覽量超過(guò)平時(shí)數倍。
雖然活動(dòng)從策劃到上線(xiàn)總共只有4天時(shí)間，趕考網(wǎng)技術(shù)團隊通過(guò)科學(xué)決策，及時(shí)精密的實(shí)施，完成了業(yè)務(wù)代碼改造、架構評估、擴容升級、SQL優(yōu)化等工作，期間也和UCloud UDB團隊緊密合作，在其協(xié)助下實(shí)現了數據庫的架構改造和擴容，很好地承接了QPS暴漲20倍的訪(fǎng)問(wèn)壓力，圓滿(mǎn)完成技術(shù)保障任務(wù)。
下面分享一些我們在此過(guò)程中的細節和思考，供有快速擴容需要的企業(yè)參考。
公司自2005年成立一直專(zhuān)注于K12在線(xiàn)教育，此次疫情公益活動(dòng)構想階段，業(yè)務(wù)側運用此前超過(guò)十年的互聯(lián)網(wǎng)及線(xiàn)下教育經(jīng)驗，快速設計了有效可行的方案，在不少細節上下了功夫，例如加速審核通道，只需兩步即可學(xué)習的易用性，面向家長(cháng)推廣的二維碼等。
技術(shù)團隊的任務(wù)則是提前預判后臺流量的迅猛增長(cháng)，未雨綢繆設計行之有效的預案，查漏補缺，切實(shí)保障活動(dòng)順利流暢運行。為此我們細致梳理了現有架構的薄弱點(diǎn)，并相應制定了精準有效的擴容方案。
由于我們原先的擴容是穩定慢節奏的，這次預見(jiàn)到了大量訪(fǎng)問(wèn)需求，首要工作是分析現有架構的能力和不足。
此前業(yè)務(wù)的主應用架構為ULB負載+雙UHost單體架構+分布式緩存+單實(shí)例高可用UDB，用了大量UCloud的云組件。我們全面梳理了架構各層模塊，對每一層的能力做了評估。ULB有扛大流量的能力，主要關(guān)注后端。UHost上是應用服務(wù)，我們測算了一個(gè)部署于8核16GB UHost上的主站模塊能夠扛住多大并發(fā)請求、應用模塊垂直擴容和平行擴容兩個(gè)方案的優(yōu)劣對比，最終決定水平擴展?？紤]到外圍的單體服務(wù)接口受主應用流量的帶動(dòng)，也進(jìn)行了擴容承壓的調整。緩存的做法是加大分布式緩存、優(yōu)化訪(fǎng)問(wèn)緩存。壓力最大的是數據庫，可能帶來(lái)性能上的嚴重瓶頸。
不管是MySQL、PostgreSQL還是MongoDB，我們都采用了UCloud 的 UDB 托管服務(wù)，其中包括核心數據庫。相比自建數據庫，UDB提供的高健壯高可用以及免維護的服務(wù)，可以讓我們更安心專(zhuān)注于上層業(yè)務(wù)邏輯的構建上。且在數據的安全問(wèn)題上，UDB提供了完善的備份和恢復機制，避免數據意外丟失。
最初我們的業(yè)務(wù)核心數據庫選用了高可用UDB部署。在業(yè)務(wù)平穩期，從性?xún)r(jià)比角度考慮，最開(kāi)始UDB實(shí)例配置不高，預估QPS最大負載在3000以?xún)?。業(yè)務(wù)爆發(fā)前夜，首先對UDB實(shí)例做了垂直升級，大幅度提升了數據庫的內存和磁盤(pán)配置。這個(gè)操作很快，幾乎不影響業(yè)務(wù)訪(fǎng)問(wèn)（只在磁盤(pán)升級時(shí)有秒級訪(fǎng)問(wèn)中斷）， 實(shí)例的處理性能迅速得到提升。
但高速增長(cháng)的業(yè)務(wù)，給數據庫帶來(lái)的壓力預計很快便超過(guò)單個(gè)UDB實(shí)例所能承受的極限，因此數據庫從單機升級為集群勢在必行。
我們設計方案時(shí)，獲得了UDB團隊的協(xié)助。分析業(yè)務(wù)的SQL請求后，發(fā)現讀寫(xiě)比例在50 : 1左右，屬于典型的讀多寫(xiě)少業(yè)務(wù)，于是向我們推薦了一主多從 + 讀寫(xiě)分離Proxy 的數據庫集群架構。
在該架構下，主（高可用UDB）和從（單節點(diǎn)UDB）之間通過(guò)異步復制保持數據同步，業(yè)務(wù)數據庫IP改指向讀寫(xiě)分離Proxy的IP，由讀寫(xiě)分離Proxy識別業(yè)務(wù)SQL的讀寫(xiě)類(lèi)型，將寫(xiě)SQL、事務(wù)讀SQL轉發(fā)到主， 普通讀SQL按比例轉發(fā)到從，轉發(fā)比例控制臺可自由配置。同時(shí)，讀寫(xiě)分離Proxy幾乎100%兼容MySQL語(yǔ)法和協(xié)議，業(yè)務(wù)無(wú)需改造即可順暢接入。
通過(guò)該架構，似乎可完美解決讀多寫(xiě)少業(yè)務(wù)對數據庫的大流量壓力問(wèn)題，但實(shí)際上仍有一些至關(guān)重要的技術(shù)細節需要把握。
其中之一就是讀寫(xiě)分離中間件的轉發(fā)性能問(wèn)題。從理論上看，可以通過(guò)橫向添加從節點(diǎn)的辦法線(xiàn)性提升數據庫集群的讀性能，但如果底層從節點(diǎn)數量加上去了，讀寫(xiě)分離中間件又是否會(huì )成為新的瓶頸？
我們十分重視這個(gè)問(wèn)題，為此首先做了一系列的數據指標估算，包括現有UDB實(shí)例的性能上限、UDB在垂直升級后根據現有訪(fǎng)問(wèn)模型估算性能上限、UDB升級為讀寫(xiě)分離主從集群后對讀寫(xiě)請求的處理性能和從節點(diǎn)數量的關(guān)系等。
第二步則是和UDB團隊配合做了讀寫(xiě)分離Proxy的壓測。
上述壓測實(shí)驗采用Sysbench程序，在兩臺物理機上模擬了底層UDB節點(diǎn)從1主線(xiàn)性增長(cháng)到1主6從的情況下，整個(gè)讀寫(xiě)分離集群的讀處理性能。從結果可以看出，得益于讀寫(xiě)分離Proxy對多核CPU的充分利用，以及代碼層面的多個(gè)性能調優(yōu)， 讀寫(xiě)分離Proxy具備可靠的轉發(fā)性能，不構成集群的性能瓶頸。從而保證集群的讀性能，能夠隨著(zhù)從節點(diǎn)的線(xiàn)性增長(cháng)，呈現幾乎完美的線(xiàn)性增長(cháng)。
實(shí)測數據令人放心，UDB團隊繼而幫助制定了整套UDB擴容計劃，我們的業(yè)務(wù)代碼也相應做了調整，整個(gè)方案可以在網(wǎng)站用戶(hù)幾乎零感知的情況下實(shí)施。此后，我們后端服務(wù)的擴容有條不紊地開(kāi)始，每天凌晨在業(yè)務(wù)低谷時(shí)執行擴容，先擴容主站應用集群，將數據庫升級到讀寫(xiě)分離集群，然后逐層向外擴容外圍單體服務(wù)，整個(gè)擴容工作設計合理，快馬加鞭實(shí)施到位。
公益項目開(kāi)始后，2月1號到2月10號短短10天內，趕考狀元平均日注冊用戶(hù)量由0.83萬(wàn)上升到3萬(wàn)，最大單日注冊用戶(hù)達5.8萬(wàn)。平穩承壓了單日20萬(wàn)用戶(hù)的web/App訪(fǎng)問(wèn)，順利地為全國各地區超過(guò)100萬(wàn)學(xué)生免費贈送了在線(xiàn)微課學(xué)習、題庫練習、作業(yè)組等線(xiàn)上服務(wù)，為停課不停學(xué)“添磚加瓦”，貢獻了優(yōu)質(zhì)的公益教育資源。
在此期間，我們業(yè)務(wù)數據庫的吞吐量（QPS）暴漲了近20倍，目前線(xiàn)上讀寫(xiě)分離Proxy單實(shí)例最高QPS已達到20萬(wàn)以上，升級到讀寫(xiě)分離集群后，通過(guò)1主6從加2節點(diǎn)雙活讀寫(xiě)分離Proxy的集群配置，平穩扛住了業(yè)務(wù)流量的高速增長(cháng)。我們的技術(shù)架構，也成長(cháng)為一個(gè)具有相當規模的中型互聯(lián)網(wǎng)服務(wù)。
在渡過(guò)2月10號這個(gè)線(xiàn)上開(kāi)學(xué)高峰后，業(yè)務(wù)依然在高速發(fā)展，雖然主從讀寫(xiě)分離集群在應對業(yè)務(wù)高QPS訪(fǎng)問(wèn)上不成問(wèn)題，但隨著(zhù)業(yè)務(wù)模塊的增多，在2月12號上午高峰期業(yè)務(wù)向數據庫發(fā)起的連接數，已經(jīng)達到高可用版UDB產(chǎn)品6000的上限。
為了從根本上解決這個(gè)問(wèn)題，UDB研發(fā)團隊建議，將高可用UDB的后臺架構，從傳統的VIP+代理+DB 的架構升級為其最新開(kāi)發(fā)的漂移 VIP+DB 雙主新架構。為此他們連夜制定了透明升級的方案，能夠不遷數據在2分鐘內從舊架構原地升級為新架構，獲得我們認可并在凌晨實(shí)施，確保第二天業(yè)務(wù)的正常運行。
新的高可用UDB架構，利用穩定的UCloud虛擬網(wǎng)絡(luò )VIP管理服務(wù)，將架構簡(jiǎn)化為更樸素的漂移 VIP+DB 雙主的實(shí)現，在數據鏈路上減少一次轉發(fā)，消除一個(gè)潛在性能瓶頸，并且簡(jiǎn)化控制模塊，減少不可控因素。同時(shí)新架構對數據庫（MySQL 和 PG）原生的兼容度更高。
提前規劃和快速擴容，給了我們更多的余裕，能去快速應對和解決大流量突發(fā)時(shí)暴露的其它隱藏問(wèn)題，最典型的例子是數據庫慢查詢(xún)。
我們后臺代碼采用了ORM框架連接MySQL，由于ORM層屏蔽了底層MySQL庫表的細節，小部分訪(fǎng)問(wèn)MySQL的代碼沒(méi)有考慮到底層MySQL的執行邏輯，存在慢查詢(xún)過(guò)多的問(wèn)題。慢查詢(xún)的問(wèn)題，在平時(shí)小流量慢增長(cháng)的情況下影響并不明顯，但是疫情期間大流量壓力下就變得不容忽視。
UCloud DBA團隊期間提供了諸多幫助，他們在慢查詢(xún)問(wèn)題的定位和解決上有豐富的經(jīng)驗。疫情期間，他們克服在家辦公干擾多,遠程溝通不便等不利因素，通過(guò)微信、遠程會(huì )議等方法隨時(shí)和我們保持聯(lián)系，結合我們對業(yè)務(wù)邏輯的理解，協(xié)同定位問(wèn)題，一起梳理了業(yè)務(wù)近半年所有新增數據庫表并增加索引，最終慢查詢(xún)的問(wèn)題得到有效解決。
【留言互動(dòng)】面對各種突發(fā)緊急的業(yè)務(wù)擴容需求
你有什么想法和故事？
歡迎文章底部留言，點(diǎn)贊數排第一即可獲得技術(shù)書(shū)籍
《計算機程序的構造與解釋》一本，截止時(shí)間3月19日18:00
聯(lián)系客服
