10 月 18 日~ 20 日，第 12 屆中國資料庫技術大會（DTCC2021）在北京國際會議中心隆重召開。PingCAP 聯合創始人兼 CTO 黃東旭受邀在主會場進行了以“TiDB Cloud：from Product to Platform” 為主題的演講，分享了雲原生時代資料庫產品平臺化的重要性，以及 TiDB 從 DB 到 DBaaS 的經驗和體會。以下為分享實錄。
在最近資料庫行業的發展中，比起 “程式碼寫得好不好” 這樣的工程技術問題，科學問題更加突出：有一件事情非常深刻地改變了整個資料庫的行業，那就是資料庫底層發生了變化。
以往大家去思考資料庫軟體和系統軟體，都會先做一個假設：軟體是跑在計算機等具體的硬體上的，即使是分散式資料庫，每個節點都還是一個普通的計算機。現在這個假設改變了：我們的下一代到能夠學程式設計或者寫程式碼的年紀，不會再像我們現在這樣能夠看到 CPU、硬碟、網路，他們看到的可能就是 AWS 提供的一個 S3 的 API 。其實這種改變並不僅是軟體載體的改變，更重要的是架構、程式設計的底層邏輯發生了變化。
雲對基礎設施和軟體的影響和改變是深遠的。具體到 PingCAP 身上，最大的感受就是比起做資料庫核心， 現在在雲上做 TiDB Cloud 服務的投入可能多得多。這也是我今天要分享的主題，From Product to Platform —— 從 DB 到 DBaaS，資料庫技術的當前和未來。
PingCAP 的創業初心
上圖是我理解的資料庫發展歷程。追溯到十幾年前，我們開始使用單機 MySQL，這個時期我們對資料庫的需求只有樸素的增刪改查，2010 年前後直到今天，爆發的資料量讓單機資料庫難以為繼，大家只能通過分庫分表或者中介軟體來實現分散式部署。
然而分庫分表對業務的入侵性太大，那能不能有這樣一個資料庫，用起來和單機 MySQL 一樣簡單，但是擴容時不需要考慮分片，而是通過系統本身的機制來實現彈性、舒適、業務無入侵的擴充？這就是 PingCAP 創業的初心。
PingCAP 創業六年多以來，為了達成這個小目標，也總結了幾點心得：
易用優先：協議大於實現
MySQL 協議比 MySQL 具體軟體更重要。如果一款資料庫能夠相容 MySQL 協議，能讓使用者在資料庫的選型過程中無需考慮對應用和業務的影響，就能擁有最大的使用者群。我們無需發明一種新的使用方式，就像電動車還是會通過方向盤和油門來操控，雖然引擎下的世界和汽油車完全不同。
使用者體驗優先
資料庫的效能指標比如 TPS、QPS 等固然重要，但是使用者的體驗才是一款資料庫成功的關鍵。因此，TiDB 在做所有技術決策的時候都是通過使用者體驗（Usability matters）來判斷。從我過去的經驗來看，許多網際網路公司需要維護的資料庫種類非常多，每啟用一種新的資料庫就會多一個資料孤島。因此，在滿足使用者資料處理需求的同時，簡化的技術棧可能才是真正的使用者痛點。無論是 OLTP、OLAP 還是 HTAP，TiDB 希望做的事就是讓大家的生活變得好一點。
開源優先
PingCAP 始終堅持開源戰略，也因此受益頗多。
從生態角度，開源的研發模式能夠迅速積累使用者。TiDB 1.0 版本 2017 年 11 月釋出，從誕生到現在，我們知道名字的使用者有 2000 多家，貢獻者有 1500 多個，CNCF 開源組織的 Contribution Rank 中，PingCAP 排名全球第六。
從技術角度，開源加速了產品的迭代速度。這張圖的縱軸是程式碼量，橫軸是時間，不同色塊是代表某一年寫的程式碼量。從圖中我們能夠看出，基本上每年 TiDB 的程式碼都在被重寫，幾乎沒有一年是跟去年的程式碼一樣。這個迭代的速度就是通過開源社群來實現的，是任何一個團隊、任何一個公司、任何一個企業從頭開始做一個資料庫都無法達到的進化速度。
Why DBaaS
TiDB 的產品能力不是今天分享的重點，我今天想談的是把一個產品變成雲服務到底有多重要。首先丟擲一個最終結論，現在這個時代對 CIO 尤其是海外的客戶來說，資料庫產品對雲的適配成為了一個必選項。
現在我們正好站在時代的交界點上。從技術上來講，資料庫的發展就是從 Standalone（單機）到 Cloud-Native（雲原生）的程式。現在我們處在第二條紅線的位置，就是從 Shared-Nothing 到 Cloud-Native 的邊界。從商業角度看，整個資料庫和基礎軟體行業的商業模式也正在發生特別大的變化：過去我們希望通過售賣 license 進行私有化部署，到現在希望能夠實現規模化的擴張，這也正是 On-Prem 到 DBaaS 變革。
作為一家成功將資料庫商業化的公司，MongoDB 走出了一條很有代表性的道路。MongoDB 每年的市值都在翻番，現在已經到達了 300 多億美金。從 MongoDB 的財報可以看出，DBaaS 產品 MongoDB Atlas 基本上每年都保持著超過 100% 的年複合增長率，這就是雲服務的價值所在。
TiDB 在雲上的平臺化之路
最近兩年我也重新定義了一下我們的願景和使命：全世界的開發者享受到我們的服務，Anywhere with Any Scale。
想要實現這個目標，從 DB 到 DBaaS 是個必選項。只有雲上的服務才能突破地域的限制，並提供無限的算力。從 DB 到 DBaaS，遠不止將底層資源換成雲這麼簡單，需要考慮的還有很多。技術上，要實現降本增效、運維自動化、多租戶管理，合規上要考慮資料安全，商業上，計價模式、商業化策略等都是需要納入考慮的範圍。接下來我將從技術角度談談 TiDB 在 DBaaS 程式中付出的努力。
成本節約：分離的架構設計
雲原生技術最終要解決的就是成本的問題。
在過去，TiDB 有一個 TiDB + TiKV 的協處理引擎，計算和儲存的邊界是非常模糊的，很難處理不同負載率的場景。本地部署的情況下，如果需要增加儲存容量，就需要增加儲存節點，因為硬體的限制，除了磁碟，CPU 及網路頻寬也會同步增加，這就造成了資源的浪費，這是所有 Shared-Nothing 的資料庫都要面臨的問題。
而到了雲上，一切就截然不同。比如 AWS 的塊儲存裝置的服務 EBS，特別是 GP3 系列，能夠在不同的機器上執行，且達到同樣的 IOPS 和 Cost，效能和對雲原生的整合都非常好。為了利用 GP3 的特性，我們是否可以把計算和儲存的邊界往下移，從原來的 TiKV 到儲存，到現在 TiDB、TiKV 的大部分都可以是計算單元，更加靈活。
雲帶來的成本節約不止於此。雲上真正值錢的東西是 CPU，瓶頸會是計算，而不是容量。叢集和例項可以基於資源共享池進行優化（Spot instances & Clusters based on shared resource pools）、按需選擇儲存服務的型別、對不同型別的 EC2 例項在特定場景組合交付、無伺服器計算、彈性的計算資源都將成為可能。
此外，根據我的判斷，除了計算儲存分離，網路、記憶體，甚至 CPU 快取都會是分離的。因為對一個應用程式來說，尤其是分散式程式，硬體資源的要求是不一樣的。不管是做什麼業務，就像做菜一樣，手上只有一顆菜肯定做不出什麼花來，但原材料很多，就可以按照口味去做組合，雲帶來的就是這樣的機會。
安全性
除了成本，雲的安全性也是重要課題。TiDB 官方支援的公有云是 AWS 和 GCP。雲上網路使用者使用的都是自己的 VPC，中間也會有 VPC Peering 打通的環節，我們看不到使用者的資料，但使用者可以很高效能地訪問自己的業務，安全性要怎麼保證？
圖中是 TiDB 的安全體系，雲上的安全體系和我們雲下的思考完全不同。舉個特別簡單的例子：雲下只需要考慮 RBAC 資料庫內部的許可權，但在雲上就非常複雜，需要考慮從網路到儲存一整套的使用者健全安全的體系。做好雲上安全的關鍵點是千萬不要自己重複發明，因為基本都有安全漏洞。所以我們現在就是要充分利用雲本身提供的一套完整的安全機制，比如金鑰管理和規則等。當然，最好的地方都是這些服務都能夠明碼標價，只要做出計費模型就好了。
運維自動化
關於 DBaaS 的構建還有一點很重要，其實也和成本有關，就是運維自動化。雲是一個規模化的生意，而現在國內資料庫生意最麻煩的部分之一就是交付。一個大客戶恨不得派二十個人駐場，但這件事情可持續嗎？。我們要實現的就是可以通過 10 個人的交付團隊去支援有 1000 個客戶的系統，這是規模化的前提。
這些是 TiDB 自己的雲服務技術選型，通過 Kubernetes 實現雲上部署，通過 Gardener 進行聯邦管理，管控多個 Kubernetes 叢集，Pulumi 是一個基礎架構即程式碼的自動化工具。
Kubernetes
要把 TiDB 變成雲服務總共分為幾步？第一步就是人肉運維全部變成程式碼。TiDB 要擴容了，不要人肉擴容，系統自己能不能擴容？TiDB 故障恢復，人蔘與不了，機器能不能參與？我們把所有 TiDB 的運維全部變成了 Kubernetes Operator，相當於我們實現了自動運維 TiDB。Kubernetes 能夠遮蔽所有云廠商的介面複雜性，每個雲廠商都會提供 Kubernetes 服務。
Pulumi
剛才說過這些東西的部署、運維、排程的邏輯，如果都是靠人寫指令碼，一是不穩定，二是不可維護。我們的理念就是隻要能夠變成程式碼的東西就固化下來，千萬不要依賴人，包括去開一個伺服器，或者去買一個虛擬機器，我們都會把它變成 Pulumi 程式語言的指令碼。
Gardener
TiDB 通過 Gardener 的 API 來管控多個不同 Region 裡的 Kubernetes 叢集，每個 Kubernetes 叢集再去劃分不同租戶的 TiDB 叢集，形成一個多雲、多區域、多 AZ 的大的系統。這個架構有一個好處：使用者可以在自己應用程式所在的雲服務商和地理區域按需啟用 TiDB，保持技術棧的統一。
商業 SLA
SLA 裡面要考慮的東西也很多，這是 TiDB 要做的且正在做的東西。
TiDB 的海外客戶特別多，海外使用者對資料庫的需求與國內使用者有很大不同，跨資料中心是一個剛需。由於現在各國的資料安全需求，資料的傳輸有了諸多限制，合規的、跨資料中心的能力對資料庫來說十分重要。比如面對歐洲的 GDPR 管控，如果能把一部分資料就放在歐洲，不要出來，只有不在管控範圍內的東西能出來，就會省去很多麻煩。相信接下來這個能力對於中國的廠商和客戶，包括做出海以及在國內做合規都會變成剛需。
這個功能在雲上很容易實現，比如 AWS 本身就是多 AZ、多 Region 的架構，無需考慮底層，在另外一個資料中心開幾臺機器，使用者只需要在介面上點一下滑鼠資料就過去了，但對於無法在雲端部署的資料庫來說，如果要去處理全域性的資料分佈或者全域性 Transaction 和 Local Transaction，需要考慮的東西就多得多。
現在 TiDB 就是未雨綢繆，這項功能已經馬上就要釋出了。
想要在雲上提供服務，技術固然重要，合規是個前提。雲上的生態整合有一個主線，就是跟著資料走，資料的上游、下游和管控是最重要的三個點。TiDB 的上游就是 MySQL、S3 裡面的資料檔案，下游只需要支援與 Kafka 或其他訊息佇列服務的同步即可。在資料的管控層面，在雲上尤其是對海外使用者來說，比起通過資料庫廠商去做整體的管控，更希望和類似 DataDog、Confluent 這樣的平臺打通。
最後打個廣告，TiDB 在 Q4 會推出對開發者的為期 12 個月的免費體驗版，能夠快速部署，預設支援 HTAP 功能，通過容器實現計算隔離，同時具有專用的塊儲存，大家在雲上可以隨意使用。我們的網址是 tidbcloud.com，未來也會支援國內的雲，期待大家的體驗和反饋。
希望 PingCAP 能夠真正做到：讓全世界的開發者享受到我們的服務，Anywhere with Any Scale。