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

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

摘要：TiDB作為開源分布式關(guān)系型數(shù)據(jù)庫，具備良好的擴展性，結(jié)合云環(huán)境靈活的基礎(chǔ)設(shè)施，可以充分發(fā)揮分布式數(shù)據(jù)庫的優(yōu)勢。至于，為什么TiDB一定要上云?云原生數(shù)據(jù)庫改造之前最大的挑戰(zhàn)是什么?平安科技給出的答案是效率、成本和故障自愈需求!那么，在上云過程中，TiDB使用了哪些關(guān)鍵組件?如何在K8S上有效管理TiDB集群?如何充分利用云環(huán)境穩(wěn)定運行TiDB?TiDB上云后如何提供更好的用戶體驗?本文結(jié)合平安科技實際業(yè)務(wù)環(huán)境，具體介紹了開發(fā)與應(yīng)用實踐過程!

云原生時代，以Kubernetes為代表的編排系統(tǒng)成為新應(yīng)用的事實標準，甚至被稱為是提升開發(fā)效率的“殺手锏”級應(yīng)用，其無狀態(tài)的彈性伸縮以及自動故障轉(zhuǎn)移能力，無疑實現(xiàn)了生產(chǎn)力的又一次解放。

事實上，狀態(tài)本身從未消失，而是下沉到底層的數(shù)據(jù)庫、對象存儲等有狀態(tài)的應(yīng)用上。那么，以TiDB為代表的有狀態(tài)應(yīng)用，如何在“負重前行”過程中，充分利用云以及Kubernetes的潛力，獲得進一步的成功呢?平安科技總結(jié)出的關(guān)于TiDB與Kubernetes的“愛恨情仇”，或許能為更多企業(yè)的云原生實踐帶來參考和借鑒意義!

分布式數(shù)據(jù)庫TiDB技術(shù)回顧

2018年，平安科技開始使用TiDB;2019年首次完成了線上業(yè)務(wù)部署。2019年以后，平安科技開始著手實現(xiàn)TiDB的上云。2021年，平安科技推出了UbiSQL云原生分布式數(shù)據(jù)庫。

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

眾所周知，TiDB是一款開源分布式NewSQL數(shù)據(jù)庫服務(wù)，源于谷歌發(fā)布的Spanner，支持OLTP和OLAP;同時，TiDB在橫向擴展能力上，具有非常強的水平擴展能力，這是天然架構(gòu)上的優(yōu)勢;TiDB支持分布式事務(wù)，高度兼容MySQL5.7協(xié)議，是HTAP交易分析混合型應(yīng)用，適用于海量數(shù)據(jù)存儲、高并發(fā)、高吞吐、高增速的業(yè)務(wù)場景，能使遷移成本降到極低。

為什么TiDB需要上云?

TiDB為什么要上云?運維成本是最大挑戰(zhàn)!

當時，集群管理非常多，運維效率難以滿足用戶的交付時效。而從故障自愈的角度看，傳統(tǒng)環(huán)境難以實現(xiàn)自動化。比如：當一個服務(wù)器掛掉以后，其實服務(wù)能力是受損的狀態(tài)，需要DBA晚上爬起來去看這個問題怎么解決。如果業(yè)務(wù)晚上有高峰，還要新建一個實例去擴容，這些都需要去手動操作。

上云自動化以后，對用戶來說最直接的感受就是成本和效率。在傳統(tǒng)環(huán)境去部署TiDB的時候，比較碎片化，管理成本較高，通過配置腳本做自動化部署，缺少對整個集群狀態(tài)的維護和自動管理能力，也很難做資源調(diào)度，并且資源調(diào)度依賴于外部的算法或者框架來做。另外，傳統(tǒng)環(huán)境很難實現(xiàn)故障自愈、彈性服務(wù);但是上云以后，數(shù)據(jù)庫實例超過一定時間沒有響應(yīng)后，Operator會幫你把新的節(jié)點自動拉起來，提供數(shù)據(jù)庫服務(wù)故障自愈能力。而從用戶應(yīng)用交付來看，我們原來從準備資源到到交付一套生產(chǎn)集群可能需要數(shù)天時間，因為需要申請服務(wù)器，還需要規(guī)劃一些端口;而上云以后的交付時效是分鐘級別，這是非常明顯的用戶體驗上的提升。

基于上述幾點因素，TiDB上云成為最佳選擇!

在云化過程中，我們用了TiDB Operator這個組件，同時做了一些二次開發(fā)，在K8S集群上去交付一套TiDB容器化的集群，可以很好地將資源利用率提高到一個比較高的水平。在傳統(tǒng)環(huán)境下，需要人工去管理資源，比如：通過粗糙的資源算法去管理，資源利用率比較低;而云化以后，可統(tǒng)一管理資源池，通過K8s編排和調(diào)度充分利用主機資源，使主機資源使用率得到大幅提升。同時，云上是使用容器化的方式去部署的，節(jié)點失效了以后可以由Controller自動拉起，很好地做到節(jié)點的容災(zāi)，確保節(jié)點在一臺主機掛掉以后，在其他節(jié)點或者計算層可以維持副本數(shù)量。

尤為重要的是，TiDB上云把所有的TiDB集群做了集約化管理以后，可以很明顯看到規(guī)模效應(yīng)。分布式數(shù)據(jù)庫集群組件很多，節(jié)點也很多，管理大量集群的時候，會導(dǎo)致信息管理成本、集群的管理成本、運維成本陡然上升，而把所有的集群進行集中化管理后會產(chǎn)生規(guī)模效應(yīng)。TiDB上云以后，可以有效降低每套集群的邊際管理成本。

換言之，管理的集群越多，每個節(jié)點所需要消耗的技術(shù)、人力成本就越少。同時，集約化管理還帶來另一個好處，集團各公司用戶可以共享技術(shù)紅利。我們在做代碼的提升時，發(fā)布了新的功能，比如：快速備份、基于時間點恢復(fù)、參數(shù)調(diào)優(yōu)等，都可以在云上集約化管理方式下，把技術(shù)能力提供給被托管集群，最終效果就是降本增效。

如何在云上管理TiDB集群?

那么，我們?nèi)绾卧贙8S集群上管理TiDB集群呢?大概構(gòu)建了以下5個核心能力!

自動化部署。首先，使用TiDB Operator做了一些二次開發(fā)，實現(xiàn)了一些云上自動化的管理能力。比如：自動化交付，讓用戶在平安云界面上一鍵點擊，創(chuàng)建集群，選擇規(guī)格、實例，然后選擇存儲的空間大小，自動在后端創(chuàng)建TiDB集群，交付這個集群。

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

3.備份管理。基本做到了全量備份、增量備份、全量恢復(fù)、按時間點恢復(fù)(PITR)。

4. 參數(shù)管理。DBA可以在平安云頁面上做參數(shù)配置，同時這個參數(shù)配置可以記錄你的參數(shù)修改歷史，給你一些默認參數(shù);并且，根據(jù)不同的套餐給你一些默認的參數(shù)。你去修改調(diào)整以后，會記錄誰什么時候修改的什么東西。并且，還有可以修改參數(shù)的時間段，設(shè)置控制參數(shù)生效規(guī)則，比如：不要在業(yè)務(wù)高峰期調(diào)整這個參數(shù)，然后由用戶在頁面上配置。

5. 用戶管理。目前，主要針對集團內(nèi)部子公司，對于數(shù)據(jù)庫的用戶管理有一些管理規(guī)范，結(jié)合內(nèi)部系統(tǒng)的一些建設(shè)規(guī)范和審批流程，通過審批以后按照規(guī)范去創(chuàng)建用戶的功能。

如何充分利用云環(huán)境穩(wěn)定運行TiDB?

第一，容器網(wǎng)絡(luò)。使用了K8S比較常見的Calico作為網(wǎng)絡(luò)插件，相比Flannel的好處在于，可以在網(wǎng)絡(luò)層面通過BGP的方式實現(xiàn)容器網(wǎng)絡(luò)互連，避免overlay 模型隧道開銷。另外，我們還在驗證基于自研的K8S網(wǎng)絡(luò)插件實現(xiàn)靜態(tài)IP的網(wǎng)絡(luò)方案。

第二，Load Balancer。數(shù)據(jù)庫實例增加后，業(yè)務(wù)訪問的時候就需要一個負載均衡，目前我們使用了K8S的Service 作為它的一個負載均衡;同時，在做灰度升級、滾動升級的時候，利用了負載均衡的標簽選擇能力，來做流量的控制。

第三，Service Discovery。基于DNS實現(xiàn)服務(wù)自動發(fā)現(xiàn)。所謂“服務(wù)發(fā)現(xiàn)”，在搭建PD的時候，要去配置一些靜態(tài)節(jié)點。PD有幾種集群搭建方式，一種是配置一個靜態(tài)的集群，各節(jié)點相互知道其他節(jié)點IP。也可以基于服務(wù)發(fā)現(xiàn)機制，節(jié)點自動組建集群。采用服務(wù)發(fā)現(xiàn)的好處是，集群的規(guī)模比較靈活，比較容易做一個動態(tài)的集群，而非采用靜態(tài)的方式。

第四，Backup&Restore。基于社區(qū)工具和對象存儲實現(xiàn)備份恢復(fù)數(shù)據(jù)。之前備份恢復(fù)功能，基于MySQL、Lightning做TiDB層的數(shù)據(jù)備份和恢復(fù)，Lightning還涉及寫KV。而Backup&Restore工具直接從KV層備份數(shù)據(jù)。由于是在每個TiKV節(jié)點上直接備份，所以還可以支持更高的并發(fā)和吞吐。并且避免計算層的SQL解析，恢復(fù)速度也比較快。目前來看，這個工具很快，我們集成了Backup&Restore工具。同時，可以基于云備份到對象存儲，再從對象存儲做數(shù)據(jù)恢復(fù)。

另外用戶更多關(guān)心采用容器化以后，如何確保穩(wěn)定性，如何在一個復(fù)雜的系統(tǒng)里使用一個新的技術(shù)，讓整個系統(tǒng)變得更好而非更糟糕。

這里有幾項相對來說比較智能化的技術(shù)：

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

Auto-scaling，結(jié)合Prometheus、TiDB的Pod及K8S的HPA能力，基于Metrics的一些關(guān)鍵指標，實現(xiàn)實例節(jié)點的擴容。當我們發(fā)現(xiàn)節(jié)點、業(yè)務(wù)特別繁忙的時候，會基于資源池進行擴容。用戶可以指定擴容規(guī)則，比如最大的擴容上線，擴容的等待時間，可以有在用戶端的頁面按需設(shè)置。同時，有擴容就會有縮容策略，比如：有一個冷卻的時間，超過這個時間以后，關(guān)鍵指標沒有達到縮容的最低值，管控組件就自動縮容，告訴這個進程結(jié)束了，數(shù)據(jù)庫會終止接受新的會話，并把當前會話進行處理完成，不會出現(xiàn)事務(wù)長時間的等待，超過等待時間被清除的情況。

Self-Driving，數(shù)據(jù)庫集群整體有波動、有異常，如何把異常平滑地處理掉?通過監(jiān)控、日志等自動地分析和識別參數(shù)，可以通過Self-Driving來實現(xiàn)。

TiDB上云后如何獲得更好的用戶體驗?

一般情況下，DBA比較習(xí)慣在Linux里面去維護數(shù)據(jù)庫，比如查看日志，但在分布式系統(tǒng)里很麻煩，因為需要登錄到各個節(jié)點去看不同的路徑，所以上云之后我們就接入了一些云本身的能力，包括集中日志管理，我們內(nèi)部叫日志云，把K8S Pod上的日志等集中收集上來，然后在另外的產(chǎn)品頁面里去做一些關(guān)鍵字的過濾、分析等。

另外，就是統(tǒng)一的監(jiān)控頁面，方便DBA做更好的分析，幫助用戶做數(shù)據(jù)庫性能的分析。該能力可以基于云平臺的產(chǎn)品頁面去添加，包括可以擴縮容，調(diào)整購買規(guī)格，調(diào)整付費方式，比如預(yù)付費還是按量付費等。

最后，云原生數(shù)據(jù)庫也是一個持續(xù)演進的過程，為了讓應(yīng)用性能達到最佳，我們在底層技術(shù)支撐方面也在做一些新的探索，進行持續(xù)發(fā)力。

1、 縱向擴縮容(VPA)。我們在2021年推出的UbiSQL分布式數(shù)據(jù)庫，在這方面在做進一步的探索，比如：如何基于實例進行縱向擴縮容(VPA)。原來的CPU有限定，但業(yè)務(wù)突然遇到高峰期，如果是水平擴容，首先能力和時間有限;另外，水平擴容有些大的SQL在單個實例上還是有瓶頸。于是套餐的規(guī)格需要擴大，在應(yīng)用不用重啟的情況下，原地增加可用資源限制，然后再去做縱向的套餐規(guī)格的擴容。

2、 異構(gòu)集群( Heterogeneous Cluster )。存儲節(jié)點在擴縮容的時候，包括底層存儲，每個TiKV對應(yīng)的存儲塊不一樣，我們在構(gòu)建集群的時候，允許加入不同的內(nèi)存、CPU還有存儲磁盤的比例，整個TiKV允許他有不同磁盤每一個塊的比例。同時，異構(gòu)集群還有一個特性，就是可以隔離AP和TP的請求。比如：有個做數(shù)據(jù)中臺的業(yè)務(wù)找過來，有些業(yè)務(wù)是交易型，希望打在某個節(jié)點上;另外，有些業(yè)務(wù)是分析型的，希望打在另外的計算節(jié)點上，并且這些節(jié)點資源規(guī)格是不一樣的，如何把這塊功能以產(chǎn)品化的形式提供給用戶，也是我們目前在做的事情。

3、 數(shù)據(jù)庫自治能力( Database Autonomy )。我們也在做一些數(shù)據(jù)庫自治探索。首先，構(gòu)建數(shù)據(jù)庫治理體系，因為治理體系是數(shù)據(jù)庫自治的關(guān)鍵路徑，先有一個治理的過程，有數(shù)據(jù)、有治理能力。接下來，再根據(jù)數(shù)據(jù)和治理能力再去做自動化，包括基于數(shù)據(jù)的分析、參數(shù)的調(diào)優(yōu)。

TiDB可以優(yōu)化的參數(shù)非常多，加上分布式架構(gòu)組件，兩者結(jié)合起來調(diào)優(yōu)過程就非常復(fù)雜。而數(shù)據(jù)庫自治可以解決很多問題。首先是，參數(shù)調(diào)優(yōu)，根據(jù)不同的環(huán)境和業(yè)務(wù)負載，可以把數(shù)據(jù)庫的一些參數(shù)調(diào)整到相對較好的狀態(tài)。因為交付的集群都是默認的參數(shù)，這些參數(shù)要么是基于專家模型，專家覺得這個套餐能面向80%的業(yè)務(wù)，都在用這個參數(shù)，那就用這樣的。但是，集群交付了以后，部分參數(shù)可以根據(jù)實際業(yè)務(wù)負載特性進行適當調(diào)整。我們通過數(shù)據(jù)庫自治可以把參數(shù)調(diào)優(yōu)變成一個自動化的過程。

然后是，積累下來的慢日志數(shù)據(jù)如何去優(yōu)化?過去，很多日志數(shù)據(jù)都是基于人工的經(jīng)驗去做分析，我們希望把慢日志的分析能力自動化?，F(xiàn)在，這些能力都依賴于所使用的基礎(chǔ)設(shè)施，先把所有慢日志采集下來，然后再根據(jù)專家模型轉(zhuǎn)化成自動化過程。

4、使用新型硬件優(yōu)化KV存儲(KVSSD)。將Rocksdb集成到SSD硬件中，從而直接使用硬件KV接口能力，上層應(yīng)用原來需要通過Rocksdb訪問SSD硬件。而現(xiàn)在硬件廠商直接就把KV能力集成到硬件中，類似于存算一體的硬件，可以顯著提升SSD的KV讀寫性能。

總之，TiDB能超越傳統(tǒng)數(shù)據(jù)庫，讓數(shù)據(jù)發(fā)揮更大價值，與容器相關(guān)的關(guān)鍵組件發(fā)揮了重要作用，而從云原生數(shù)據(jù)庫設(shè)計的未來發(fā)展來看，還有更多可能性以及更大的探索空間!