Amazon RDS

其實說到公有云上的云數(shù)據(jù)庫，應(yīng)該最早 Amazon 的 RDS，最早應(yīng)該是在 2009 年發(fā)布的，Amazon RDS 的架構(gòu)類似在底層的數(shù)據(jù)庫上構(gòu)建了一個中間層（從架構(gòu)上來看，阿里云 RDS，UCloud RDS 等其他云的 RDS 服務(wù)基本是大同小異，比拼的是功能多樣性和實現(xiàn)的細(xì)節(jié)）。

這個中間層負(fù)責(zé)路由客戶端的 SQL 請求發(fā)往實際的數(shù)據(jù)庫存儲節(jié)點(diǎn)，因為將業(yè)務(wù)端的請求通過中間層代理，所以可以對底層的數(shù)據(jù)庫實例進(jìn)行很多運(yùn)維工作，比如備份，遷移到磁盤更大或者 IO 更空閑的物理機(jī)等。這些工作因為隱藏在中間層后邊，業(yè)務(wù)層可以做到基本沒有感知，另外這個中間路由層基本只是簡單的轉(zhuǎn)發(fā)請求，所以底層可以連接各種類型的數(shù)據(jù)庫。

所以一般來說，RDS 基本都會支持 MySQL / SQLServer / MariaDB / PostgreSQL 等流行的數(shù)據(jù)庫，對兼容性基本沒有損失，而且在這個 Proxy 層設(shè)計良好的情況下，對性能的損失是比較小的。另外有一層中間層隔離底層的資源池，對于資源的利用和調(diào)度上可以做不少事情。

簡單舉個例子，比如有一些不那么活躍的 RDS 實例可以調(diào)度在一起共用物理機(jī)，比如需要在線擴(kuò)容只需要將副本建立在更大磁盤的機(jī)器上，在 Proxy 層將請求重新定向即可，比如定期的數(shù)據(jù)備份可以放到 S3 上，這些一切都對用戶可以做到透明。

但是這樣的架構(gòu)缺點(diǎn)也同樣明顯：本質(zhì)上還是一個單機(jī)主從的架構(gòu)，對于超過最大配置物理機(jī)的容量，CPU 負(fù)載，IO 的場景就束手無策了。隨著很多業(yè)務(wù)的數(shù)據(jù)量并發(fā)量的增長，尤其是移動互聯(lián)網(wǎng)的發(fā)展，無限的可擴(kuò)展性成為了一個很重要需求。當(dāng)然對于絕大多數(shù)數(shù)據(jù)量要求沒那么大，單實例沒有高并發(fā)訪問的庫來說，RDS 仍然是很適合的。

Amazon DynamoDB

對于剛才提到的水平擴(kuò)展問題，一些用戶實在痛的不行，甚至能接受放棄掉關(guān)系模型和 SQL。比如一些互聯(lián)網(wǎng)應(yīng)用業(yè)務(wù)模型比較簡單，但是并發(fā)量和數(shù)據(jù)量巨大，應(yīng)對這種情況，Amazon 開發(fā)了 DynamoDB，并于 2012 年初發(fā)布 DynamoDB 的云服務(wù)。其實 Dynamo 的論文早在 2007 年就在 SOSP 發(fā)表，這篇有歷史意義的論文直接引爆了 NoSQL 運(yùn)動，讓大家覺得原來數(shù)據(jù)庫還能這么搞。

Dynamo 對外主打的特點(diǎn)是水平擴(kuò)展能力和通過多副本實現(xiàn)（3副本）的高可用，另外在 API 的設(shè)計上可以支持最終一致性讀取和強(qiáng)一致性讀取，最終一致性讀取能提升讀的吞吐量。

但是請注意，DynamoDB 雖然有強(qiáng)一致讀，但是這里的強(qiáng)一致性并不是傳統(tǒng)我們在數(shù)據(jù)庫里說的 ACID 的 C，而且由于沒有時序的概念（只有 vector clock），對于沖突的處理只能交給客戶端，Dynamo 并不支持事務(wù)。不過對于一些特定的業(yè)務(wù)場景來說，擴(kuò)展能力和可用性是最重要的，不僅僅是容量，還有集群的吞吐。

阿里云 DRDS

但是那些 RDS 用戶的數(shù)據(jù)量也是在持續(xù)增長的，對于云服務(wù)提供商來說不能眼睜睜的看著這些 RDS 用戶數(shù)據(jù)量一大就走掉或者自己維護(hù)數(shù)據(jù)庫集群。因為也不是誰都能徹底重構(gòu)代碼到 NoSQL 之上，并且分庫分表其實對于業(yè)務(wù)開發(fā)者來說是一個很痛苦的事情，在痛苦中往往是蘊(yùn)含著商業(yè)機(jī)會的。

比如對于 RDS 的擴(kuò)展方案，我介紹兩個比較典型的：第一個是阿里云的 DRDS （不過現(xiàn)在好像從阿里云的產(chǎn)品列表里拿掉了？），DRDS 其實思路很簡單，就是比 RDS 多一小步，在剛才提到的 RDS 的中間層中加入用戶配置的路由策略，比如用戶可以指定某個表的某些列作為 sharding key 根據(jù)一定規(guī)則路由到特定的實例，也可以垂直的配置分庫的策略。

其實 DRDS 的前身就是淘寶的 TDDL，只不過原來 TDDL 是做在 JDBC 層，現(xiàn)在將 TDDL 做進(jìn)了 Proxy 層（有點(diǎn)像把 TDDL 塞到 Cobar 的感覺）。這樣的好處是，將應(yīng)用層分庫分表的工作封裝起來了，但是本質(zhì)上仍然是一個中間件的方案，盡管能對簡單的業(yè)務(wù)做到一定程度的 SQL 兼容。

對于一些復(fù)雜查詢，多維度查詢，跨 Shard 事務(wù)支持都是有限了。畢竟中間路由層對 SQL 的理解有限，至于更換 Sharding key 、DDL、備份也是很麻煩的事情。從 Youtube 開源的中間件 Vitess 的實現(xiàn)和復(fù)雜程度來看甚至并不比實現(xiàn)一個數(shù)據(jù)庫簡單，但是兼容性卻并沒有重新寫一個數(shù)據(jù)庫來得好。

Amazon Aurora

后來時間來到了 2015 年，Amazon 走了另外一條路。在 2015 年，Amazon Aurora 發(fā)布。Aurora 的資料在公網(wǎng)上并不多，Aurora 提供了 5x 于單機(jī) MySQL 5.6 的讀吞吐能力，不過最大也就擴(kuò)展到 15 個副本，副本越多對寫吞吐影響越大，因為只有一個 Primary Instance 能提供寫入服務(wù)，單個副本最大支持容量 64T，而且支持高可用以及彈性的擴(kuò)展。

值得一提的是 Aurora 的兼容性。其實做數(shù)據(jù)庫的都知道，兼容性是一個很難解決的問題，可能實現(xiàn)上很小的差異就會讓用戶的遷移成本變得很大，這也是為什么中間件和分庫分表的方案如此反人類的原因，我們大多都在追求用戶平滑的遷移體驗。

Aurora 另辟蹊徑，由于公開的資料不多，我猜想 Aurora 在 MySQL 前端之下實現(xiàn)了一個基于 InnoDB 的分布式共享存儲層（ https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/ ）。對于讀實例來說是很好水平擴(kuò)展的，這樣就將 workload 均攤在前端的各個 MySQL 實例上，有點(diǎn)類似 Oracle RAC 那樣的 Share everything 的架構(gòu)。

這個架構(gòu)的好處相對中間件的方案很明顯，兼容性更強(qiáng)，因為還是復(fù)用了 MySQL 的 SQL 解析器。優(yōu)化器，業(yè)務(wù)層即使有復(fù)雜查詢也沒關(guān)系，因為連接的就是 MySQL。

但是也正是由于這個原因，在節(jié)點(diǎn)更多，數(shù)據(jù)量更大的情況下，查詢并不能利用集群的計算能力（對于很多復(fù)雜查詢來說，瓶頸出現(xiàn)在 CPU 上），而且 MySQL 的 SQL 優(yōu)化器能力一直是 MySQL 的弱項，而且對于大數(shù)據(jù)量的查詢的 SQL 引擎的設(shè)計是和單機(jī)有天壤之別的。一個簡單的例子，分布式 Query Engine 比如 SparkSQL / Presto / Impala 的設(shè)計肯定和單機(jī)的 SQL 優(yōu)化器完全不同，更像是一個分布式計算框架。

所以我認(rèn)為 Aurora 是一個在數(shù)據(jù)量不太大的情況下（有容量上限），對簡單查詢的讀性能優(yōu)化的方案，另外兼容性比中間件的方案好得多。但是缺點(diǎn)是對于大數(shù)據(jù)量，復(fù)雜查詢的支持還是比較弱，另外對于寫入性能 Aurora 其實沒有做太多優(yōu)化（單點(diǎn)寫入），如果寫入上出現(xiàn)瓶頸，仍然需要在業(yè)務(wù)層做水平或者豎直拆分。

Google Cloud BigTable

Google 作為大數(shù)據(jù)的祖宗一樣的存在，對于云真是錯過了一波又一波：虛擬化錯過一波讓 VMWare 和 Docker 搶先了（Google 早在十年前就開始容器的方案，要知道容器賴以生存的 cgroups 的 patch 就是 Google 提交的）；云服務(wù)錯過一波讓 Amazon 搶先了（Google App Engine 真是可惜）：大數(shù)據(jù)存儲錯過一波讓開源的 Hadoop 拿下了事實標(biāo)準(zhǔn)，以至于我覺得 Google Cloud BigTable 服務(wù)中兼容 Hadoop HBase API 的決定，當(dāng)時實現(xiàn)這些 Hadoop API for BigTable 的工程師心中應(yīng)該是滴血的 :)

不過在被 Amazon / Docker / Hadoop 刺激到以后，Google 終于意識到社區(qū)和云化的力量，開始對 Google Cloud 輸出 Google 內(nèi)部各種牛逼的基礎(chǔ)設(shè)施，2015 年終于在 Google Cloud Platform 上正式亮相。對于 BigTable 的架構(gòu)相信大多數(shù)分布式存儲系統(tǒng)工程師都比較了解，畢竟 BigTable 的論文也是和 Amazon Dynamo 一樣是必讀的經(jīng)典，我就不贅述了。

BigTable 云服務(wù)的 API 和 HBase 兼容，所以也是 {Key : 二維表格結(jié)構(gòu)}，由于在 Tablet Server 這個層次還是一個主從的結(jié)構(gòu)，對一個 Tablet 的讀寫默認(rèn)都只能通過 Tablet Master 進(jìn)行，這樣使得 BigTable 是一個強(qiáng)一致的系統(tǒng)。這里的強(qiáng)一致指的是對于單 Key 的寫入，如果服務(wù)端返回成功，接下來發(fā)生的讀取，都能是最新的值。

由于 BigTable 仍然不支持 ACID 事務(wù)，所以這里的強(qiáng)一致只是對于單 Key 的操作而言的。對于水平擴(kuò)展能力來說， BigTable 其實并沒有什么限制，文檔里很囂張的號稱 Incredible scalability，但是 BigTable 并沒有提供跨數(shù)據(jù)中心（Zone）高可用和跨 Zone 訪問的能力。

也就是說，一個 BigTable 集群只能部署在一個數(shù)據(jù)中心內(nèi)部。這其實看得出 BigTable 在 Google 內(nèi)部的定位，就是一個高性能低延遲的分布式存儲服務(wù)，如果需要做跨 Zone 高可用需要業(yè)務(wù)層自己做復(fù)制在兩個 Zone 之間同步，構(gòu)建一個鏡像的 BigTable 集群。

其實 Google 很多業(yè)務(wù)在 MegaStore 和 Spanner 出來之前，就是這么搞的。對于 BigTable 來說，如果需要搞跨數(shù)據(jù)中心高可用，強(qiáng)一致，還要保證低延遲那是不太可能的，也不符合 BigTable 的定位。另外值得吐槽的是 BigTable 團(tuán)隊發(fā)過一個 Blog ：https://cloudplatform.googleblog.com/2015/05/introducing-Google-Cloud-Bigtable.html

里面把 HBase 的延遲黑得夠嗆，一個 .99 的響應(yīng)延遲 6 ms, HBase 280ms。其實看平均響應(yīng)延遲的差距不會那么大....BigTable 由于是 C++ 寫的，優(yōu)勢就是延遲是相當(dāng)平穩(wěn)的。但是據(jù)我所知 HBase 社區(qū)也在做很多工作將 GC 帶來的影響降到最小，比如 off-heap 等優(yōu)化做完以后，HBase 的延遲表現(xiàn)會好一些。

Google Cloud Datastore

在 2011 年，Google 發(fā)表了 Megastore 的論文，第一次描述了一個支持跨數(shù)據(jù)中心高可用 + 可以水平擴(kuò)展 + 支持 ACID 事務(wù)語義的分布式存儲系統(tǒng)。 Google Megastore 構(gòu)建在 BigTable 之上，不同數(shù)據(jù)中心之間通過 Paxos 同步，數(shù)據(jù)按照 Entity Group 來進(jìn)行分片。Entity Group 本身跨數(shù)據(jù)中心使用 Paxos 復(fù)制，跨 Entity Group 的 ACID 事務(wù)需要走兩階段的提交，實現(xiàn)了 Timestamp-based 的 MVCC。

不過也正是因為 Timstamp 的分配需要走一遍 Paxos，另外不同 Entity Groups 之間的 2PC 通信需要通過一個隊列來進(jìn)行異步的通信，所以實際的 Megastore 的 2PC 的延遲是比較大的，論文也提到大多數(shù)的寫請求的平均響應(yīng)延遲是 100~400ms 左右。據(jù) Google 內(nèi)部的朋友提到過，Megastore 用起來是挺慢的，秒級別的延遲也是常有的事情...

作為應(yīng)該是 Google 內(nèi)部第一個支持 ACID 事務(wù)和 SQL 的分布式數(shù)據(jù)庫，還是有大量的應(yīng)用跑在 Megastore 上，主要是用 SQL 和事務(wù)寫程序確實能輕松得多。為什么說那么多 Megastore 的事情呢？因為 Google Cloud Datastore 的后端就是 Megastore…

其實 Cloud Datastore 在 2011 年就已經(jīng)在 Google App Engine 中上線，也就是當(dāng)年的 Data Engine 的 High Replication Datastore，現(xiàn)在改了個名字叫 Cloud Datastore，當(dāng)時不知道背后原來就是大名鼎鼎的 Megastore 實在是失敬。

雖然功能看上去很牛，又是支持高可用，又支持 ACID，還支持 SQL（只不過是 Google 精簡版的 GQL）但是從 Megastore 的原理上來看延遲是非常大的，另外 Cloud Datastore 提供的接口是一套類似的 ORM 的 SDK，對業(yè)務(wù)仍然是有一定的侵入性。

Google Spanner

雖然 Megastore 慢，但是架不住好用。在 Spanner 論文中提到，2012 年大概已經(jīng)有 300+ 的業(yè)務(wù)跑在 Megastore 上，在越來越多的業(yè)務(wù)在 BigTable 上造 ACID Transaction 實現(xiàn)的輪子后，Google 實在受不了了，開始造一個大輪子 Spanner，項目的野心巨大，和 Megastore 一樣，ACID 事務(wù) + 水平擴(kuò)展 + SQL 支持。

但是和 Megastore 不一樣的是，Spanner 沒有選擇在 BigTable 之上構(gòu)建事務(wù)層，而是直接在 Google 的第二代分布式文件系統(tǒng) Colossus 之上開始構(gòu)建 Paxos-replicated tablet。

另外不像 Megastore 實現(xiàn)事務(wù)那樣通過各個協(xié)調(diào)者通過 Paxos 來決定事務(wù)的 timestamp，而是引入了硬件，也就是 GPS 時鐘和原子鐘組成的 TrueTime API 來實現(xiàn)事務(wù)。這樣一來，不同數(shù)據(jù)中心發(fā)起的事務(wù)就不需要跨數(shù)據(jù)中心協(xié)調(diào)時間戳，而是直接通過本地數(shù)據(jù)中心的 TrueTime API 來分配，這樣延遲就降低了很多。

Spanner 近乎完美的一個分布式存儲，在 Google 內(nèi)部也是的 BigTable 的互補(bǔ)，想做跨數(shù)據(jù)中心高可用和強(qiáng)一致和事務(wù)的話，用 Spanner，代價是可能犧牲一點(diǎn)延遲，但是并沒有Megastore 犧牲那么多；想高性能（低延遲）的話，用 BigTable。

Google Spanner 目前沒有在 Google Cloud Platform 中提供服務(wù)，但是看趨勢簡直是一定的事情，至少作為 Cloud Datastore 的下一代是一定的。另外一方面來看 Google 仍然沒有辦法將 Spanner 開源，原因和 BigTable 一樣，底層依賴了 Colossus 和一堆 Google 內(nèi)部的組件，另外比 BigTable 更困難的是，TrueTime 是一套硬件...

所以在 12 年底發(fā)布 Spanner 的論文后，社區(qū)也有開源的實現(xiàn)，比如目前比較成熟的 TiDB 和 CockroachDB，一會提到社區(qū)的云數(shù)據(jù)庫實現(xiàn)的時候會介紹。Spanner 的接口比 BigTable 稍微豐富一些，支持了它稱之為 Semi-relational 的表結(jié)構(gòu)，可以像關(guān)系型數(shù)據(jù)庫那樣進(jìn)行 DDL，雖然仍然要指定每行的 primary key，但是比簡單的 kv 還是好太多。

Google F1

在 Spanner 項目開始的同時，Google 啟動了另外一個和 Spanner 配套使用的分布式 SQL 引擎的項目 F1，底層有那么一個強(qiáng)一致高性能的 Spanner，那么就可以在上層嘗試將 OLTP 和部分的 OLAP 打通。F1 其實論文題目說是一個數(shù)據(jù)庫，但是它并不存儲數(shù)據(jù)，數(shù)據(jù)都在 Spanner 上，它只是一個分布式查詢引擎，底層依賴 Spanner 提供的事務(wù)接口，將用戶的 SQL 請求翻譯成分布式執(zhí)行計劃。

Google F1 提供了一種可能性，這是在其他的數(shù)據(jù)庫中一直沒有實現(xiàn)過的：OLTP 與 OLAP 融合的可能性。因為 Google F1 設(shè)計目標(biāo)是給 Google 的廣告系統(tǒng)使用，廣告投放系統(tǒng)這類系統(tǒng)一是對于一致性要求很高，壓力也很大，是典型的 OLTP 場景；第二是可能會有很多復(fù)雜的廣告投放效果評估的查詢，而且這類的查詢越是實時越好，這又有點(diǎn)實時 OLAP 的意思。

傳統(tǒng)的做法是 OLTP 的數(shù)據(jù)庫將數(shù)據(jù)每隔一段時間同步一份到數(shù)據(jù)倉庫中，在數(shù)據(jù)倉庫中離線的進(jìn)行計算，稍微好點(diǎn)的使用一些流式計算框架進(jìn)行實時計算。第一種使用數(shù)據(jù)倉庫的方案，實時性是比較差的，倒騰數(shù)據(jù)是很麻煩的事情；至于使用流式計算框架的方案，一是靈活性不好，很多查詢邏輯需要提前寫好，沒法做很多 Ad-hoc 的事情，另外因為兩邊是異構(gòu)的存儲，導(dǎo)致 ETL 也是很麻煩的工作。

F1 其實依靠 Spanner 的 ACID 事務(wù)和 MVCC 的特性實現(xiàn)了 100% 的 OLTP，并且自身作為一個分布式 SQL 引擎，可以利用集群的計算資源實現(xiàn)分布式的 OLAP 查詢。這帶來的好處就是并不需要額外在設(shè)置一個數(shù)據(jù)倉庫進(jìn)行數(shù)據(jù)分析，而是直接在同一個數(shù)據(jù)庫里實時分析，另外由于 Spanner 的 MVCC 和多副本帶來的 Lock-free snapshot read 的特性，這類 OLAP 查詢并不會影響正常 OLTP 的操作。

對于 OLTP 來說，瓶頸經(jīng)常出現(xiàn)在 IO 上。對于 OLAP 來說，瓶頸反而經(jīng)常出現(xiàn)在 CPU 也就是計算上。其實看上去是能融合起來，提升整個集群的資源利用率，這也是我看好 Google F1 + Spanner 這個組合的原因，未來的數(shù)據(jù)庫可能會融合數(shù)據(jù)倉庫，提供更完整且更實時的體驗。

(其實這個下面的 GFS 不太準(zhǔn)確，現(xiàn)在應(yīng)該是 Colossus)

Open source cloud-native database

2016 年在硅谷突然有個新詞火了起來 GIFEE，Google Infrastructure For Everyone Else，大家意識到好像隨著新一代的開源基礎(chǔ)軟件的繁榮發(fā)展，原來在 Google 內(nèi)部的基礎(chǔ)設(shè)施已經(jīng)有很多高質(zhì)量的開源實現(xiàn)。

比如容器方面有 Docker，調(diào)度器方面 Google 主動開源的 Borg 的第二代 Kubernetes，傳統(tǒng)的 BigTable 和 GFS 社區(qū)還有雖然屎但是還是能湊合用的 Hadoop，而且很多大廠覺得 Hadoop 屎的都基本自己都造了類似的輪子……

更別說最近 Google 開源上癮，Kubernetes 就不提了，從大熱的 Tensorflow 到相對冷門但是我個人認(rèn)為意義重大的 Apache Beam（Google Cloud Dataflow 的基礎(chǔ)），基本能獨(dú)立開源的都在積極的擁抱社區(qū)。

這就造成了社區(qū)與 Google 內(nèi)部差距正在縮小，但是目前來說，Spanner 和 F1 并不是那么容易造的。就算拋開 TrueTime 的硬件不提，實現(xiàn)一個穩(wěn)定的 Multi-Paxos 都不是容易的事情，另外分布式 SQL 優(yōu)化器這種事情也是有很高技術(shù)門檻的，另外就算造出來了，測試的復(fù)雜度也一點(diǎn)不比實現(xiàn)的復(fù)雜度低（可以參考 PingCAP 的分布式測試哲學(xué)的幾篇分享）。

目前從全球范圍內(nèi)來看，我認(rèn)為開源世界只有兩個團(tuán)隊：一個 PingCAP 的 TiDB，一個 CockroachLabs 的 CockroachDB 是有足夠的技術(shù)能力和視野能將 Spanner 的開源實現(xiàn)造出來的。目前 TiDB 已經(jīng) RC1 并有不少使用者在生產(chǎn)環(huán)境使用，比 CockroachDB 的成熟度稍好，架構(gòu)上更接近正統(tǒng)的 F1 above Spanner 的架構(gòu)。CockroachDB 的成熟度稍微落后一些，并且協(xié)議選擇 PostgreSQL，TiDB 選擇的是 MySQL 的協(xié)議兼容。

而且從 TiDB 的子項目 TiKV 中，我們看到了新一代分布式 KV 的雛形，RocksDB + Multi-Raft 不依賴第三方分布式文件系統(tǒng)（DFS）提供水平擴(kuò)展能力，正在成為新一代分布式 KV 存儲標(biāo)準(zhǔn)架構(gòu)。另外也很欣喜的看到竟然是由一個國內(nèi)團(tuán)隊發(fā)起并維護(hù)的這樣級別的開源項目，即使放到硅谷也是頂級的設(shè)計和實現(xiàn)，從 Github 的活躍度和使用的工具及運(yùn)營社區(qū)的流程上來看，很難看出是一個國內(nèi)團(tuán)隊。

Kubernetes + Operator

剛才提到了一個詞 Cloud-Native，其實這個詞還沒有準(zhǔn)確的定義，不過我的理解是應(yīng)用開發(fā)者和物理設(shè)施隔離，也就是業(yè)務(wù)層不需要再去關(guān)心存儲的容量性能等等一切都可以透明水平擴(kuò)展，集群高度自動化乃至支持自我修復(fù)。

對于一個大規(guī)模的分布式存儲系統(tǒng)來說人工是很難介入其中的，比如一個上千個節(jié)點(diǎn)的分布式系統(tǒng)，幾乎每天都可能有各種各樣的節(jié)點(diǎn)故障，瞬時網(wǎng)絡(luò)抖動甚至整個數(shù)據(jù)中心直接掛掉，人工去做數(shù)據(jù)遷移，數(shù)據(jù)恢復(fù)幾乎是不可能的事情。

很多人非?？春?Docker，認(rèn)為它改變了運(yùn)維和軟件部署方式，但是我認(rèn)為更有意義的是 Kubernetes。調(diào)度器才是 Cloud-native 架構(gòu)的核心，容器只是一個載體而已并不重要，Kubernetes 相當(dāng)于是一個分布式的操作系統(tǒng)，物理層是整個數(shù)據(jù)中心，也就是 DCOS，這也是我們在 Kubernetes 上下重注的原因，我認(rèn)為大規(guī)模分布式數(shù)據(jù)庫未來不可能脫離 DCOS。

不過 Kubernetes 上對于有狀態(tài)的服務(wù)編排是一件比較頭疼的事情。而一般的分布式系統(tǒng)的特點(diǎn)，他不僅每個節(jié)點(diǎn)都有存儲的數(shù)據(jù)，而且他還要根據(jù)用戶需要做擴(kuò)容，縮容。

當(dāng)程序更新時要可以做到不停服務(wù)的滾動升級，當(dāng)遇到數(shù)據(jù)負(fù)載不均衡情況下系統(tǒng)要做 Rebalance，同時為了保證高可用性，每個節(jié)點(diǎn)的數(shù)據(jù)會有多個副本，當(dāng)單個節(jié)點(diǎn)遇到故障，還需要自動恢復(fù)總的副本數(shù)。而這些對于 Kubernetes 上的編排一個分布式系統(tǒng)來說都是非常有挑戰(zhàn)的。

Kubernetes 在 1.3 版本推出了 Petset ，現(xiàn)在已經(jīng)改名叫 StatefulSet， 核心思想是給 Pod 賦予身份，并且建立和維護(hù) Pod 和 存儲之間的聯(lián)系。當(dāng) Pod 可能被調(diào)度的時候，對應(yīng)的 Persistent Volume 能夠跟隨他綁定。但是它并沒有完全解決我們的問題，PS 仍然需要依賴于 Persistent Volume。

目前 Kubernetes 的 Persistent Volume 只提供了基于共享存儲，分布式文件系統(tǒng)或者 NFS 的實現(xiàn)，還沒有提供 Local Storage 的支持，而且 Petset 本身還處于 Alpha 版本階段，我們還在觀望。

不過除了 Kubernetes 官方社區(qū)還是有其他人在嘗試，我們欣喜的看到，就在不久之前，CoreOS 提出了一個新的擴(kuò)展 Kubernetes 的新方法和思路。CoreOS 為 Kubernetes 增加了一個新成員，叫作 Operator。

Operator 其實是一種對 Controller 的擴(kuò)展，具體的實現(xiàn)由于篇幅的原因我就不羅嗦了，簡單來說是一個讓 Kubernetes 調(diào)度帶狀態(tài)的存儲服務(wù)的方案，CoreOS 官方給出了一個 Etcd-cluster 的備份和滾動升級的 operator 實現(xiàn)，我們也在開發(fā) TiDB 的 operator，感興趣的可以關(guān)注我們的 Github 了解最新的進(jìn)展。

來源：紫數(shù)網(wǎng)