從傳統資料庫架構遷移至雲資料庫，如何實現平滑遷移？在多雲、混合雲以及多機房環境下，如何解決高可用和運維挑戰？本文結合鬥魚實際業務環境，具體介紹了混合雲架構實踐及運維過程！
▲本期分享嘉賓：趙閃 武漢鬥魚網絡科技有限公司 DBA主管
嘉賓介紹：
趙閃，2014年研究生畢業，2014年中國電信DBA，2016年加入鬥魚直播；現負責鬥魚資料庫的運維架構以及資料庫團隊的管理，發表了多篇關於資料庫故障切換的專利；對多種資料庫均有一定研究，主要熟悉的資料庫有MySQL、postgresql、MongoDB、redis等;
熟悉多種業務場景架構，對維護高並發和海量數據業務有一定經驗；目前主要工作為資料庫中間件開發和相關工具平台開發。
如何實現資料庫平滑遷移
企業之前的數據都在自建的IDC里，如何把PB級數據同步到雲上去？每天增量的數據也是TB級，這些數據如何快速高效地同步到雲上去？數據同步過程中速度比較慢，如何解決？如何把業務安全、高效地遷移到雲上去 ？這些都是資料庫遷移過程中，必然會遇到的問題！
具體而言，資料庫上雲會遇到3個重要的架構遷移問題：
1、 統一帳號，流量收攏
從A機房到B機房，最首要的問題就是流量、DNS切換、路由切換，如何在不停業務的情況下，通過一個統一的平台，實現帳號管理以及流量的收攏，是一個重要挑戰。
2、 數據實時同步
在資料庫遷移之前，用戶訪問數據會直接到中間件層，然後再到遷移前的資料庫。但是為了確保業務不受影響，遷移過程中要做一些調整。遷移前的資料庫和遷移後的資料庫會有一段時間並行。這時，整個業務架構要充分考慮到數據同步、請求切換以及訪問耗時等問題。
3、讀寫流量分離
在資料庫遷移時，還要考慮自動讀寫分離以及讀寫分離路由的規則。因為，大量流量來到資料庫，會造成IO飆升，使得請求變慢，導致資料庫CPU飆升無法響應，所以在遷移架構設計上，一般要考慮如何做到主從讀寫分離。
面對上述挑戰，鬥魚的做法是觀察業務訪問形態，確定業務訪問邏輯，同時關注讀寫比例，確定遷移順序。為了確保數據的實時同步，還要關注時延和業務敏感性，測試直連和代理性能差異 ，測試業務兼容性。新資料庫上線後，即便做了讀寫分離，也要隨時關注流量壓力以及參數對比，確保整個業務的平穩運行。
混合雲場景下的負載均衡和故障切換
隨著業務量的增加，會採用多活架構來解決負載均衡和故障切換的問題。
比如：A機房是主力機房，提供核心業務80%流量，邊緣業務50%流量；B機房承載20%的核心業務流量，50%的邊緣業務流量；C機房提供其他業務以及災備，比如離線分析等場景。
具體的做法是，不管是路由層、代理層還是資料庫層，全部由配置中心統一配置並下發各個機房。其中，路由層實現機房流量、讀寫流量的調度；數據通過專線保證一致性，實現數據響應到達秒級以內的延遲。
整個設計規則是，每個機房都有流量,每個機房都能讀寫，是完全的多活，遇到單元高可用以及單元故障問題，直接轉移到另一個機房繼續提供服務。
比如：A機房發生故障時，B機房承接流量，保證業務連續性。要根據故障時間、寫沉默時間設置業務邏輯。故障發生時，未完成的處理邏輯進入異常狀態，進行回滾和補償處理。整個過程中，系統要做到讀秒級切換，保證事務完整執行，避免因事務導致數據丟失或者重複操作，進而出現數據的不一致性。
混合雲場景下的降級容災
混合雲、多雲雖然在性能、彈性靈活、方便易用等方面有著諸多優勢，但云環境同時又是個「黑盒」，仍然存在容災和高可用的問題，需要一定的策略來確保數據不丟失。
大體來看，故障容災主要集中在四個維度：
1、 RPO VS RTO
RPO和 RPO 都是企業災難恢復需要重點考慮的關鍵指標，這兩個指標可以用來指導企業來制定合適的業務系統服務或數據的恢復方案。
RPO.即數據恢復點目標，主要指的是業務系統所能容忍的數據丟失量。如果以定期計劃的24小時增量備份全部或大部分數據，那麼在最壞的情況下，全量備份和日誌恢復可能導致企業丟失1-2個事務的數據，對於大部分應用來說，是可以接受的。
RTO即恢復時間目標，主要指的是所能容忍的業務停止服務的最長時間，也就是從災難發生到業務系統恢復服務功能所需要的最短時間周期，此兩點之間的時間段稱為RTO。比如： 4小時RTO允許從裸機恢復開始進行本地恢復，並以完整的應用程式和數據可用性結束。
RTO 和 RPO 都使用時間來度量，但是使用它們的目的卻不相同。RTO 關注於應用或系統的可用性，RPO 關注於數據的完整性，描述所能容忍的最大數據丟失限制。
在制定容災計劃時，需要根據業務特點確定 RTO 和 RPO目標。
2、 性能成本基線
把容災放到雲上，成本會降低不少。雲上應用和本地一樣，當系統的操作響應時間超出可接受的程度，說明已出現了性能問題。每秒請求處理量(QPS)，是對一個特定的應用系統在規定時間內所處理流量多少的衡量標準，要設定好這個基線。
3、 數據同步
常見的容災模式比較簡單，包括：資料庫冷備，即每天備份一次資料庫；雙機本地熱備，即一份數據存在不同盤陣上並多存幾份，保證壞一個盤不影響數據讀寫；資料庫熱備，建立資料庫災備中心，與主庫實時進行數據同步，同時應用系統保持文件實時同步，保證引用版本最新。為了實現從源資料庫到目標資料庫的實時數據同步，要重點關注耗時數據。
4、流量卸載
為了確保整個業務環境的健壯性，還要重點關注流量。當請求量大，但時效性不高的時候，可將限流數控制小一些；當請求量大，但時效性高的時候，可將限流數適當調高，同時要分離讀寫流量。
最後，要能夠提供柔性有損服務，當條件有限而不能向用戶提供完美服務時,可以以柔性的方式提供有損的服務，最大程度的保證關鍵服務的可用性。
當然，為了讓容災方案實現價值最大化，對業務進行等級劃分也是重中之重。對於核心業務要實現雙向同步，以兩地多中心的方式進行容災；對於關鍵業務，要能夠實現實時同步，做到雙活；對於重要業務，要實現主從同步，以主備模式保護數據和應用；對於邊緣業務，要能夠實現定時同步，做到災備層面的萬無一失。
雲原生場景下的資料庫運維挑戰
如今，資料庫也在擁抱雲原生方向，為了讓雲上應用更加方便、快捷，鬥魚有三個重要實踐。
1、 接口化
整個管理平台被分為四大層面，包括需求管理、上線管理、數據管理和監控管理。每一層分管不同的業務。
比如：需求管理解決的是DNS配置、數據遷移、檢測對比等WEB自動化的能力，同時還包括其他開發能力、運維管理等。上線管理解決的是從實例初始化到需求管理再到資源交付過程的整個流程，並且與質量巡檢、規範巡檢、瓶頸巡檢緊密關聯。
所以應用與應用之間，均以接口化的形式處理，可以通過API調用的方式實現，極大地方便了雲資料庫層面的統一管理和快速應用。
2、 運維內部化
雲資料庫運維有多種方案，最有效的做法是，實現運維的內部化。即按照業務形態劃分業務，比如劃分為在線業務和離線業務，不同的業務類型設定不同的成本和SLA標準。在線業務包括彈性調度、自助服務、容量管理、性能巡檢和備份管理，一般對時效性和數據準確性要求較高，這部分業務需要保障99.999%的可靠性。離線業務包括離線分析、緩存分析、日誌分析，這部分業務通過分布式關係型資料庫集群和緩存集群來支撐，一般對時效性要求較低，這部分業務可以提供99.95%的可靠性。同時也可以針對不同的業務性質採購不同的硬碟和設備，實現成本和性能的平衡
3、 IaC基礎設施代碼化
在傳統IT業務環境下，IT基礎設施管理都是由組織的系統管理員人工完成。他們管理應用程式運行所需的所有硬體和軟體。在過去幾年，隨著數位化轉型步伐的加快，IT技術取得了長足的進步，現在除了這種人工管理之外，還有一種替代方法，叫做「基礎設施即代碼(IaC)」。
不管是日誌管理、還是資產流轉，所有內容都可以實現自動化，並儘可能地消除所有人工工作。除了要在配置文件中明確所有基礎規範，還像其他代碼一樣，被持續測試、持續集成和部署，檢查應用部署到生產之前可能發生的錯誤或者不一致，確保整個基礎設施的高可用性。
基礎設施代碼化，真正將雲資料庫運維實現高度自動化，運維人員可更輕鬆、高效地運行和管理系統。
結論：在雲資料庫架構改造過程中，可能會遇到的問題有千種，解決方案也不同，在具體實踐中，我們可以結合傳統運維方式、架構變遷等要求，對資料庫架構進行更個性化的部署，而與雲原生模式結合，可讓開發和運維達到事倍功半的效果。
