vivo資料庫與儲存平臺的建設和探索

作者：vivo網際網路資料庫團隊-Xiao Bo

以史為鑑，可以知興替，做技術亦是如此，在介紹平臺之前，我們首先來一起回顧下vivo網際網路業務近幾年的發展歷程。

我們將時間撥回到三年前來看看 vivo 網際網路產品近幾年的發展狀況，2018年11月，vivo移動網際網路累計總使用者突破2.2億；2019年應用商店、瀏覽器、影片、錢包等網際網路應用日活突破千萬大關；2020年瀏覽器日活突破1億，2021年在網總使用者（不含外銷）達到2.7億，數十款月活過億的應用，資料庫和儲存產品的也達到了4000+伺服器和5萬+資料庫例項的規模。

那三年前的資料庫和儲存平臺是什麼樣呢?

2018年的資料庫服務現狀如果用一個詞形容，那我覺得“危如累卵”最適合不過了，主要表現為以下幾點；

• 資料庫線上環境的可用性由於低效的SQL、人為的誤操作，基礎架構的不合理，開源產品的健壯性等問題導致可用性經常受到影響。

• 變更不規範，變更和各種運維操作的效率低下，沒有平臺支撐，使用命令列終端進行變更。

• 資料庫使用的成本極高，為了應對日益複雜的業務場景，增加了很多額外的成本。這些就是2018年當時vivo的資料庫現狀。

• 安全能力不夠健全，資料分類分級、密碼賬號許可權等缺乏規範。

我們再看看這些年vivo資料庫一些運營資料上的變化趨勢。

從17年底，18年初開始計算，這三年時間裡面資料庫例項的規模增加了接近5倍，所維護的資料庫伺服器規模增加了6.8倍，資料庫例項的單機部署密度增加了5倍以上，DBA人均運維的資料庫例項規模增加了14.9倍。

透過以上這些數字，我們發現近幾年vivo網際網路業務其實是處於高速發展的狀態，在高速發展的過程中無論是從使用者感受到的服務質量上來看還是從內部的成本效率來看，解決資料儲存的問題是迫在眉睫的事情，於是我們在2018年啟動了自研資料庫與儲存平臺的計劃，透過幾年時間的建設，我們初步具備了一些能力，現在就這些能力給大家做下簡單的介紹。

首先來整體對資料庫與儲存平臺產品做下介紹，主要分為2層。

• 第一層我們的資料庫和儲存產品，包括關係型資料，非關係型資料庫，儲存服務三大塊。

  
  

• 第二層主要是工具產品，包括提供資料庫和儲存統一管控的研發和運維平臺，資料傳輸服務，運維白屏化工具，還有一些SQL稽核，SQL最佳化，資料備份等產品。

工具產品主要以自研為主，下面一層的資料庫和儲存產品我們會優先選用成熟的開源產品，同時也會在開源產品的基礎上或者純自研一些產品用來更好的滿足業務發展，下面就部分產品的能力做下簡單的介紹。

DaaS平臺是Database as a Service的縮寫，該平臺旨在提供高度自助化、高度智慧化、高可用、低成本的資料儲存使用和管理的平臺，涵蓋了資料庫和儲存產品從服務申請、部署、維護直至下線的全生命週期，主要從四個方面為公司和使用者提供價值。

• 第四是降低資料庫和儲存產品的運營成本，首先透過自動化的流程減少DBA的重複工作，提高人效，其次透過服務編排和資源排程，提升資料庫和儲存服務的資源使用效率，持續降低運營成本。

透過幾年時間的建設，以上工作取得了一些進展，其中每月數以千計的需求工單，其中90%以上研發同學可以自助完成，服務可用性最近幾年都維持在4個9以上，平臺對6種資料庫產品和儲存服務的平臺化支援達到了85%以上，而且做到了同一能力的全資料庫場景覆蓋，比如資料變更，我們支援MySQL、ElastiSearch、MongoDB、TiDB的變更前語句審查，變更資料備份，變更操作一鍵回滾，變更記錄審計追蹤等。

vivo的DTS服務是基於自身業務需求完全自研的資料傳輸服務，主要提供RDBMS、NoSQL、OLAP等資料來源之間的資料互動。集資料遷移、訂閱、同步、備份的一體化服務，從功能上來看，主要有三個特性；

• 第一是同步鏈路的穩定性和資料可靠性保障，透過結合各個資料來源產品的自身特性可以做到資料不重不丟，給業務提供99.99%的服務可用性保障。

  
  

• 第二是功能層面支援異構的多種資料庫型別，除了同步、遷移、訂閱等這些通用功能外，我們還支援變更資料的集中化儲存和檢索。

  
  

• 第三是故障容災層面，支援節點級別故障容災，可以做到同步鏈路秒級恢復，也支援斷點續傳，可以有效的解決因硬體、網路等異常導致的傳輸中斷問題。

下面我們再來看看我們在底層資料儲存層做的一些專案，首先來看看MySQL資料庫。

MySQL作為最流行的資料庫，在vivo同樣承擔了關係型資料庫服務的重任，上圖的MySQL2.0是我們內部的架構版本，在這幾年時間裡面，我們的架構演化了2版。

第一版為了快速解決當時面臨的可用性問題，基於MHA+自研元件做了1.0版本。

目前已經演化到了2.0版本，MHA等元件依賴已經沒有了，從架構上看，2.0版本的服務接入層我們支援業務使用DNS或者名字服務接入，中間加入了一層自研的代理層Proxy，這一層做到了100%與MySQL語法和協議相容，在Proxy上面我們又實現了三級讀寫分離控制，流量管控，資料透明加密，SQL防火牆，日誌審計等功能。

Proxy層結合底層的高可用元件共同實現了MySQL叢集的自動化、手動故障轉移，透過RAFT機制保障了高可用管控元件自身的可用性，當然MySQL用的還是主從架構，在同地域可以跨IDC部署，跨地域同步可以用前面提到的DTS產品解決，跨地域多活目前還未支援，這塊屬於規劃中的3.0架構。

Redis作為非常流行和優秀的KV儲存服務，在vivo得到了大量的應用，在vivo網際網路的發展歷程中，有使用過單機版的Redis，也有使用過主從版本的Redis。到目前為止，已經全部升級到叢集模式，叢集模式的自動故障轉移，彈性伸縮等特性幫我們解決了不少問題。

但當單叢集規模擴大到TB級別和單叢集節點數擴充套件到500+以後還是存在很多問題，基於解決這些問題的訴求，我們在Redis上面做了一些改造開發，主要包括三部份：

• 第一是Redis Cluster的多機房可用性問題，為此我們研發了基於Redis Cluster的多活版本Redis。

  
  

• 第二是對Redis的資料持久化做了加強，包括AOF日誌改造，AEP硬體的引入，包括正在規劃中的Forkless RDB等。

  
  

• 第三是Redis同步和叢集模式的增強，包括非同步複製，檔案快取，水位控制等，還有對Redis Cluster指令的時間複雜度最佳化，Redis Cluster指令的時間複雜度曾經給我們的運維帶來了很多的困擾，透過演算法的最佳化，時間複雜度降低了很多，這塊的程式碼目前已經同步給社群。

我們在Redis上做了這些最佳化後，發現僅僅有記憶體型的KV儲存是無法滿足業務需要，未來還有更大的儲存規模需求，必須有基於磁碟的KV儲存產品來進行資料分流，對資料進行分層儲存，為此我們研發了磁碟KV儲存產品。

我們在啟動磁碟KV儲存服務研發專案時就明確了業務對儲存的基本訴求。

第一是是相容Redis協議，可以很方便的從原來使用Redis服務的專案中切換過來。

第二是儲存成本要低，儲存空間要大，效能要高，結合運維的一些基本訴求比如故障自動轉移，能夠快速的擴縮容等。

最終我們選擇了以TIKV作為底層儲存引擎實現的磁碟KV儲存服務，我們在上層封裝了Redis指令和Redis協議。其中選擇TIKV還有一個原因是我們整體的儲存產品體系中有使用到TiDB產品，這樣可以降低運維人員學習成本，能夠快速上手。

我們還開發了一系列周邊工具，比如Bulk load批次匯入工具，支援從大資料生態中匯入資料到磁碟KV儲存，資料備份還原工具，Redis到磁碟KV同步工具等，這些工具大大的降低了業務的遷移成本，目前我們的磁碟KV儲存產品已經在內部廣泛使用，支撐了多個TB級別的儲存場景。

我們知道業務執行過程中除了需要對一些結構化或者半結構化的資料有存取需求之外，還有大量的非結構化資料存取需求。vivo的物件與檔案儲存服務正是在這樣的背景下去建設的。

物件和檔案儲存服務使用統一的儲存底座，儲存空間可以擴充套件到EB級別以上，上層對外暴露的有標準物件儲存協議和POSIX檔案協議，業務可以使用物件儲存協議存取檔案、圖片、影片、軟體包等，標準的POSIX檔案協議可以使得業務像使用本地檔案系統一樣擴充套件自己的存取需求，比如HPC和AI訓練場景，可以支撐百億級別小檔案的GPU模型訓練。

針對圖片和影片檔案，還擴充套件了一些常用的圖片和影片處理能力，比如水印，縮圖、裁剪、截禎、轉碼等。前面簡單介紹了vivo資料庫與儲存平臺的一些產品能力，那麼下面我們再來聊聊在平臺建設過程中，我們對一些技術方向的探索和思考。

在平臺建設方面，運維研發效率提升是老生常談的話題，在業內也有很多建設得不錯的平臺和產品，但是關於資料儲存這塊怎麼提升運維研發效率講的比較少。

我們的理解是：

1. 首先是資源的交付要足夠的敏捷，要遮蔽足夠多的底層技術細節，為此我們將IDC自建資料庫、雲資料庫、雲主機自建資料庫進行雲上雲下統一管理，提供統一的操作檢視，降低運維和研發的使用成本。

   
   

2. 其次要提升效率就不能只關注生產環境，需要有有效的手段將研發、測試、預發、生產等多種環境統一管控起來，做到體驗統一，資料和許可權安全隔離。

   
   

3. 最後是我們運用DevOps解決方案的思想，將整個平臺邏輯上分為兩個域，一個是研發域，一個是運維域：

在研發域，我們需要思考如何解決研發同學關於資料庫和儲存產品的效率問題。交付一個資料庫例項和支援他們在平臺上可以建庫建表是遠遠不夠的，很多操作是發生在編碼過程中的，比如構造測試資料，編寫增刪改查的邏輯程式碼等等。

我們希望在這些過程中就和我們的平臺發生互動，最大程度的提升研發效率。

在運維域，我們認為目前有一個比較好的衡量指標就是日常運維過程中需要登入伺服器操作的次數，將運維的動作全部標準化、自動化，並且未來有一些操作可以智慧化。在研發和運維互動的部分，我們的建設目標是減少互動，流程中參與的人越少效率就越高，讓系統來做決策，實現的方案是做自助化。下面我們在看看安全這塊的一些探索和思考。

安全無小事，為此我們將資料庫安全和資料安全的部分單獨拿出來進行規劃和設計，基本的原則就是權責分明，資料庫體系涉及到賬號密碼等。

我們聯合SDK團隊共同研發了密碼加密傳輸使用方案，資料庫的密碼對研發、運維而言都是密文，在專案的配置檔案中依然是密文，使用時對接公司的金鑰管理系統進行解密。

針對資料的部分，我們聯合安全團隊對敏感資料做了自動標註識別，分類分級，對敏感資料的查詢、匯出、變更上做了嚴格的管控，比如許可權管控、許可權升級、透過數字水印技術進行使用追蹤，透過事後的審計可以追溯到誰在什麼時刻檢視了什麼資料。針對敏感資料我們也做了透明加解密操作，落盤到儲存介質的資料是經過加密儲存的。

同理，備份的資料和日誌也做了加密儲存，這些是目前我們做的事情，未來安全這塊還有很多的能力需要建設。下面我們再來看看變更這塊。

針對資料變更的場景，我們關注的主要有兩點；

1. 第一是資料變更本身會不會影響已有的業務，為此我們建設了不鎖表結構、不鎖表資料的變更能力，針對上線前、上線中、上線後三個環節設定三道防線。杜絕一些不好的SQL或者Query流入到生產環境，針對變更過程中或者變更結束後如果想回滾，我們也做了一鍵回滾方案。

   
   

2. 第二是變更效率問題，針對多個環境、多個叢集我們提供了一鍵同步資料變更方案，同時為了更好的提升使用者體驗，我們也提供了GUI的庫表設計平臺。有了這些基礎之後，我們將整個場景的能力全部開放給研發同學，現在研發同學可以24小時自助進行資料變更操作，極大的提升了變更效率。

接下來我們再介紹下成本這塊的一些思考。

關於成本這塊我們主要從四個方面進行管理；

1. 第一是預算的管控，資源去物理化，業務以資源為粒度進行預算提報，在預算管控層面對伺服器的消耗進行預測和不斷的修正，保證水位的健康。

   
   

2. 第二是資料庫服務的部署，這塊我們經歷了幾個階段，最早期是單機單例項，浪費了很多資源，後面發展為標準化套餐部署，同一型別的儲存資源不同的套餐混合，透過演算法的最佳化不斷的提升資源的使用效率。

   
   

3. 第三是我們做了一系列不同屬性資源的混合部署，比如資料庫的代理層和物件儲存的資料節點混合部署，這兩種資源一個是CPU型的，一個是儲存型的，正好可以互補，再往後發展的下一個階段應該是雲原生儲存計算分離，還在探索中。

   
   

4. 第四是服務部署之後還需要不斷的關注執行中的狀況，對容量做巡檢和預警，對叢集及時的做升降配操作，保障整個執行狀態有序。同時需要關注業務執行狀態，及時回收下線資料儲存叢集，減少殭屍叢集的存在。

成本這塊還有一點就是硬體資源的迭代，這塊也很關鍵，這裡就不做過多的介紹。然後我們再來看下儲存服務體系這塊。

物件與檔案儲存這塊我們主要關注的是兩個點；

• 第一個是成本，關於成本這塊我們在資料冗餘策略這塊使用了EC，並且做了跨IDC的EC，單個IDC全部故障也不會影響我們的資料可靠性。我們還引入了高密度大容量儲存伺服器，儘可能多的提升單機架儲存密度，需要注意的是伺服器採購之後的執行成本也不可忽視，依然有很大的最佳化空間。我們還提供了資料無損和透明壓縮的能力和生命週期管理的能力，及時清理過期資料和對冷資料進行歸檔。透過多種手段持續降低儲存成本。

  
  

• 第二是效能，關於效能這塊我們提供了桶&物件粒度底層儲存引擎IO隔離，透過引入一些開源元件如alluxio等提供了服務端+客戶端快取，提升熱點資料讀取效能，在底層儲存引擎這塊我們引入了opencas和IO_URING技術，進一步提升整機的磁碟IO吞吐。

以上就是我們目前在建設的能力的一些探索和思考，最後再來看下我們未來的規劃。

在整個儲存服務層，我們會不斷的完善儲存服務矩陣，打磨產品，提供更多元的儲存產品，更好的滿足業務發展訴求。同時在儲存服務層會基於現有儲存產品做一些SAAS服務來滿足更多的業務訴求。在功能層，我們拆解為4部分：

• 資料基礎服務，這部分提供儲存產品基本功能，包括部署、擴縮容、遷移、監控告警、備份恢復，下線回收等等。

• 資料服務，儲存產品本質上是儲存資料的載體，針對資料本身我們也有一些規範，最基本的比如資料的查詢變更效能最佳化，資料治理和如何深入到業務編碼過程中去。

• 儲存自治服務，初步劃分為效能自治、容量自治、智慧診斷、場景服務四大塊，透過自治服務一方面可以提升DBA工作的幸福感，一方面也可以大大的提升我們系統本身的健壯性和穩定性。

• 資料安全服務，目前雖然建設了一些能力，但是不夠體系，未來還需要加大投入。

未來整個儲存服務體系會融入到公司整體的混合雲架構中，給使用者提供一站式和標準化的體驗。以上就是分享的全部內容。