「一切都會運行在云端」。現(xiàn)在越來越多的業(yè)務從自己維護基礎設施轉(zhuǎn)移到公有(或者私有)云上， 帶來的好處也是無需贅述的，極大降低了 IaaS 層的運維成本，對于數(shù)據(jù)庫層面來說的，以往需要很強的 DBA 背景才能搞定彈性擴容高可用什么的高級動作，現(xiàn)在大多數(shù)云服務基本都或多或少提供了類似的服務。

[[178165]]

今天的分享主要集中在比較***的云服務商的云數(shù)據(jù)庫方案背后的架構(gòu)，以及我最近觀察到的一些對于云數(shù)據(jù)庫有意義的工業(yè)界的相關技術的進展。

Amazon RDS

其實說到公有云上的云數(shù)據(jù)庫，應該最早 Amazon 的 RDS，最早應該是在 2009 年發(fā)布的，Amazon RDS 的架構(gòu)類似在底層的數(shù)據(jù)庫上構(gòu)建了一個中間層(從架構(gòu)上來看，阿里云 RDS，UCloud RDS 等其他云的 RDS 服務基本是大同小異，比拼的是功能多樣性和實現(xiàn)的細節(jié))，這個中間層負責路由客戶端的 SQL 請求發(fā)往實際的數(shù)據(jù)庫存儲節(jié)點，因為將業(yè)務端的請求通過中間層代理，所以可以對底層的數(shù)據(jù)庫實例進行很多運維工作，比如備份，遷移到磁盤更大或者 IO 更空閑的物理機等，這些工作因為隱藏在中間層后邊，業(yè)務層可以做到基本沒有感知，另外這個中間路由層基本只是簡單的轉(zhuǎn)發(fā)請求，所以底層可以連接各種類型的數(shù)據(jù)庫。

所以一般來說，RDS 基本都會支持 MySQL / SQLServer / MariaDB / PostgreSQL 等流行的數(shù)據(jù)庫，對兼容性基本沒有損失，而且在這個 Proxy 層設計良好的情況下，對性能的損失是比較小的，另外有一層中間層隔離底層的資源池，對于資源的利用和調(diào)度上可以做不少事情，比如簡單舉個例子，比如有一些不那么活躍的 RDS 實例可以調(diào)度在一起共用物理機，比如需要在線擴容只需要將副本建立在更大磁盤的機器上，在 Proxy 層將請求重新定向即可，比如定期的數(shù)據(jù)備份可以放到 S3 上，這些一切都對用戶可以做到透明。

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

Amazon DynamoDB

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

Dynamo 對外主打的特點是水平擴展能力和通過多副本實現(xiàn)(3副本)的高可用，另外在 API 的設計上可以支持最終一致性讀取和強一致性讀取，最終一致性讀取能提升讀的吞吐量。但是請注意，DynamoDB 雖然有強一致讀，但是這里的強一致性并不是傳統(tǒng)我們在數(shù)據(jù)庫里說的 ACID 的 C，而且由于沒有時序的概念(只有 vector clock)，對于沖突的處理只能交給客戶端，Dynamo 并不支持事務。不過對于一些特定的業(yè)務場景來說，擴展能力和可用性是最重要的，不僅僅是容量，還有集群的吞吐。

阿里云 DRDS

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

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

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

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

Amazon Aurora

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

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

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

這個架構(gòu)的好處相對中間件的方案很明顯，兼容性更強，因為還是復用了 MySQL 的 SQL 解析器，優(yōu)化器，業(yè)務層即使有復雜查詢也沒關系，因為連接的就是 MySQL。但是也正是由于這個原因，在節(jié)點更多，數(shù)據(jù)量更大的情況下，查詢并不能利用集群的計算能力(對于很多復雜查詢來說，瓶頸出現(xiàn)在 CPU 上)，而且 MySQL 的 SQL 優(yōu)化器能力一直是 MySQL 的弱項，而且對于大數(shù)據(jù)量的查詢的 SQL 引擎的設計是和單機有天壤之別的，一個簡單的例子，分布式 Query Engine 比如 SparkSQL / Presto / Impala 的設計肯定和單機的 SQL 優(yōu)化器完全不同，更像是一個分布式計算框架。

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

Google Cloud BigTableGoogle

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

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

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

由于 BigTable 仍然不支持 ACID 事務，所以這里的強一致只是對于單 Key 的操作而言的。對于水平擴展能力來說， BigTable 其實并沒有什么限制，文檔里很囂張的號稱 Incredible scalability，但是 BigTable 并沒有提供跨數(shù)據(jù)中心(Zone)高可用和跨 Zone 訪問的能力，也就是說，一個 BigTable 集群只能部署在一個數(shù)據(jù)中心內(nèi)部，這其實看得出 BigTable 在 Google 內(nèi)部的定位，就是一個高性能低延遲的分布式存儲服務，如果需要做跨 Zone 高可用需要業(yè)務層自己做復制在兩個 Zone 之間同步，構(gòu)建一個鏡像的 BigTable 集群。

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

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

Google Cloud Datastore

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

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

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

其實 Cloud Datastore 在 2011 年就已經(jīng)在 Google App Engine 中上線，也就是當年的 Data Engine 的 High Replication Datastore，現(xiàn)在改了個名字叫 Cloud Datastore，當時不知道背后原來就是大名鼎鼎的 Megastore 實在是失敬。雖然功能看上去很牛，又是支持高可用，又支持 ACID，還支持 SQL(只不過是 Google 精簡版的 GQL)但是從 Megastore 的原理上來看延遲是非常大的，另外 Cloud Datastore 提供的接口是一套類似的 ORM 的 SDK，對業(yè)務仍然是有一定的侵入性。

Google Spanner雖然 Megastore 慢，但是架不住好用，在 Spanner 論文中提到，2012 年大概已經(jīng)有 300+ 的業(yè)務跑在 Megastore 上，在越來越多的業(yè)務在 BigTable 上造 ACID Transaction 實現(xiàn)的輪子后，Google 實在受不了了，開始造一個大輪子 Spanner，項目的野心巨大，和 Megastore 一樣，ACID 事務 + 水平擴展 + SQL 支持，但是和 Megastore 不一樣的是，Spanner 沒有選擇在 BigTable 之上構(gòu)建事務層，而是直接在 Google 的第二代分布式文件系統(tǒng) Colossus 之上開始構(gòu)建 Paxos-replicated tablet。

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

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

Google Spanner

目前沒有在 Google Cloud Platform 中提供服務，但是看趨勢簡直是一定的事情，至少作為 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)，可以像關系型數(shù)據(jù)庫那樣進行 DDL，雖然仍然要指定每行的 primary key，但是比簡單的 kv 還是好太多。

Google F1

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

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

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

F1 其實依靠 Spanner 的 ACID 事務和 MVCC 的特性實現(xiàn)了 100% 的 OLTP，并且自身作為一個分布式 SQL 引擎，可以利用集群的計算資源實現(xiàn)分布式的 OLAP 查詢。這帶來的好處就是并不需要額外在設置一個數(shù)據(jù)倉庫進行數(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 不太準確，現(xiàn)在應該是 Colossus)

Open source cloud-native database

2016 年在硅谷突然有個新詞火了起來 GIFEE，Google Infrastructure For Everyone Else，大家意識到好像隨著新一代的開源基礎軟件的繁榮發(fā)展，原來在 Google 內(nèi)部的基礎設施已經(jīng)有很多高質(zhì)量的開源實現(xiàn)，比如容器方面有 Docker，調(diào)度器方面 Google 主動開源的 Borg 的第二代 Kubernetes，傳統(tǒng)的 BigTable 和 GFS 社區(qū)還有雖然屎但是還是能湊合用的 Hadoop，而且很多大廠覺得 Hadoop 屎的都基本自己都造了類似的輪子... 更別說最近 Google 開源上癮，Kubernetes 就不提了，從大熱的 Tensorflow 到相對冷門但是我個人認為意義重大的 Apache Beam(Google Cloud Dataflow 的基礎)，基本能獨立開源的都在積極的擁抱社區(qū)。

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

目前從全球范圍內(nèi)來看，我認為開源世界只有兩個團隊：一個 PingCAP 的 TiDB，一個 CockroachLabs 的 CockroachDB 是有足夠的技術能力和視野能將 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)提供水平擴展能力，正在成為新一代分布式 KV 存儲標準架構(gòu)。另外也很欣喜的看到竟然是由一個國內(nèi)團隊發(fā)起并維護的這樣級別的開源項目，即使放到硅谷也是***的設計和實現(xiàn)，從 Github 的活躍度和使用的工具及運營社區(qū)的流程上來看，很難看出是一個國內(nèi)團隊。

Kubernetes + Operator

剛才提到了一個詞 Cloud-Native, 其實這個詞還沒有準確的定義，不過我的理解是應用開發(fā)者和物理設施隔離，也就是業(yè)務層不需要再去關心存儲的容量性能等等一切都可以透明水平擴展，集群高度自動化乃至支持自我修復。對于一個大規(guī)模的分布式存儲系統(tǒng)來說人工是很難介入其中的，比如一個上千個節(jié)點的分布式系統(tǒng)，幾乎每天都可能有各種各樣的節(jié)點故障，瞬時網(wǎng)絡抖動甚至整個數(shù)據(jù)中心直接掛掉，人工去做數(shù)據(jù)遷移，數(shù)據(jù)恢復幾乎是不可能的事情。

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

不過 Kubernetes 上對于有狀態(tài)的服務編排是一件比較頭疼的事情。而一般的分布式系統(tǒng)的特點，他不僅每個節(jié)點都有存儲的數(shù)據(jù)，而且他還要根據(jù)用戶需要做擴容，縮容，當程序更新時要可以做到不停服務的滾動升級，當遇到數(shù)據(jù)負載不均衡情況下系統(tǒng)要做 Rebalance，同時為了保證高可用性，每個節(jié)點的數(shù)據(jù)會有多個副本，當單個節(jié)點遇到故障，還需要自動恢復總的副本數(shù)。而這些對于 Kubernetes 上的編排一個分布式系統(tǒng)來說都是非常有挑戰(zhàn)的。

Kubernetes 在 1.3 版本推出了 Petset ，現(xiàn)在已經(jīng)改名叫 StatefulSet， 核心思想是給 Pod 賦予身份，并且建立和維護 Pod 和 存儲之間的聯(lián)系。當 Pod 可能被調(diào)度的時候，對應的 Persistent Volume 能夠跟隨他綁定。但是它并沒有完全解決我們的問題，PS 仍然需要依賴于 Persistent Volume，目前 Kubernetes 的 Persistent Volume 只提供了基于共享存儲，分布式文件系統(tǒng)或者 NFS 的實現(xiàn)，還沒有提供 Local Storage 的支持，而且 Petset 本身還處于 Alpha 版本階段，我們還在觀望。

不過除了 Kubernetes 官方社區(qū)還是有其他人在嘗試，我們欣喜的看到，就在不久之前，CoreOS 提出了一個新的擴展 Kubernetes 的新方法和思路。CoreOS 為 Kubernetes 增加了一個新成員，叫作 Operator。Operator 其實是一種對 Controller 的擴展，具體的實現(xiàn)由于篇幅的原因我就不羅嗦了，簡單來說是一個讓 Kubernetes 調(diào)度帶狀態(tài)的存儲服務的方案，CoreOS 官方給出了一個 Etcd-cluster 的備份和滾動升級的 operator 實現(xiàn)，我們也在開發(fā) TiDB 的 operator, 感興趣的可以關注我們的 Github 及微信公眾號了解***的進展。

作者介紹

黃東旭，PingCAP 聯(lián)合創(chuàng)始人/CTO, 資深 infrastructure 工程師，擅長分布式存儲系統(tǒng)的設計與實現(xiàn)，開源狂熱分子，著名的開源分布式緩存服務 Codis 的作者，對于開源文化和技術社區(qū)建設有獨到的理解。