資料庫納管平台DBhouse的技術路線與實踐
- 2022 年 4 月 7 日
- 筆記
為幫助開發者更好地了解和學習前沿資料庫技術，騰訊雲資料庫特推出”DB · TALK“系列技術分享會，聚焦乾貨賦能創新，邀請數十位鵝廠資深資料庫專家每月和您一起深入探討雲資料庫的內核技術、性能、架構、管理運維和最佳實踐等。
3月30日第一期分享會「資料庫管理與運維」專場已結束，錯過直播的小夥伴也不要拍大腿，本期帶來騰訊雲資料庫產品經理陳昊分享《資料庫統一納管平台DBhouse技術路線的最佳實踐》的文字回顧。
大家好，我是陳昊，我的分享包括四個部分：產品建設背景，為什麼要做DBhouse；產品架構，包括技術架構和產品功能；DBhouse的幾個關鍵技術路徑去分享；分享現階段的投產經驗。
一、DBhouse誕生記
在當前互聯網時代背景下，運維的資料庫種類呈現出急劇增長的態勢，主要原因是數據類型不一樣，有關係型的、非關係型例如文檔型的等不同分類，另外在政策的影響下，國產資料庫也應運而生，這就導致企業中使用的資料庫種類和數量越來越多。隨著業務的不斷增長，上線變更也越來越頻繁，對資料庫性能和穩定性的需求也在持續增加，單個資料庫伺服器已經難以滿足業務需要，必須考慮資料庫集群和資料庫架構的變化方式來提升性能。
而高性能資料庫集群的第一種方式是讀寫分離，本質是把壓力分散到集群的各個節點，但是並沒有分散存儲壓力。第二種方式是分庫分表，既可以分散訪問壓力，又可以分散存儲壓力。我們以MySQL為例，如果要去做一個MYSQL的高可用集群，首先要對mysql的庫進行垂直拆，比如拆分成不同的邏輯庫。每個邏輯庫也可能會出現多個分片，每個分片採用一寫多讀的架構去保證節點的可用性。通常也會採用MHA的方式實現高可用，除此之外如果要去滿足災備能力，我們也要把不同的庫放到不同的IDC機房裡去滿足災備需求。
除此之外，我們也會用到proxy去做讀寫分離和分片，用LVS去做高可用和負載均衡，ZK去實現分片規則動態更新，通過選舉機制來完成節點宕掉之後的主備切換。所以整體看下來，企業當前面臨的問題是隨著資料庫種類的變多，用戶量也在不斷增多。對DBA的技術能力和架構設計能力也是一個挑戰。這是我們遇到的第一個挑戰，運維架構的複雜性帶來的挑戰。
第二個運維挑戰是規範。不同的資料庫類型會有不同規範，企業一般也會在通用的規範下個性化訂製不同規範。整體規範我們大概可以區分為三類，開發規範、上線規範和運行規範。比如在開發規範中，會要求開發人員禁止使用視圖，包括觸發器和外鍵的這種情況。上線變更的時候，主庫要開啟慢同步模式；在運營規範中，比如連接數不允許超過1000等。其實規範是越來越多的，規範類型也不一樣，針對不同類型的庫規範也不一樣。
但是資料庫規範化是很有意義的，能儘可能減少數據冗餘，並且降低數據插入異常的情況，但是數據變更規範如果全靠人工去維護的話，面臨如此多的規範，其實是有一定難度的，我們更希望通過機器去規避這些風險，讓機器先一步去做規範審核，所以後面我們也會講到DBhouse的一大管理功能-SQL審核能力。
第三個挑戰是開發和運維團隊的交互成本很高。在企業中，一般都是一個DBA對應著很多應用人員，如果應用人員發現問題時再去回饋DBA，然後DBA再去懷疑資料庫，進機房去看。整體看下來，傳統的開發人員和DBA的交互模式管理起來是比較複雜的。
總結來看，其實就分為兩大痛點，一個是資料庫運維問題，一個是我們流程管理的複雜度。
那怎麼理解自身的複雜度？就是說當開源資料庫和傳統資料庫同時使用的時候就會導致資料庫的數量和種類越來越多，並且運行環境也越來越複雜，架構也越來越豐富，互聯網上線的變更也變得越來越頻繁，流程管理的複雜度也日益增加。
以往的資料庫管理方式主要是以需求驅動，運營團隊一般是被動去為產品和開發部門提供運維操作，如建庫和擴容升級等，比較簡單重複，但又消耗大量工作精力。所以我們就在思考，如何去簡化這樣操作，提升運維效率。
傳統管理方式的另一個特點是屬於事件驅動型的，團隊一般會有一定的事件防禦和檢查機制，但是又不是很全面。當一個資料庫事件發生之後，很多時候都是通過業務部門或者開發部門回饋後運維團隊再介入進來，效率就很難提高。另外，傳統運營模式下對運維人員的技能要求也比較高， DBA的需求量在不斷增加的同時技術門檻也變得越來越高了。
因此，DBhouse應運而生。
簡言之，DBhouse是資料庫統一納管平台，幫助企業實現資料庫運維自動化、自助化和流程化。有三大功能：
監控能力
我們會去做一些資料庫探活，包括數據採集，採集完的數據會定義告警。能力包括常用的資料庫巡檢，支援導出巡檢報表；
安全能力
包括制定規範、客戶審核、許可權管理、完善審批流程鏈路、支援審計等。
運維能力
DBhouse最大的特點是幫助運維人員提高運維效率，通過JDBC和腳本的方式能夠幫助用戶去做很多運維操作，快速處理故障，比如說去做擴縮容。在交付場景上也能去實現自助化、標準化和自動化。
二、DBhouse架構
在講架構之前，跟大家簡單介紹一下的DBhouse目前已經支援的資料庫類型。商業資料庫主要支援Oracle、DB2還有SQL Server；開源型關係資料庫主要支援MySQL和PG；非關係型數據主要支援是MongoDB、Redis；國產資料庫目前支援的是騰訊雲國產資料庫TDSQL，其他資料庫在進一步規劃中。
下面這張圖是整體技術架構，採用的是微服務架構，去實現模組化和層次化，對平台中的所有的功能分層和分模組設計。提供三大服務，基礎服務、交互服務和集成服務。
首先看基礎服務。基礎服務最核心的點在於監控引擎。通過JDBC的方式周期性地從目標庫調用數據，最後把數據存儲到存儲庫中，然後通過CMDB服務、監控數據服務，還有分析引擎來去做數據處理。
交互服務主要是去向用戶提供的具體功能，包括監控告警能力、問題分析能力、配置用戶管理許可權等。
集成服務主要是指可拓展性，將DBhouse資料庫管理平台的微服務架構支援與客戶已有的IT運維資產進行無縫集成，可以集成的服務包括單點登錄、工單系統、統一告警平台等。這是整體的一個技術架構。
功能層面主要是分為幾層，從下至上是數據層、基礎服務層、交互服務和集成服務。
數據層負責存儲和管理平台所有數據，包括配置、監控數據。
基礎服務層主要起到數據橋樑的作用。底層數據會有很多數據存儲，通過基礎服務層給上層的功能層去提供各種基礎服務， API可以按照需求開放給其他用戶使用。主要包括思考執行、監控引擎等。
再往上層是功能層和展現層，功能層展現層主要提供各個資料庫的管理功能，包括技能管理、容量管理、問題管理和自動化運維等。
三、DBhouse的關鍵技術路徑
第三部分我會挑上面講的DBhouse的三個主要功能，對監控能力、自動化運維能力和SQL審核能力的技術路徑做一些解釋。
首先是監控和告警能力，DBhouse本身提供了大量的資料庫運行狀態指標，如資料庫性能指標、容量分析指標，然後我們會按照固定頻率去採集監控數據，從而提供實時查詢功能，並且以圖形化的方式呈現給使用者，可以將故障分析能力從平均的30分鐘縮短到5分鐘內。
那我們的數據監控主要是怎麼去做的？傳統的採集方式一般是採用agent的模式，而DBhouse採用的實際上是一種無agent的模式。那什麼是agent的部署模式？所謂agent的模式，顧名思義就是在主機上去部署代理軟體，通過代理軟體去完成這樣主機監控。有agent和我們這種採用JDBC無agent的兩種取數方式可以理解為一個是推送數據，一個是拉取數據。在場景上面來看，因為DBhouse的定位本身在於納管企業的全部資料庫，所以會面臨著大量的需要監控的資料庫，如果採用agent模式，會遇到諸多問題，比如部署周期長，需要在每一台伺服器上部署，資源佔用性強，並且有可能面臨著兼容性風險。
總結來看，agent的模式一是侵入性強，相當於要佔用伺服器一部分資源，並不是每個客戶都可以接受；二是面對監控規模比較大的客戶，agent的維護與調度成本也相對較高一些。因此我們採用了一種通過jdbc的無agent模式，通過設置定時任務，周期性地從目標資料庫拉取監控指標，而我們也都知道，資料庫的不同指標因為其屬性不同、監控力度不同，所以我們設置了一個規則引擎，面對不同的指標數據，通過不同的演算法進行定時任務拉取。該引擎負責持續對採集到的監控數據進行智慧分析，從多個維度、多種規則進行計算，採用了基於基準線的智慧化演算法，從大量的監控數據中篩選出可能影響資料庫性能與可用性的問題條目，並持續對已有的問題進行跟蹤管理並向用戶發起推送。推送時以郵件介面為主，支援不同介面類型及自動發送問題、手動發送問題等多種方式，同時可以進行訂製化，與客戶的統一監控、ITIL等系統進行無縫整合。
那麼DBhouse如何實現自動化運維？我們基於ansible同合作夥伴新數自研了這樣一套自動化運維引擎，主要有以下特點：
作業編排：可以自由選擇相應的原子化操作編排和發布新的作業流程。在講作業編排的之前提兩個核心概念，一個是作業，一個是任務。怎麼理解這個作業？簡單理解就是發起一個運維操作，從頭到尾以這種結果導向；而任務就是完成作業的每一個步驟。
並行調度: 同一個作業中的任務支援並行執行，在很多場景下能極大的縮短執行時間。
斷點執行: 執行錯誤的任務在修復錯誤後可以繼續執行，不需要重新執行整個作業。
任務回滾: 遇到錯誤，可以支援回滾作業中已經執行過的任務，恢復執行環境。
計算表達式: 使用表達式動態的計算任務的參數值，能夠極大的簡化重複參數的輸入以及複雜參數的拼接。
動態參數：前面任務的輸出作為後續任務的輸入參數。
這是整體的流程圖。
簡單來說，我們主要分為以下幾層。
第一部分是交互功能，第二部分是引擎，第三部分是任務執行器和消息中心。自動化運維引擎是整個作業系統的調度核心，決定任務什麼時候開始執行，作業是否執行完成，啟動任務執行器執行任務等。
下面我們就從系統架構，作業的實時運行狀態以及編排逐步進行介紹。系統主要分為以下幾層：
- 交互功能: 自動化運維引擎對用戶提供原子操作發布、作業編排、管理、作業調度和運行狀態查看等功能
- 作業引擎: 作業系統的調度核心，決定什麼任務開始執行，作業是否執行完成，啟動任務執行器執行任務，維護作業和任務的狀態等
- 任務執行器: 執行任務的邏輯，針對多種場景擴展了不同的執行器，可以在一個作業流程中同時支援JDBC操作、執行腳本和執行HTTP API操作；由於執行器有各自的執行環境，天然支援多任務的高並發執行
- 消息中心: 任務執行結束後，通過消息驅動作業引擎進行後續任務的調度，任務執行器不與作業引擎直接交互，降低了系統的耦合度，且利於作業引擎的彈性擴容。
計算表達式為了實現參數的復用，DBhouse引入了表達式的機制。目前，DBhouse主要支援五種表達式，任務參數、全局參數、部分參數、任務組參數和任務結果。也包括前端計算和伺服器端的運行計算，表達式包括前端計算和伺服器端運行時計算: ${xxx} 在前端進行計算，#{xxx} 在伺服器端任務調度的時候進行計算，表達式可以任意組合使用。除此之外，DBhouse也更加簡化了參數的輸入模式，通過選擇器的方式讓用戶去選擇，用戶只需要點選就可以完成一個參數的輸入。
下一部分是安全管理能力，包括兩部分，一部分是怎麼更好地匹配SQL語句，另一部分是做安全審批，最開始讓機器去做審核，辨別出一些高危和低效的操作，在最後審核通過了之後發起審批，由DBA或者主管部門去進行相關審批，審批通過之後再執行任務。執行任務之前DBhouse會去做數據備份，我們可以選擇去自動備份或定時備份。執行過程中我們可以支援定時執行或手動執行，所有操作完成之後，操作記錄會形成一個日誌供審計或複核。
眾所周知，在做整個SQL審核過程中，較為複雜的難點就在語法匹配能力上，如果告訴機器你輸入的SQL語句什麼，如何去匹配審核規則。談到SQL解析，就不得不談一下文本識別。文本識別是根據給定的規則把輸入文本的各個部分識別出來，再按照特定的數據格式輸出。以樹形結構輸出是最常見的方式，這就是通常所說的抽象語法樹。
DBhouse在做解析的時候是通過詞法解析+語法解析+分片上下文提取做到的。在詞法解析上面，DBhouse會通過自己的詞法解析器將SQL拆分為一個個不可再分的詞法單元（Token）。在SQL語法中，通常將詞法單元拆分為關鍵字、標識符、字面量、運算符和分界符。
在做完詞法解析之後再進行語法解析。這裡的語法解析，我們一般採用的是貪婪匹配演算法。
在做完詞法解析後，我們隨後會進行語法解析，這裡語法解析我們採用的是貪婪匹配演算法，就是最長路徑匹配方式，語法解析器每次從詞法解析器中獲取一個詞法單元。如果滿足規則，則繼續下一個詞法單元的提取和匹配，直至字元串結束；若不滿足規則，便提示錯誤並結束本次解析。
語法解析難點在於規則的循環處理以及分支選擇，還有遞歸調用和複雜的計算表達式等。
在選擇分支時，可能會出現一個分支是另一個分支的子集。此時，當成功匹配短路徑時，需要進一步匹配長路徑，在無法匹配長路徑時，再選取短路徑，這稱之為貪婪匹配。如果不使用貪婪匹配的演算法，則最長的分支規則便永遠不能被匹配了。
完成了SQL解析之後，最後一步便是對數據分片所需的上下文進行提取。它通過對SQL的理解，以訪問抽象語法樹的方式去提煉分片所需的上下文，並標記有可能需要改寫的位置。最後返回到用戶介面提示需要改寫這個SQL是高風險還是低風險的，可能需要改什麼內容等。
四、經驗總結
最後分享一些經驗總結。第一個經驗是在以往沒有運維工具的場景下，我們發現異常之後流程是比較長的，通過DBhouse我們可以盡最大程度去降低人與人之間的交互，降低溝通成本，通過這樣便捷、易用、安全、保密可追溯性最大程度地提高運營效率效率。
第二個經驗就是可拓展性，因為DBhouse就是要幫助用戶管理資料庫，提供運維和監控能力，保證安全，所以在整體設計的過程中，DBhouse所有模組化功能都具備可拓展性的能力，能夠自定義運維工具。
第三個經驗是整體運維分析能力，幫助用戶隨時隨地發現資料庫存在的問題，通過可視化報表展現出來。
想獲取更多資料庫相關知識，可以關注【騰訊雲資料庫】微信公眾號哦
