《專家觀察 | 黃東旭：“Cloud-Native與分布式數(shù)據(jù)庫”》要點：
本文介紹了專家觀察 | 黃東旭：“Cloud-Native與分布式數(shù)據(jù)庫”，希望對您有用。如果有疑問，可以聯(lián)系我們。

由工業(yè)和信息化部指導,中國信息通信研究院主辦,業(yè)界知名組織云計算開源產(chǎn)業(yè)聯(lián)盟(OSCAR)承辦的2017全球云計算開源大會于4月19日-20日在北京國家會議中心順利召開.本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽.

嘉賓介紹:黃東旭

公司職務：PingCAP CTO

大會演講速記

大家好,今天我的題目是Cloud-Native與分布式數(shù)據(jù)庫的實踐.

我先簡單的介紹一下自己,我是PingCAP的聯(lián)合創(chuàng)始人和CTO,過去一直都是做基礎軟件領域的工程師,基本上做的所有的東西都是開源.

其實在整個分享之前我想說一下為什么現(xiàn)在各行各業(yè)或者整個技術軟件社區(qū)一直在重復的再造數(shù)據(jù)庫或者現(xiàn)在數(shù)據(jù)庫到底怎么了,為什么這么百花齊放?因為隨著整個業(yè)務的多種多樣還有不管是傳統(tǒng)行業(yè)還是互聯(lián)網(wǎng)行業(yè),業(yè)務的迭代速度越來越互聯(lián)網(wǎng)化,使得整個數(shù)據(jù)量其實是一直在往上走的.第二就是隨著IOT的設備還有包括像手機、移動互聯(lián)網(wǎng)蓬勃的發(fā)展,終端其實也不僅僅是傳統(tǒng)的PC客戶端的數(shù)據(jù)的接入,第三方面隨著現(xiàn)在AI或者大數(shù)據(jù)分析一些模型或者理論上的突破,使得在大數(shù)據(jù)上進行計算的手段越來越多樣.

還有在物理上一些硬件的新的帶有保護的內存,各種各樣新的物理的設備包括我正在做的,越來越多的硬件或者物理上的存儲成本持續(xù)的降低,使得我們的數(shù)據(jù)庫需要要面對更多的挑戰(zhàn).關聯(lián)數(shù)據(jù)庫理論是上世紀七十年代做出來的東西,現(xiàn)在四十年過去不管是物理的環(huán)境還是計算模型都是完全不一樣的階段,還抱著過去這種觀念可能并不是一個面向未來的設計.

今天我的題目是Cloud-Native,有一個比較大膽的假設,大家在過去三十年的計算平臺基本都是在一臺PC或者一個服務器或者一個手機這樣的獨立的計算平臺,但是未來我覺得一切的服務都應該是分布式的.因為我覺得摩爾定律已經(jīng)失效了,所以未來的操作系統(tǒng)會是一個大規(guī)模分布式的操作系統(tǒng),在上面跑的任何的進程任何的服務都應該是分布式的,在這個假設下怎么去做設計,云其實是這個假設最好的載體,怎么在這個假設上去設計面向云的技術軟件,其實是最近我一直在思考的一個問題.

其實在這個時代包括面向云的軟件,對業(yè)務開發(fā)來說盡量還是不要太多的改變過去的開發(fā)習慣.你看最近大數(shù)據(jù)的發(fā)展趨勢,從最傳統(tǒng)的關系數(shù)據(jù)庫到過去十年相比,整個改變了用戶的編程模型,但是改變到底是好的還是不好的,我個人覺得其實并不是太好,最近這兩年大家會看到整個學術圈各種各樣的論文都在回歸,包括DB新時代的軟件都會把擴展性和分布式放在第一個要素.

大家可能聽到主題會有點蒙,叫Cloud-Native,Cloud-Native是什么?其實很早的過去也不是沒有人做過這種分布式系統(tǒng)的嘗試,最早是IBM提出面向服務的軟件架構設計,最近熱門的SOA、Micro Service把自己的服務拆分成小的服務,到現(xiàn)在谷歌一直對外輸出一個觀點就是Cloud-Native,就是未來大家的業(yè)務看上去的分布式會變成一個更加透明的概念,就是你怎么讓分布式的復雜性消失在云的基礎設施后,這是Cloud-Native更加關心的事情.

這個圖是CNCF的一個基金會,也是谷歌支持的基金會上扒過來的圖,這里面有一個簡單的定義,就是SCALE作為一等公民,面向Cloud-Native的業(yè)務必須是彈性伸縮的,不僅能伸也得能縮,第二就是在對于這種Cloud-Native業(yè)務來說是面向Micro service友好,第三就是部署更加的去人工化,最近可能也看到很多各種各樣容器化的方案,背后代表的意義是什么?

就是整個運維和部署脫離人工,大家可以想象過去十幾二十年來,一直以來運維的手段是什么樣的,我找了一個運維,去買服務器,買服務器裝系統(tǒng),在上面部署業(yè)務,但是現(xiàn)在Cloud-Native出現(xiàn)變得非常的自動化,就相當于把人的功能變得更低,這是很有意義的,因為理想中的世界或者未來的世界應該怎么樣,一個業(yè)務可能會有成百上千的物理節(jié)點.

如果是人工的去做運維和部署是根本不可能做得到的,所以其實構建整個Cloud-Native的基礎設施的兩個條件,第一個就是存儲本身的云化,第二就是運維要和部署的方式必須是云化的,我就從這兩個點說一下我們 TiDB 在上面的一些工作和一些我的思考.

存儲本身的云化有幾個基本條件,大家過去認為是高可用,主要停留在雙活,其實仔細去思考的話,主備的方案是很難保證數(shù)據(jù)在完全不需要人工的介入情況下數(shù)據(jù)的一致性可用性的,所以大家會發(fā)現(xiàn)最近這幾年出來的分布式存儲系統(tǒng)的可用性的協(xié)議跟復制協(xié)議基本都會用類似Raft/Paxos基于選取的一致性算法,不會像過去做這種老的復制的方案.

第二就是整個分片的策略,作為分布式系統(tǒng)數(shù)據(jù)一定是會分片的,數(shù)據(jù)分片是來做分布式存儲唯一的思路,自動分片一定會取代傳統(tǒng)的人工分片來去支撐業(yè)務,比如傳統(tǒng)分片,當你的數(shù)據(jù)量越來越大,你只能做分庫分表或者用中間件,不管你分庫分表還是中間件都必須制訂自己人工的分辨規(guī)則,但是其實在一個真正面向Cloud的數(shù)據(jù)庫設計里,任何一種人的介入的東西都是不對的.

第三,接入層的去狀態(tài)化,因為你需要面對Cloud-Native做設計,你的接入層就不能帶有狀態(tài),你可以相當于是前端的接入層是一層無狀態(tài)的或者連接到任何一個服務的接入的入口,對你來說應該都是一樣的,就是說你不能整個系統(tǒng)因為一個關鍵組件的損壞或者說磁盤壞掉或者機器的宕機,整個系統(tǒng)就不能服務了,整個測試系統(tǒng)應該具有自我愈合和自我維護的能力.

其實我本身是架構師,所以整個我們數(shù)據(jù)庫的設計都是圍繞這些點來做思考的,就是一個數(shù)據(jù)庫怎么能讓他自我的生長,自我的維護,出現(xiàn)任何的災難性的物理故障(有物理故障是非常正常的,每天在一個比較大的集群的規(guī)模下,網(wǎng)絡中斷、磁盤損壞甚至是很多很詭異的問題都是很正常的),所以怎么設計這種數(shù)據(jù)庫,我們的項目是TiDB,我不知道在座的有沒有聽說過這個項目,它其實是一個開源實現(xiàn).

當你的業(yè)務已經(jīng)用了數(shù)據(jù)庫,數(shù)據(jù)量一大就有可能遇到一些問題,一個是單點的可靠性的問題,還有一個數(shù)據(jù)容量怎么去彈性伸縮的問題.TiDB就能解決這個問題,它本身對外暴露了一個接口,你可以用客戶端去連接,你可以認為你下面面對的是一個彈性動態(tài)伸縮完全沒有容量限制.

同時還可以在上面支持復雜的子查詢的東西,底層存儲的話,相當于這一層無狀態(tài)的會把這個請求發(fā)到底層的節(jié)點上,這個存儲里面的數(shù)據(jù)都是通過協(xié)議做高可用和復制的,這個數(shù)據(jù)在底層會不停的分裂和移動.你可以認為這個數(shù)據(jù)庫是一個活的數(shù)據(jù)庫,你任何一個節(jié)點的宕機都不會影響整個數(shù)據(jù)庫對業(yè)務層的使用,包括你可以跨數(shù)據(jù)中心部署,甚至你在跨數(shù)據(jù)中心的時候,整個數(shù)據(jù)中心網(wǎng)絡被切斷,機房著火,業(yè)務層都幾乎完全是透明的,而且這個數(shù)據(jù)比如副本丟失會自己去修復,自己去管理或者移動數(shù)據(jù).

上圖右邊是一個集群的調度模塊,你可以認為它是整個集群的大腦,是一個7×24小時不眠的DBA,你任何的業(yè)務可以接上來.

所以本質上來說NewSQL這個詞大家聽的都爛了,但是我還是想提,首先它是一個面向擴展的數(shù)據(jù)庫,同時它還結合的傳統(tǒng)管理數(shù)據(jù)庫的強一致事務,必須得是SSI隔離級別的,并不是非常弱根本沒法用的隔離級別,而是需要提供最強一致性的隔離級別的數(shù)據(jù)庫.

擴展性其實是通過在TiKV層面做完全自動分片,可用性是通過Raft為保證,我們整個數(shù)據(jù)庫沒有主從的概念,每一個節(jié)點既可以是主又可以是從,然后整個數(shù)據(jù)復制通過Raft為保證,對外的是一個強一致性的事務層,其實背后的算法是用兩階段提交的算法,比如一個最簡單的例子,我一百個并發(fā)過來很快,每個平均十毫秒訪問數(shù)據(jù),一百個并發(fā),一百萬個并發(fā),你還能保證每一個請求都是十毫秒返回數(shù)據(jù)嗎?

那我可以簡單的通過添加機器把系統(tǒng)的吞吐加上去,每一個吞吐的響應延遲會更大一些,在論文里提到過,谷歌數(shù)據(jù)庫寫的每一個平均延遲是150到100毫秒,可以做到線性擴展.所以終于有一個數(shù)據(jù)庫可以scable.

剛才說的是存儲層面的云化,剛才提到了Cloud-Native還有一個重要的點就是部署和運維方式的云化,我們其實選的這個Kubernetes就是用來承載背后數(shù)據(jù)庫大規(guī)模集群上的部署,其實大家都知道這個是什么東西,這是最出名的開源項目之一,谷歌開源的,大家也知道borg,就是他們用了這么多年的集群調度服務,主要做的事情就是服務的編排、部署、自動化的運維,一臺物理機掛掉了,他會很好的讓這個業(yè)務不中斷,像集群調度器,它就是整個數(shù)據(jù)中心的操作系統(tǒng).

但是面臨最大的問題就是所有的業(yè)務一旦是有狀態(tài)的,那你這個就非常惡心,舉個案例,比如我在跑一個數(shù)據(jù)庫,如果你這臺物理機宕機,按照Kubernetes會開一個服務器在那邊展開,但是這一臺老的宕機服務器數(shù)據(jù)是存在上面的,你不能只是把進程在新的服務器那啟起來而數(shù)據(jù)不帶過去,相當于這種業(yè)務是帶狀態(tài)的,這在Kubernetes過去是一個老大難的問題.

 

其實整個應用層,因為它的特性被分成了四個大的陣營,如果想上可以看一下自己的業(yè)務到底屬于哪一個陣營,第一個就是完全無狀態(tài)的業(yè)務,比如這是一個簡單的CRUD業(yè)務層的邏輯,其實是無狀態(tài)的應用層.第二種就是單點的帶狀態(tài)的applications,還有任何單機的數(shù)據(jù)庫其實都有屬于applications.第三個就是Static distributed,比如高可用的分布式服務,大家也不會做擴容什么的,這種是靜態(tài)的分布式應用.

還有最難的一個問題,就是這種集群型的applications,clustered是沒有辦法很好的調度服務的.這是剛才說的,其實對于Single point,其實是很好解決的,對于靜態(tài)的其實也是用Static distributed來解決帶狀態(tài)的持續(xù)化的方案.

剛才我說最難的那個問題,我們整個架構中引入了Operational,調度一套有狀態(tài)服務的方案,其實它思路也很簡單,就是把運維分布人員系統(tǒng)的領域知識給嵌入到了系統(tǒng)中,Knowledge發(fā)布調度任務之前都會相當于被CoreOS提供的接口以后再調度業(yè)務,這套方案依賴了HtirdPartyResources調度,因為這個里面我的狀態(tài)我自己才知道,這個時候你需要通過把你的系統(tǒng)領域知識放到operator里.很簡單,就是Create用TiDB Operator來實現(xiàn),還有Rollingupdate和Scale Out還有Failover等.

使用Kubemetes很重要的原因就是它只用到了很毛的一層API,內部大量的邏輯是在Operator內部,而且像PV/Statefulset中并不是一個很好的方案,比如PV實現(xiàn)你可以用分布式文件系統(tǒng)或者快存儲作為你持久化的這一層,但是數(shù)據(jù)庫的業(yè)務,我對我底層的IO或者硬件有很強的掌控力的,我在我的業(yè)務層自己做了三副本和高可用,我其實就不需要在存儲層面上.比如我在一個裸盤上跑的性能能比其他上快十倍,這個時候你告訴我不好意思下面只支持statefulset那這是不適合跑數(shù)據(jù)庫的,也就是數(shù)據(jù)庫集群是跟它的普通的云盤或者云存儲的業(yè)務是分開的.

分布式數(shù)據(jù)庫也不是百分之百所有的業(yè)務場景都適合,特別是大規(guī)模的分布式數(shù)據(jù)庫來說,比如自增ID,雖然我們支持,但是自增IT高壓力寫入的時候它的壓力會集中在表的末尾,其實是我不管怎么調度總會有一塊熱點.

當然你可以先分表,最后我們聚合分析也沒有問題,像秒殺或者特別小的表,其實是完全不適合在這種分布式數(shù)據(jù)庫上做的,比較好的一些實踐業(yè)務的讀寫比較平均,數(shù)據(jù)量比較大,同時還有并發(fā)的事務的支持,需要有事務的支持,但并不是沖突特別大的場景,并不是秒殺的場景,同時你又可以需要在上面做比較復雜的分析,比如現(xiàn)在我們的一些線上的用戶特別好玩,過去它的業(yè)務全都是跑在MySQL上,一主多從,他發(fā)現(xiàn)我一個個MySQL成為了信息的孤島,他并沒有辦法做聚合地分析.

過去傳統(tǒng)的方案就是我把MySQL或者數(shù)據(jù)通過一個ETL流程導到數(shù)據(jù)倉庫里,但是開發(fā)者不會用各種琳瑯滿目大數(shù)據(jù)的東西,他只會用MySQL,一般他做的數(shù)據(jù)分析都會把MySQL倒騰到一個庫上再做分析,數(shù)據(jù)量一大堆分析不出來,這個時候他把所有他自己的MySQL總庫連到了一個TiDB上,過去是一主多從,先多主多從,把所有的從都打通,做MySQL的分析,所以我覺得TiDB打造了新的模型,可以讀寫高并發(fā)的事務,所以未來的數(shù)據(jù)庫會是一個什么樣子的,我覺得可能是至少我們覺得沿著這條路走下去應該會有一條新的路,謝謝大家.

文章來自微信公眾號：云計算開源產(chǎn)業(yè)聯(lián)盟

轉載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4149.html