vivo 數據庫與存儲平臺的建設和探索

作者：vivo 互聯網數據庫團隊 - Xiao Bo

本文根據 Xiao Bo 老師在 “2021 vivo 開發者大會 " 現場演講內容整理而成。公衆號回覆**【2021VDC】**獲取互聯網技術分會場議題相關資料。

一、數據庫與存儲平臺建設背景

圖片

以史爲鑑，可以知興替，做技術亦是如此，在介紹平臺之前，我們首先來一起回顧下 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 工作的幸福感，一方面也可以大大的提升我們系統本身的健壯性和穩定性。

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

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1y5rxSMh2xVL_RIKBAeWxw