平安雲原生資料庫開發與實踐

　 摘要：TiDB作為開源分散式關係型資料庫，具備良好的擴充套件性，結合雲環境靈活的基礎設施，可以充分發揮分散式資料庫的優勢。至於，為什麼TiDB一定要上雲？雲原生資料庫改造之前最大的挑戰是什麼？平安科技給出的答案是效率、成本和故障自愈需求！那麼，在上雲過程中，TiDB使用了哪些關鍵元件？如何在K8S上有效管理TiDB叢集？如何充分利用雲環境穩定執行TiDB？TiDB上雲後如何提供更好的使用者體驗？本文結合平安科技實際業務環境，具體介紹了開發與應用實踐過程！

　　本期分享嘉賓：平安科技資深研發工程師 宋歌

　　簡介： 平安科技研發工程師，熟悉Kubernetes contributor、TiDB contributor，熱愛開源，同時也是《TiDB in action》作者之一。

　　雲原生時代，以Kubernetes為代表的編排系統成為新應用的事實標準，甚至被稱為是提升開發效率的“殺手鐧”級應用，其無狀態的彈性伸縮以及自動故障轉移能力，無疑實現了生產力的又一次解放。

　　事實上，狀態本身從未消失，而是下沉到底層的資料庫、物件儲存等有狀態的應用上。那麼，以TiDB為代表的有狀態應用，如何在“負重前行”過程中，充分利用雲以及Kubernetes的潛力，獲得進一步的成功呢？平安科技總結出的關於TiDB與Kubernetes的“愛恨情仇”，或許能為更多企業的雲原生實踐帶來參考和借鑑意義！

　 　分散式資料庫TiDB技術回顧

　　2018年，平安科技開始使用TiDB；2019年首次完成了線上業務部署。2019年以後，平安科技開始著手實現TiDB的上雲。2021年，平安科技推出了UbiSQL雲原生分散式資料庫。

　　之所以要引入TiDB，主要是為了支援平安集團重大業務活動——平安1.8財神節。在短短10天活動高峰期，TiDB平穩地度過了活動大促。活動中，TiDB表現出卓越的延展性，可以支援快速擴縮容，實現業務峰值的覆蓋。

　　眾所周知，TiDB是一款開源分散式NewSQL資料庫服務，源於谷歌釋出的Spanner，支援OLTP和OLAP；同時，TiDB在橫向擴充套件能力上，具有非常強的水平擴充套件能力，這是天然架構上的優勢；TiDB支援分散式事務，高度相容MySQL5.7協議，是HTAP交易分析混合型應用，適用於海量資料儲存、高併發、高吞吐、高增速的業務場景，能使遷移成本降到極低。

　 　為什麼TiDB需要上雲？

　　TiDB為什麼要上雲？運維成本是最大挑戰！

　　當時，叢集管理非常多，運維效率難以滿足使用者的交付時效。而從故障自愈的角度看，傳統環境難以實現自動化。比如：當一個伺服器掛掉以後，其實服務能力是受損的狀態，需要DBA晚上爬起來去看這個問題怎麼解決。如果業務晚上有高峰，還要新建一個例項去擴容，這些都需要去手動操作。

　　上雲自動化以後，對使用者來說最直接的感受就是成本和效率。在傳統環境去部署TiDB的時候，比較碎片化，管理成本較高，透過配置指令碼做自動化部署，缺少對整個叢集狀態的維護和自動管理能力，也很難做資源排程，並且資源排程依賴於外部的演算法或者框架來做。另外，傳統環境很難實現故障自愈、彈性服務；但是上雲以後，資料庫例項超過一定時間沒有響應後，Operator會幫你把新的節點自動拉起來，提供資料庫服務故障自愈能力。而從使用者應用交付來看，我們原來從準備資源到到交付一套生產叢集可能需要數天時間，因為需要申請伺服器，還需要規劃一些埠；而上雲以後的交付時效是分鐘級別，這是非常明顯的使用者體驗上的提升。

　　基於上述幾點因素，TiDB上雲成為最佳選擇！

　　在雲化過程中，我們用了TiDB Operator這個元件，同時做了一些二次開發，在K8S叢集上去交付一套TiDB容器化的叢集，可以很好地將資源利用率提高到一個比較高的水平。在傳統環境下，需要人工去管理資源，比如：透過粗糙的資源演算法去管理，資源利用率比較低；而云化以後，可統一管理資源池，透過K8s編排和排程充分利用主機資源，使主機資源使用率得到大幅提升。同時，雲上是使用容器化的方式去部署的，節點失效了以後可以由Controller自動拉起，很好地做到節點的容災，確保節點在一臺主機掛掉以後，在其他節點或者計算層可以維持副本數量。

　　尤為重要的是，TiDB上雲把所有的TiDB叢集做了集約化管理以後，可以很明顯看到規模效應。分散式資料庫叢集元件很多，節點也很多，管理大量叢集的時候，會導致資訊管理成本、叢集的管理成本、運維成本陡然上升，而把所有的叢集進行集中化管理後會產生規模效應。TiDB上雲以後，可以有效降低每套叢集的邊際管理成本。

　　換言之，管理的叢集越多，每個節點所需要消耗的技術、人力成本就越少。同時，集約化管理還帶來另一個好處，集團各公司使用者可以共享技術紅利。我們在做程式碼的提升時，釋出了新的功能，比如：快速備份、基於時間點恢復、引數調優等，都可以在雲上集約化管理方式下，把技術能力提供給被託管叢集，最終效果就是降本增效。

　　如何在雲上管理TiDB叢集？

　　那麼，我們如何在K8S叢集上管理TiDB叢集呢？大概構建了以下5個核心能力！

　　自動化部署。首先，使用TiDB Operator做了一些二次開發，實現了一些雲上自動化的管理能力。比如：自動化交付，讓使用者在平安雲介面上一鍵點選，建立叢集，選擇規格、例項，然後選擇儲存的空間大小，自動在後端建立TiDB叢集，交付這個叢集。

　　2．滾動升級。TiDB社群版的升級頻率非常高，前幾年，大概一個半月，就升級一個小版本。所以，線上上，我們也會有一些碎片化的小版本，在做滾動升級的時候， DBA可以在運維時間段，將叢集做一個小版本的一個升級，目前可以做到一鍵滾動升級。

　　3．備份管理。基本做到了全量備份、增量備份、全量恢復、按時間點恢復（PITR）。

　　4. 引數管理。DBA可以在平安雲頁面上做引數配置，同時這個引數配置可以記錄你的引數修改歷史，給你一些預設引數；並且，根據不同的套餐給你一些預設的引數。你去修改調整以後，會記錄誰什麼時候修改的什麼東西。並且，還有可以修改引數的時間段，設定控制引數生效規則，比如：不要在業務高峰期調整這個引數，然後由使用者在頁面上配置。

　　5. 使用者管理。目前，主要針對集團內部子公司，對於資料庫的使用者管理有一些管理規範，結合內部系統的一些建設規範和審批流程，透過審批以後按照規範去建立使用者的功能。

　 　如何充分利用雲環境穩定執行TiDB？

　　第一，容器網路。使用了K8S比較常見的Calico作為網路外掛，相比Flannel的好處在於，可以在網路層面透過BGP的方式實現容器網路互連，避免overlay 模型隧道開銷。另外，我們還在驗證基於自研的K8S網路外掛實現靜態IP的網路方案。

　　第二，Load Balancer。資料庫例項增加後，業務訪問的時候就需要一個負載均衡，目前我們使用了K8S的Service 作為它的一個負載均衡；同時，在做灰度升級、滾動升級的時候，利用了負載均衡的標籤選擇能力，來做流量的控制。

　　第三，Service Discovery。基於DNS實現服務自動發現。所謂“服務發現”，在搭建PD的時候，要去配置一些靜態節點。PD有幾種叢集搭建方式，一種是配置一個靜態的叢集，各節點相互知道其他節點IP。也可以基於服務發現機制，節點自動組建叢集。採用服務發現的好處是，叢集的規模比較靈活，比較容易做一個動態的叢集，而非採用靜態的方式。

　　第四，Backup&Restore。基於社群工具和物件儲存實現備份恢復資料。之前備份恢復功能，基於MySQL、Lightning做TiDB層的資料備份和恢復，Lightning還涉及寫KV。而Backup&Restore工具直接從KV層備份資料。由於是在每個TiKV節點上直接備份，所以還可以支援更高的併發和吞吐。並且避免計算層的SQL解析，恢復速度也比較快。目前來看，這個工具很快，我們整合了Backup&Restore工具。同時，可以基於雲備份到物件儲存，再從物件儲存做資料恢復。

　　另外使用者更多關心採用容器化以後，如何確保穩定性，如何在一個複雜的系統裡使用一個新的技術，讓整個系統變得更好而非更糟糕。

　　這裡有幾項相對來說比較智慧化的技術：

　　Automatic Failover。相當於你的TiKV本身具備故障自愈能力，假設指定了三個副本，當Operator檢測到有個副本掛掉了，超過30分鐘沒有恢復，他就會做一個故障的自愈，這是傳統的Ansible沒有的特性，是TiDB Operator獨有的一個特性，這也是基於雲帶來的一個好處。假設有三個副本，有一個副本做了健康檢查失敗了，時間已經超過30分鐘，就會自動恢復一個新的副本。不用管原來的副本了，這個時候依然保持彈性的服務能力。當然，等待故障節點恢復了以後，會有一個超出期望的4個副本，這個時候DBA再去根據故障情況去判斷，要不要把新增的副本下線掉。當然，這個30分鐘的限制，也是Operator自身的一個引數，可以配置多長時間以後Operator才能新建節點。

　　Auto-scaling，結合Prometheus、TiDB的Pod及K8S的HPA能力，基於Metrics的一些關鍵指標，實現例項節點的擴容。當我們發現節點、業務特別繁忙的時候，會基於資源池進行擴容。使用者可以指定擴容規則，比如最大的擴容上線，擴容的等待時間，可以有在使用者端的頁面按需設定。同時，有擴容就會有縮容策略，比如：有一個冷卻的時間，超過這個時間以後，關鍵指標沒有達到縮容的最低值，管控元件就自動縮容，告訴這個程式結束了，資料庫會終止接受新的會話，並把當前會話進行處理完成，不會出現事務長時間的等待，超過等待時間被清除的情況。

　　Self-Driving，資料庫叢集整體有波動、有異常，如何把異常平滑地處理掉？透過監控、日誌等自動地分析和識別引數，可以透過Self-Driving來實現。

　 　TiDB上雲後如何獲得更好的使用者體驗？

　　一般情況下，DBA比較習慣在Linux裡面去維護資料庫，比如檢視日誌，但在分散式系統裡很麻煩，因為需要登入到各個節點去看不同的路徑，所以上雲之後我們就接入了一些雲本身的能力，包括集中日誌管理，我們內部叫日誌雲，把K8S Pod上的日誌等集中收集上來，然後在另外的產品頁面裡去做一些關鍵字的過濾、分析等。

　　另外，就是統一的監控頁面，方便DBA做更好的分析，幫助使用者做資料庫效能的分析。該能力可以基於雲平臺的產品頁面去新增，包括可以擴縮容，調整購買規格，調整付費方式，比如預付費還是按量付費等。

　　最後，雲原生資料庫也是一個持續演進的過程，為了讓應用效能達到最佳，我們在底層技術支撐方面也在做一些新的探索，進行持續發力。

　　1、 縱向擴縮容（VPA）。我們在2021年推出的UbiSQL分散式資料庫，在這方面在做進一步的探索，比如：如何基於例項進行縱向擴縮容（VPA）。原來的CPU有限定，但業務突然遇到高峰期，如果是水平擴容，首先能力和時間有限；另外，水平擴容有些大的SQL在單個例項上還是有瓶頸。於是套餐的規格需要擴大，在應用不用重啟的情況下，原地增加可用資源限制，然後再去做縱向的套餐規格的擴容。

　　2、 異構叢集（ Heterogeneous Cluster ）。儲存節點在擴縮容的時候，包括底層儲存，每個TiKV對應的儲存塊不一樣，我們在構建叢集的時候，允許加入不同的記憶體、CPU還有儲存磁碟的比例，整個TiKV允許他有不同磁碟每一個塊的比例。同時，異構叢集還有一個特性，就是可以隔離AP和TP的請求。比如：有個做資料中臺的業務找過來，有些業務是交易型，希望打在某個節點上；另外，有些業務是分析型的，希望打在另外的計算節點上，並且這些節點資源規格是不一樣的，如何把這塊功能以產品化的形式提供給使用者，也是我們目前在做的事情。

　　3、 資料庫自治能力（ Database Autonomy ）。我們也在做一些資料庫自治探索。首先，構建資料庫治理體系，因為治理體系是資料庫自治的關鍵路徑，先有一個治理的過程，有資料、有治理能力。接下來，再根據資料和治理能力再去做自動化，包括基於資料的分析、引數的調優。

　　TiDB可以最佳化的引數非常多，加上分散式架構元件，兩者結合起來調優過程就非常複雜。而資料庫自治可以解決很多問題。首先是，引數調優，根據不同的環境和業務負載，可以把資料庫的一些引數調整到相對較好的狀態。因為交付的叢集都是預設的引數，這些引數要麼是基於專家模型，專家覺得這個套餐能面向80%的業務，都在用這個引數，那就用這樣的。但是，叢集交付了以後，部分引數可以根據實際業務負載特性進行適當調整。我們透過資料庫自治可以把引數調優變成一個自動化的過程。

　　然後是，積累下來的慢日誌資料如何去最佳化？過去，很多日誌資料都是基於人工的經驗去做分析，我們希望把慢日誌的分析能力自動化。現在，這些能力都依賴於所使用的基礎設施，先把所有慢日誌採集下來，然後再根據專家模型轉化成自動化過程。

　　4、使用新型硬體最佳化KV儲存（KVSSD）。將Rocksdb整合到SSD硬體中，從而直接使用硬體KV介面能力，上層應用原來需要透過Rocksdb訪問SSD硬體。而現在硬體廠商直接就把KV能力整合到硬體中，類似於存算一體的硬體，可以顯著提升SSD的KV讀寫效能。

　　總之，TiDB能超越傳統資料庫，讓資料發揮更大價值，與容器相關的關鍵元件發揮了重要作用，而從雲原生資料庫設計的未來發展來看，還有更多可能性以及更大的探索空間！