連B站都崩過，實現系統高可用的確有難度

　　7月13日，網友的深夜狂歡第一次出現了除消費盛宴、明星八卦、重大新聞以外的話題—網站崩潰。

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

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

　　于是，廣大網友腦洞大開，開始推測本次故障是誰的鍋。出現機房斷電、機房著火、黑客攻擊、云服務異常、CDN異常、運維實習生失誤操作、奧特曼襲擊等各種假說。。。

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

　　以數據庫層面的高可用容災建設為例，由于不同的業務部門對RTO（恢復所需的時間指標）以及RPO（能夠恢復到的最新狀態）兩個指標的期望值不同，對性能、可擴展性、停機成本、維護成本等其他可用性變量的側重點不同，最終的實現方案也存在一定的差異。

　　無論什么實現方案，最根本的核心始終圍繞5個方面的高可用技術。

　　整體建設過程通常包含調研評估、架構規劃、測試、上線四個階段。

　　需要強調的是，容災演練是驗證故障發生時業務連續性、數據可用性的重要手段。對于7*24小時運行的系統，通常采取破壞性測試，模擬服務器、數據庫、應用調度等多種場景的故障，以檢驗容災系統是否具備業務接管的必要條件。

　　然而系統上線并不意味著容災演練的結束，而是常態化的開始。由于系統隨著業務的調整，會不斷有框架升級或部署架構的迭代更新，只有通過定期演練，針對每一次變化確定具體的場景和范圍，才能及時發現災備系統的缺陷，提高突發事件響應與處置能力。

　　數據庫高可用容災實踐

　　客戶簡介

　　該企業作為互聯網+健康醫療整體解決方案提供商，首創國內互聯網+健康醫療區域服務平臺和標準智慧醫院概念，通過優化咨詢、預約、一卡就診、電子病歷管理、診間支付等就診流程，打造線上+線下的智慧醫院O2O閉環服務生態系統，從而解決就診過程的“三長一短”問題。

　　高可用需求

　　一次系統故障，讓自助就診系統突然卡死，導致多個醫院的掛號業務全面癱瘓，嚴重影響了醫療工作的正常運轉。

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

　　為了避免再次出現此類重大故障，同時提高系統的健壯性、穩定性和可靠性。客戶委托云掣數據庫專家針對業務現狀，做數據庫系統的同城雙活高可用容災架構改造。

　　主要難點

　　根據業務要求，整個高可用改造過程需要做到業務0中斷，數據0丟失、0出錯，同時核心業務的數據庫系統要做到跨機房的容災能力。

　　解決方案

　　通過詳細的調研，基于該智慧醫療系統業務實際情況，圍繞正常運行時間、恢復時間、恢復能力、停機成本4個核心可用性變量，云掣提供了以“MHA+ProxySQL+Keepalived”為基礎的高可用架構方案：

　　使用千兆光纖物理專線連接同城雙機房，確保網絡連接質量和數據傳輸速度。

　　基于專線構建大局域網，降低網絡環境復雜度，保障數據傳輸的安全性。

　　主機房部署雙節點，限制服務器級故障轉移在同機房內切換，保障恢復速度。

　　備份實例使用級聯復制，隔離于業務系統之外，提供日常報表查詢及數據庫備份服務。

　　當主機房A癱瘓，所有功能模塊會全部轉移到容災機房B，繼續對外提供服務。

　　基于云掣數據庫運維管控平臺EasyDo，對數據庫進行監控，降低運維成本的同時運維提高效率。

　　客戶收益

　　徹底鏟除原有架構暴露的安全隱患，跨機房MHA+自動備份機制，保障數據存儲安全。

　　ProxySQL實現應用無感知切換，解決客戶對架構改造的擔憂，真正實現了業務0中斷。

　　故障恢復效率得到明顯提升，由服務器硬件引發的故障，可實現分鐘級別切換到備庫。

　　數據庫系統作為智慧醫療體系中重要的后端支撐，自上線以來一直穩定運行，使患者獲得了更好的就醫體驗。

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

　　推薦閱讀