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