本文根據魯越老師在〖Gdevops 2018全球敏捷運維峰會成都站〗現場演講整理而成。
講師介紹
魯越，騰訊雲數據庫架構師團隊負責人，主要負責MySQL、Redis等數據庫售前架構、運維、調優等工作，曾就職於網易和尼比魯。
大家好，今天很高興能和大家分享一下我們騰訊雲數據庫海量運維的經驗，主要分為以下三部分：
數據庫架構師團隊的組建
自動化運維平臺的建設
智能海量運維的實踐
數據庫架構師團隊的組建
1組建緣由
由於數據庫產品的特殊性和複雜性，我們在平時服務客戶的過程中常遇到一些問題，例如：分佈在各行各業的客戶，他們會有不同的場景需求，這對於數據庫的應用來說存在有非常大的差別。而我們的售前架構師可能沒辦法對各行各業在數據庫方面的應用、對不同客戶需求的架構都做到非常精通，因此無法推薦出最優的架構。
另一方面，我們的客戶非常多，但可能我們的一些售後服務工程師對於這麼複雜的數據庫產品並不是非常精通，對於難度較大的問題不能做到完全覆蓋，或是與客戶交流不夠平滑等，所以服務質量亟需提高。
基於以上兩大原因，我們組建了數據庫架構師團隊。
2分工合作
架構師團隊組建起來後，我們整個數據庫產品的服務體系就變成了以下這樣一個三層架構：第一層是運維，負責處理平臺穩定性相關的工作；第二層是架構師，負責在中間督促重難點的攻堅，包括數據庫的建設、運維工具的建設等等；第三層是一線服務工程師，負責處理主要的諮詢類、流程類的問題。
目前整個架構師團隊的工作包括四方面：
客戶運營：在進行數據運營的同時，與客戶做更多溝通，包括跟進客戶在使用數據庫時遇到的各種難題；
解決方案：包括基礎解決方案和行業解決方案；
服務體系：包括平臺運維和基礎產品運維；
平臺建設：包括客戶運營平臺、解決方案出口、支撐服務體系。
自動化運維平臺的建設
要更好地服務客戶、提高服務質量，光有數據庫架構師團隊和售後服務體系是不夠的，我們還要有一個非常穩定的自動化運維平臺來支持環境。因此，為什麼需要自動化運維平臺，這個問題的答案是顯而易見的。到目前為止，我們一共有10W+的實例、2W+的物理機，對於平臺的穩定性要求肯定是非常高。
1功能
資源管理：包括實例的象限上限、物理機的管理和部署等；
運維操作：包括升級、上限等功能；
監控：一方面是數據庫性能方面的監控，包括QPS、CPU相關的性能監控；二是可用性方面的監控。
自愈：自動發現數據庫的一些常見問題，比如發現了複製異常，平臺會主動對它進行恢復。
2架構
自動化運維平臺的整體架構從下往上共分為三層，其中最底層是APP的入口，即我們的客戶端；中間層是客戶入口；最上層是平臺後端。
從客戶端連接到APP這一層，需要經過兩個架構，我們MySQL的備份會存儲到集群，而性能監控的數據會上傳到一個模塊來實時展示我們的監控。在客戶端這一層，可以通過官網或者API的入口進入到我們的自動化運維管理平臺，可以進行資源管理、實例管理、數據傳輸等系統性的操作。我們的運維平臺，除了可以進行這樣的一些操作以外，還可以進行監控告警、運營報表、全息監控等操作。我們整個平臺的任何一個操作的數據，都會彙總到運營數據庫裡，去支持我們的後端做一些包括大數據方面的分析。
3監控模塊
整個自動化運維平臺的模塊是非常多的，在此我將重點分享一下監控模塊。前面也提及到了，我們的監控模塊分為兩個部分，第一部分是性能方面的監控，第二部分是可用性方面的監控。
如上圖所示，我們的監控模塊主要是通過兩面兩個主線組成，一個是DB master，一個是撥測Svr。如果監測到有異常的話，會把這個信息發送到DB master，收到反饋的實例異常的信息之後，會通過長鏈接，再去驗證是否真的異常。
CDB實例方面的性能監控，主要是通過cdb_report這個模塊去監控的，會實時拉取性能方面的監控，將數據、包括CDB告警都彙總到我們的Apd Netman模塊，這是比較重要的一個組件。
在一個普通場景下，撥測Svr的操作比較簡單，但這樣的場景在海量實例的架構下，可能會有什麼問題？主要包括兩點，第一點是撥測Svr的性能問題，也就是每一次在有這麼多實例的情況下，撥測請求是否能夠成功發出、按時發出；如果這個撥測Svr的性能不太好，會直接影響到每一次撥測Svr的時間間隔。如果撥測Svr性能不好，只能被迫地去把撥測Svr的時間間隔調大，這樣對我們發現實例的問題可能是不及時的。第二點是撥測Svr自身的問題，如果撥測Svr是一個單點的話，萬一它掛掉了，整個實例的狀態對於我們來說都是不可知的，將會是非常危險的狀態。
基於以上兩點原因，我們在海量場景下的撥測Svr設計會考慮到以下三點優化目標：
根據這三點優化目標，我們做出瞭如下圖所示的撥測Svr架構。這個節點又會將這些實例發射到後面的pingSvr的節點，是實際去進行撥測操作的節點，這個節點在執行了撥測操作之後，會將撥測失敗結果存入DB中，會有一個alarmChecker去實時讀取，然後進行告警。不管是成功還是失敗的請求，全部都會寫進去，會有模塊去拉取，並實時地存入數據庫中。在這些節點中，其實都有一個災備的部署。
智能海量運維的實踐
經過實踐和思考，發現在海量數據運維中，我們的自動化運維平臺還不能解決以下這些問題：
定製化服務。不同行業的場景對於數據庫的應用有著非常大差異，其實我們可以根據不同的使用場景為數據庫實現定製化和優化的服務。
數據庫問題自動診斷和調優。
因此，騰訊內部目前正在研發一個智能化的產品，可以通過包括數據挖掘，或是架構師與客戶溝通等方式，對客戶的數據庫應用場景進行畫像，從而實現定製化服務。
1定製化服務
從數據挖掘的結果以及平常與客戶的一些溝通來看，我們把一些比較特殊的使用方法總結為以下四種類型：
計算型應用：比如一個報表類的應用，可能會需要在一段時間內，頻繁地去獲取計算資源；
-
存儲型應用：比如一個歷史數據存儲的應用；
流量型應用：會拉取大量的數據；
熱點型應用：比如一個新聞類或紅包類的應用，可能在低峰和高峰的界限會非常明顯。
針對這四種特殊的使用方法，我們其實可以做一些定製化的服務，如下圖所示：
對於計算型應用，如BI報表類，它的業務特點是凌晨才執行，而整個機器在凌晨這個時間段內是比較空閒的，所以我們就可以針對這樣的計算型場景，進行一些允許閒時超用的優化。
對於存儲型應用，客戶可能比較關心的是整個容量的使用情況，那麼我們就可以相應地提供自動加載、數據壓縮的壓縮引擎。
對於流量型應用，可能會對SQL的要求非常高，如果中間有一兩個性能不是特別好的SQL，就可能會影響到整個數據庫。所以對於這種應用，我們可以給客戶提供一個類似自助SQL優化的工具，幫助客戶把SQL做一定的優化。
對於熱點型應用，我們可以提供一個實例動態升降配的功能，在業務高峰前，快速地將這個實例升到一個較高的配置。
2數據庫自動調優
針對前文提到的數據庫自動調優的問題，我們可以做一個實時分析和預測分析的工作，來分析實例的質量得分。
其中，預測分析是通過實例過去的歷史數據，來分析它在未來兩到三個月的走勢。其實這個分析也是可以做定製化的，例如上文提及的計算型應用，如果客戶對CPU比較敏感，我們在分析時就可以把CUP使用權重的比例調大；如果是對存儲、空間利用率比較敏感，我們可以把存儲方面的一些指標相應調大。通過這樣的預測分析，再加上大數據、AI的一些模型，我們就可以得出一個實例得分的指標，並以此自動地優化數據庫，或是提出一些優化建議。
Q & A
Q1：剛講的內容中有一塊是關於撥測的，想請問平常是不是撥測也會通過一個核心的表現？
A1：這個會做，我們也會去做檢測，看它是不是可寫的，這不僅僅是包括網絡上的，我們還可能對數據庫進行操作。
Q2：很多人的數據庫場景，無論是日誌還是流程，直接通過終端進去也可以看到實例的健康狀況，那撥測的操作類型跟這個相比有什麼優越的地方？
A2：撥測主要就是快速以及檢測實例的可用性，如果發現實例不可用，就需要馬上做切換，讓這個時間儘量降到最低，保證對業務的影響最小。相對於其他的日誌，它會非常快速地發現問題，區別就在這裡。
Q3：剛剛看了撥測的架構，目前還是中心化的，騰訊有沒有做去中心化的呢？
A3：會考慮，因為我們雖然在撥測上做了優化，但其實整個性能方面還沒有做到非常完善，我們會在這方面再做一些優化。目前來說，現在用的還是這一套，可能在我們的產品推出之後，就會推到騰訊雲上面去。
Q4：想請問一下騰訊雲的MySQL是採用什麼方式來保證數據的一致性和實例的可用性？
A4：數據一致性是通過主動複製的方式來保持，我們可以提供一主多從的形式，跨服務器地部署，還可以提供災備實例的功能。而實例的可用性，我們是通過撥測的方式來快速發現、定位實例的問題，一旦發生問題，會通過快速的主動切換的方式，去保證實例的高可用。
追問：切換的話也是比如說延遲達到多少，然後再進行不同的那種定級、定位嗎？
A：如果是延遲的話，是不能切的，但是在我們平時的監控過程中，會對這個東西非常關注。如果發現有主動延遲的實例，會通過各種手段去消除這樣的延遲。比如說5.5或5.6的版本就已經這樣了，5.7的版本可以使用官方原生的控制。從目前騰訊雲的實例情況來看，有主從延遲的實例還是比較少。
不妨來“2018 DAMS中國數據資產管理峰會”
繼續聽聽騰訊、輕維軟件等名企運維大牛怎麼說
掃描以下二維碼，查看峰會詳情及報名↓
↓↓↓ 點這裡下載本文PPT
閱讀更多 DBAplus社群 的文章
