連B站都崩過，實(shí)現(xiàn)系統(tǒng)高可用的確有難度

　　7月13日，網(wǎng)友的深夜狂歡第一次出現(xiàn)了除消費(fèi)盛宴、明星八卦、重大新聞以外的話題—網(wǎng)站崩潰。

　　B站崩了首先在微博熱搜燃爆，豆瓣崩了、A站也崩了、晉江崩了緊隨其后，上演了一出熱搜會(huì)晤。

　　直到7月14日凌晨2:20分，官方回應(yīng)機(jī)房發(fā)生故障，但是并未對具體宕機(jī)原因作說明。

　　于是，廣大網(wǎng)友腦洞大開，開始推測本次故障是誰的鍋。出現(xiàn)機(jī)房斷電、機(jī)房著火、黑客攻擊、云服務(wù)異常、CDN異常、運(yùn)維實(shí)習(xí)生失誤操作、奧特曼襲擊等各種假說。。。

　　不管是何種原因造成的故障，只有經(jīng)過完善的復(fù)盤，才能吸取教訓(xùn)，避免同樣的問題再次發(fā)生。顯然此次重大故障，再一次讓許多企業(yè)意識到建設(shè)高可用容災(zāi)系統(tǒng)的重要性。應(yīng)用級別的容災(zāi)體系通常包含了流量接入層、應(yīng)用層、數(shù)據(jù)層多個(gè)方面的建設(shè)方案。

　　以數(shù)據(jù)庫層面的高可用容災(zāi)建設(shè)為例，由于不同的業(yè)務(wù)部門對RTO（恢復(fù)所需的時(shí)間指標(biāo)）以及RPO（能夠恢復(fù)到的最新狀態(tài)）兩個(gè)指標(biāo)的期望值不同，對性能、可擴(kuò)展性、停機(jī)成本、維護(hù)成本等其他可用性變量的側(cè)重點(diǎn)不同，最終的實(shí)現(xiàn)方案也存在一定的差異。

　　無論什么實(shí)現(xiàn)方案，最根本的核心始終圍繞5個(gè)方面的高可用技術(shù)。

　　整體建設(shè)過程通常包含調(diào)研評估、架構(gòu)規(guī)劃、測試、上線四個(gè)階段。

　　需要強(qiáng)調(diào)的是，容災(zāi)演練是驗(yàn)證故障發(fā)生時(shí)業(yè)務(wù)連續(xù)性、數(shù)據(jù)可用性的重要手段。對于7*24小時(shí)運(yùn)行的系統(tǒng)，通常采取破壞性測試，模擬服務(wù)器、數(shù)據(jù)庫、應(yīng)用調(diào)度等多種場景的故障，以檢驗(yàn)容災(zāi)系統(tǒng)是否具備業(yè)務(wù)接管的必要條件。

　　然而系統(tǒng)上線并不意味著容災(zāi)演練的結(jié)束，而是常態(tài)化的開始。由于系統(tǒng)隨著業(yè)務(wù)的調(diào)整，會(huì)不斷有框架升級或部署架構(gòu)的迭代更新，只有通過定期演練，針對每一次變化確定具體的場景和范圍，才能及時(shí)發(fā)現(xiàn)災(zāi)備系統(tǒng)的缺陷，提高突發(fā)事件響應(yīng)與處置能力。

　　數(shù)據(jù)庫高可用容災(zāi)實(shí)踐

　　客戶簡介

　　該企業(yè)作為互聯(lián)網(wǎng)+健康醫(yī)療整體解決方案提供商，首創(chuàng)國內(nèi)互聯(lián)網(wǎng)+健康醫(yī)療區(qū)域服務(wù)平臺和標(biāo)準(zhǔn)智慧醫(yī)院概念，通過優(yōu)化咨詢、預(yù)約、一卡就診、電子病歷管理、診間支付等就診流程，打造線上+線下的智慧醫(yī)院O2O閉環(huán)服務(wù)生態(tài)系統(tǒng)，從而解決就診過程的“三長一短”問題。

　　高可用需求

　　一次系統(tǒng)故障，讓自助就診系統(tǒng)突然卡死，導(dǎo)致多個(gè)醫(yī)院的掛號業(yè)務(wù)全面癱瘓，嚴(yán)重影響了醫(yī)療工作的正常運(yùn)轉(zhuǎn)。

　　云掣數(shù)據(jù)庫專家對系統(tǒng)進(jìn)行了緊急救援，快速恢復(fù)業(yè)務(wù)。通過故障復(fù)盤，發(fā)現(xiàn)該企業(yè)在數(shù)據(jù)庫運(yùn)維管理方面存在開發(fā)規(guī)范缺失、變更審核機(jī)制不完善、集群選型與應(yīng)用場景不匹配等一系列亟需解決的問題。

　　為了避免再次出現(xiàn)此類重大故障，同時(shí)提高系統(tǒng)的健壯性、穩(wěn)定性和可靠性。客戶委托云掣數(shù)據(jù)庫專家針對業(yè)務(wù)現(xiàn)狀，做數(shù)據(jù)庫系統(tǒng)的同城雙活高可用容災(zāi)架構(gòu)改造。

　　主要難點(diǎn)

　　根據(jù)業(yè)務(wù)要求，整個(gè)高可用改造過程需要做到業(yè)務(wù)0中斷，數(shù)據(jù)0丟失、0出錯(cuò)，同時(shí)核心業(yè)務(wù)的數(shù)據(jù)庫系統(tǒng)要做到跨機(jī)房的容災(zāi)能力。

　　解決方案

　　通過詳細(xì)的調(diào)研，基于該智慧醫(yī)療系統(tǒng)業(yè)務(wù)實(shí)際情況，圍繞正常運(yùn)行時(shí)間、恢復(fù)時(shí)間、恢復(fù)能力、停機(jī)成本4個(gè)核心可用性變量，云掣提供了以“MHA+ProxySQL+Keepalived”為基礎(chǔ)的高可用架構(gòu)方案：

　　使用千兆光纖物理專線連接同城雙機(jī)房，確保網(wǎng)絡(luò)連接質(zhì)量和數(shù)據(jù)傳輸速度。

　　基于專線構(gòu)建大局域網(wǎng)，降低網(wǎng)絡(luò)環(huán)境復(fù)雜度，保障數(shù)據(jù)傳輸?shù)陌踩浴?/p>

　　主機(jī)房部署雙節(jié)點(diǎn)，限制服務(wù)器級故障轉(zhuǎn)移在同機(jī)房內(nèi)切換，保障恢復(fù)速度。

　　備份實(shí)例使用級聯(lián)復(fù)制，隔離于業(yè)務(wù)系統(tǒng)之外，提供日常報(bào)表查詢及數(shù)據(jù)庫備份服務(wù)。

　　當(dāng)主機(jī)房A癱瘓，所有功能模塊會(huì)全部轉(zhuǎn)移到容災(zāi)機(jī)房B，繼續(xù)對外提供服務(wù)。

　　基于云掣數(shù)據(jù)庫運(yùn)維管控平臺EasyDo，對數(shù)據(jù)庫進(jìn)行監(jiān)控，降低運(yùn)維成本的同時(shí)運(yùn)維提高效率。

　　客戶收益

　　徹底鏟除原有架構(gòu)暴露的安全隱患，跨機(jī)房MHA+自動(dòng)備份機(jī)制，保障數(shù)據(jù)存儲安全。

　　ProxySQL實(shí)現(xiàn)應(yīng)用無感知切換，解決客戶對架構(gòu)改造的擔(dān)憂，真正實(shí)現(xiàn)了業(yè)務(wù)0中斷。

　　故障恢復(fù)效率得到明顯提升，由服務(wù)器硬件引發(fā)的故障，可實(shí)現(xiàn)分鐘級別切換到備庫。

　　數(shù)據(jù)庫系統(tǒng)作為智慧醫(yī)療體系中重要的后端支撐，自上線以來一直穩(wěn)定運(yùn)行，使患者獲得了更好的就醫(yī)體驗(yàn)。

　　但在整個(gè)業(yè)務(wù)系統(tǒng)中，數(shù)據(jù)庫屬于既核心又脆弱的一環(huán)，雖然做到了高可用，如果使用不當(dāng)同樣會(huì)對性能產(chǎn)生不良影響，給業(yè)務(wù)帶來嚴(yán)重的損失，因此仍需要專業(yè)的專家運(yùn)維服務(wù)持續(xù)為企業(yè)提供數(shù)據(jù)庫穩(wěn)定性保障。云掣通過讀寫分離、OLAP剝離以及SQL優(yōu)化服務(wù)，有效提升了數(shù)據(jù)庫性能，通過SQL變更審核服務(wù)，解決了數(shù)據(jù)變更及對象設(shè)計(jì)不規(guī)范的問題。

　　推薦閱讀