近日，國內(nèi)領(lǐng)先的中立云計算服務(wù)商UCloud與國內(nèi)開源分布式NewSQL數(shù)據(jù)庫TiDB團(tuán)隊(duì)PingCAP正式達(dá)成合作，雙方聯(lián)手在UCloud全球數(shù)據(jù)中心推出了新一代TiDB的云端版本——Cloud TiDB。

作為一款定位于Cloud-native的數(shù)據(jù)庫，截至目前TiDB在云整合上已取得了階段性進(jìn)展。Cloud TiDB產(chǎn)品在UCloud平臺正式開啟公測，TiDB彈性伸縮特性在Cloud 提供的基礎(chǔ)設(shè)施支持下得到了淋漓盡致的展現(xiàn)。

在感受云數(shù)據(jù)庫魅力的同時，讓我們來探索一下TiDB與Cloud背后的技術(shù)秘密。

TiDB與傳統(tǒng)單機(jī)關(guān)系型數(shù)據(jù)庫的區(qū)別

首先，從TiDB的架構(gòu)說起。TiDB作為一款開源的分布式數(shù)據(jù)庫產(chǎn)品，具有多副本強(qiáng)一致性，能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對上層業(yè)務(wù)無感知。

TiDB的主體架構(gòu)包含三個模塊，對應(yīng)Github上PingCAP組織下的三個開源項(xiàng)目（TiDB / TiKV / PD）：

◆  TiDB主要是負(fù)責(zé)SQL的解析器和優(yōu)化器，它相當(dāng)于計算執(zhí)行層，同時也負(fù)責(zé)客戶端接入和交互；

◆  TiKV是一套分布式的Key-Value存儲引擎，它承擔(dān)整個數(shù)據(jù)庫的存儲層，數(shù)據(jù)水平擴(kuò)展和多副本高可用特性都在這一層實(shí)現(xiàn)；

◆  PD相當(dāng)于分布式數(shù)據(jù)庫的大腦，一方面負(fù)責(zé)收集和維護(hù)數(shù)據(jù)在各個TiKV節(jié)點(diǎn)的分布情況，另一方面PD承擔(dān)調(diào)度器的角色，根據(jù)數(shù)據(jù)分布狀況以及各個存儲節(jié)點(diǎn)的負(fù)載來采取合適的調(diào)度策略，維持整個系統(tǒng)的平衡與穩(wěn)定。

上述三個模塊中的每個角色都是一個多節(jié)點(diǎn)組成的集群，所以最終TiDB的架構(gòu)如下圖所示：

由此可見，分布式系統(tǒng)本身的復(fù)雜性不僅導(dǎo)致手工部署和運(yùn)維成本較高，而且容易出錯。傳統(tǒng)的自動化部署運(yùn)維工具（如：Puppet/Chef/SaltStack/Ansible等），由于缺乏狀態(tài)管理，在節(jié)點(diǎn)出現(xiàn)問題時不能及時自動完成故障轉(zhuǎn)移，需要運(yùn)維人員人工干預(yù)，有些則需要寫大量DSL甚至與Shell腳本一起混合使用，可移植性較差，維護(hù)成本比較高。

在云時代，容器成為應(yīng)用分發(fā)部署的基本單位，谷歌基于內(nèi)部使用數(shù)十年的容器編排系統(tǒng)Borg經(jīng)驗(yàn)，推出的開源容器編排系統(tǒng)Kubernetes就成為當(dāng)前容器編排技術(shù)的主流。

TiDB 與Kubernetes的深度整合

作為Cloud Native Database，TiDB選擇擁抱容器技術(shù)，并與Kubernetes進(jìn)行深度整合，使其可以非常方便地基于Kubernetes完成數(shù)據(jù)庫自動化管理。甚至可以說Kubernetes項(xiàng)目是為Cloud而生，利用云平臺IaaS層提供的API可以很方便地與云進(jìn)行整合。這樣只要讓TiDB與Kubernetes 結(jié)合得更好，進(jìn)而就能實(shí)現(xiàn)其與各個云平臺的整合，使TiDB在云上的快速部署和高效運(yùn)維成為現(xiàn)實(shí)。

◆  Kubernetes簡介

Kubernetes最早是作為一個純粹的容器編排系統(tǒng)而誕生，用戶部署好Kubernetes集群之后，直接使用其內(nèi)置的各種功能部署應(yīng)用服務(wù)。由于這個PaaS平臺使用起來非常便利，吸引了很多用戶，不同用戶也提出了各種不同需求，有些特性需求Kubernetes 可直接在其核心代碼里實(shí)現(xiàn)，但有些特性并不適合合并到主干分支。

為了滿足這類需求，Kubernetes開放出一些API供用戶自己擴(kuò)展，實(shí)現(xiàn)自身需求。當(dāng)前Kubernetes已經(jīng)升級到v1.8版本，內(nèi)部API變得越來越開放，使其更像是一個跑在云上的操作系統(tǒng)。用戶可以把它當(dāng)作一套云的SDK或Framework來使用，而且可以很方便地開發(fā)組件來擴(kuò)展?jié)M足自身業(yè)務(wù)需求，對有狀態(tài)服務(wù)的支持就是一個代表性實(shí)例。

在最早期，Kubernetes 項(xiàng)目只支持無狀態(tài)服務(wù)(Stateless Service) 來管理，無狀態(tài)服務(wù)通過ReplicationController定義多個副本，由Kubernetes調(diào)度器來決定在不同節(jié)點(diǎn)上啟動多個Pod，實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。對于無狀態(tài)服務(wù)，多個副本對應(yīng)的 Pod是等價的，所以當(dāng)節(jié)點(diǎn)出現(xiàn)故障時，在新節(jié)點(diǎn)上啟動一個Pod與失效的Pod是等價的，不會涉及狀態(tài)遷移問題，因而管理非常簡單。

◆  有狀態(tài)服務(wù)Stateful Service

不過，對于有狀態(tài)服務(wù) (Stateful Service)，由于需要將數(shù)據(jù)持久化到磁盤，使得不同Pod之間不能再認(rèn)為成等價，也就不能再像無狀態(tài)服務(wù)那樣隨意地進(jìn)行調(diào)度遷移。Kubernetes v1.3版本提出PetSet的概念，用來管理有狀態(tài)服務(wù)并在v1.5版本中將其更名為StatefulSet。

StatefulSet明確定義了一組Pod中的每個身份，啟動和升級都按特定順序來操作。另外，使用持久化卷存儲(PersistentVolume)來作為存儲數(shù)據(jù)的載體，當(dāng)節(jié)點(diǎn)失效 Pod需要遷移時，對應(yīng)的PV通過umount/mount方式跟著一起遷移到新節(jié)點(diǎn)，或者直接使用分布式文件系統(tǒng)作PV底層存儲，使Pod在遷移后仍然能訪問到之前的數(shù)據(jù)。

同時，Pod在發(fā)生遷移時，其網(wǎng)絡(luò)身份（例如IP地址）是會發(fā)生變化的，很多分布式系統(tǒng)不能接受這種情況，所以StatefulSet在遷移Pod時可以通過綁定域名的方式來保證Pod在集群中網(wǎng)絡(luò)身份不發(fā)生變化。

然而，現(xiàn)實(shí)中一些分布式系統(tǒng)更為復(fù)雜，StatefulSet也顯得捉襟見肘。舉例來說，某些分布式系統(tǒng)的節(jié)點(diǎn)在加入集群或下線時，還需要做些額外的注冊和清理操作，或者在滾動升級時，要考量版本兼容性等問題。

基于上述原因，CoreOS公司提出了Operator概念，并實(shí)現(xiàn)了etcd-operator和prometheus-operator來管理Etcd和Prometheus這樣復(fù)雜的分布式系統(tǒng)。用戶可以開發(fā)自己的Operator，在Kubernetes之上實(shí)現(xiàn)自定義的Controller，將有狀態(tài)服務(wù)領(lǐng)域中特定的運(yùn)維知識編碼進(jìn)去，從而實(shí)現(xiàn)對特定分布式系統(tǒng)的管理。同時，Operator本身也是跑在Kubernetes中的一個Pod（deployment），對Kubernetes系統(tǒng)并無侵入性。

◆  TiDB多組件支持

針對TiDB這種復(fù)雜的分布式服務(wù)，我們開發(fā)了tidb-operator等一系列組件，來管理 TiDB集群實(shí)例在Kubernetes平臺上的創(chuàng)建、銷毀、擴(kuò)縮容、滾動升級和故障轉(zhuǎn)移等運(yùn)維操作。同時，在上層封裝了一個tidb-cloud-manager組件，提供RESTful接口，實(shí)現(xiàn)了與云平臺的控制臺打通功能。這就完成了一個DBaaS（數(shù)據(jù)庫即服務(wù)）架構(gòu)的基本形態(tài)。

由于TiDB對磁盤I/O有比較高的要求，通過PV掛載網(wǎng)絡(luò)盤，會有明顯的性能損耗。另外，TiKV本身維護(hù)了數(shù)據(jù)多副本，這點(diǎn)和分布式文件系統(tǒng)的多副本是有重復(fù)的，所以要給Pod上掛載本地磁盤，并且在Kubernetes上把Local PV管理起來，作為一種特定資源來維護(hù)。

Kubernetes官方長期以來一直沒有提供Local PV支持，本地存儲只支持hostPath和 emptyDir兩種方式。其中，hostPath的生命周期是脫離Kubernetes管理的，使用 hostPath的Pod銷毀后，里面的數(shù)據(jù)是不會被自動清理，下次再掛載Pod就會造成臟數(shù)據(jù)。而emptyDir更像是一個臨時磁盤，在Pod重建時會被清理重置，不能成為持久化PV來使用。

為此，我們開發(fā)了一個tidb-volume-manager組件，用于管理Kubernetes集群中每臺物理主機(jī)上的本地磁盤，并且將其暴露成一種特殊的PV資源。結(jié)合Operator在部署TiDB節(jié)點(diǎn)時會參考Local PV資源的情況，來選擇特定節(jié)點(diǎn)進(jìn)行部署，分配一個空的Local PV和Pod綁定。而當(dāng)Pod銷毀時，會根據(jù)具體情況決定是否結(jié)束Local PV的生命周期，釋放掉的Local PV在經(jīng)歷一個GC周期后，被tidb-volume-manager回收，清理其盤上數(shù)據(jù)等待再次被分配使用。

（圖：Cloud TiDB 總體架構(gòu)圖）

將這些組件整合起來，就形成了上圖描述了Cloud TiDB總體架構(gòu)。在Kubenetes管理的集群上，通過tidb-operator等組件針對性的調(diào)配和使用集群資源，從而實(shí)現(xiàn)TiDB集群實(shí)例的生命周期管理。通過這種方式實(shí)現(xiàn)TiDB分布式數(shù)據(jù)庫和云平臺的整合。

我們將在下一篇中詳細(xì)介紹針對Cloud TiDB的關(guān)鍵特性和實(shí)現(xiàn)細(xì)節(jié)。