工程師筆記：我對資料庫系統雲原生化的一些思考

作者 | 張敏（於期） 阿里雲智慧高階技術專家

劃重點

• 我眼中的雲原生

• 我認為的雲原生關鍵能力

• 我眼中的雲原生化技術手段

• 我對資料庫雲原生化的思考

伴隨著雲原生技術越來越熱門，阿里內部關於 CloudNative、Serverless 等相關文章和討論非常多。不過，我發現無論是外部開發者還是阿里內部，對雲原生定義、理解及實踐還處於探索階段，還沒有一個明確通行的標準化定義。

本文嘗試著對大家的各種討論，實踐，按通俗易於理解的方式加以總結，包含雲原生的定義，特徵，技術能力要求及當下集團圍繞雲原生目標而在做的一些事情，最後基於對雲原生的一點理解及市場的機遇，對雲原生時代下的資料庫系統談下個人的一些粗淺思考。

01

我眼中的雲原生

雲端計算的出現與虛擬化技術的發展與成熟密不可分。基於虛擬化技術，雲端計算可為使用者提供具有彈性的計算、儲存、網路及其它基礎資源服務，隨著發展還提供了各類雲產品，如：資料庫、中介軟體等，基本上企業執行中所依賴的各類軟體在雲上都有相對應的產品。

用過雲產品的人知道，雲上提供的產品就像一塊塊獨立的積木，還需要你自己動手拼接組裝，能否搭建出穩定牢固的底座取決於你對產品是否熟悉，還是有一定的技術門檻，除此外執行過程中某塊積木壞了，需要依賴人工進行介入，通過平臺發起替換或修復。

總之企業可通過雲提供的產品快速完成應用搭建，通過上雲可把更多精力專注在業務上，但云計算要像水電煤氣一樣成為社會運轉的基礎設施，還有很多需要提升的地方，這裡引發了大家對下一代雲端計算，也就是雲原生架構的思考與定義。提到雲原生，不得不提雲原生後面的最大推手
CNCF（雲原生基金會）。目前，CNCF 已經完成了對雲原生的初步定義併發布了 CloudNative Definition v1.0版本：

Cloud native technologies empower
organizations to build and run scalable applications in modern, dynamic
environments such as public, private, and hybrid clouds. Containers,
service meshes, microservices, immutable
infrastructure, and declarative APIs exemplify this approach. These techniques
enable loosely coupled systems that are resilient,
manageable, and observable. Combined with
robust automation, they allow engineers to make high-impact changes frequently
and predictably with minimal toil.

CNCF 列舉了一些關鍵的實現手段，包括容器、服務網格、微服務、不可變基礎設施和宣告式 API，這些技術能夠構架容錯性好，易於管理和便於觀察的鬆耦合系統。
而 Serverless 作為雲原生領域中的一個細分技術，直譯為“無伺服器”，核心思想是讓使用者只關注於業務開發，平臺自身提供部署，自動化運維，高可用及資源彈效能力，使用者只為實際使用的資源付費。同樣 CNCF 也對 Serverless 概念，適用場景等進行了定義，認為完整的 Serverless 服務包含 FAAS 和 BAAS 兩種形態：

A serverless computing platform may provide
one or both of the following:
1.Functions-as-a-Service (FaaS), which
typically provides event-driven computing. Developers run and manage
application code with functions that are
triggered by events or HTTP requests. Developers deploy small units of code to
the FaaS, which are executed as needed as discrete actions,
scaling without the need to manage servers or
any other underlying infrastructure.
2.Backend-as-a-Service (BaaS), which are
third-party API-based services that replace core subsets of functionality in an
application. Because those APIs are provided as a service
that auto-scales and operates transparently,
this appears to the developer to be serverless.

來源：https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview
抽象總結：FAAS 的典型代表就是 AWS Lambda，OpenFaaS 等開源專案，以及阿里雲函式計算產品。而 BaaS 的範疇則更廣泛比如未來雲原生的資料庫或者儲存服務。

02

我認為的雲原生關鍵能力

根據 CNCF 對雲原生定義的參考及基於我自己的理解，雲原生希望達成的目的是能夠讓雲上的服務能最大程度的發揮出雲的價值，從而讓雲的使用者能最大程度的受益於雲的能力，除此外還需要關注成本，相比自建成本足夠低時才能吸引使用者遷移到雲上。

為達成這個目標，從應用軟體架構的設計，開發，構建，部署，交付，容量，監控及運維等整個應用生命週期各環節都需要被重塑，總結下來雲原生需具備的一些能力或特性：

關鍵技術

• 彈性伸縮性：根據業務負載自動伸縮，做到秒級擴縮容能力，靈活動態分配或釋放資源，結合彈性計費策略，這是降低使用者費用重要手段之一，對服務而言需要的關鍵技術點，就是服務本身的輕量級容器化和以此為基礎的“不可變基礎設施”特徵。

• 自動容錯性：當機遷移，故障隔離，異常流量自動排程，負載均衡，自動限流降級等。

• 安全隔離性：發揮規模效應，降低使用雲的成本，計算，儲存，網路等資源採用共享池化技術，以提高資源利用率，因此雲產品在設計時必須要考慮多租戶的安全隔離性，避免資訊洩露或受攻擊，除此外還有隔離的穩定性。

• 釋出穩定性：為應對頻繁變更帶來的穩定性風險，需建立無人值守的變更釋出系統，具備自動化的灰度、分批等釋出策略，同時建立變更前中後的監控基線，具備異常變更的熔斷和自動化回滾能力。

• 可觀測性：豐富且細粒度的監控指標，秒級監控能力，可持久化的提供查詢。

• 易於管理：需要從自助運維到自動運維的轉變，具備自動化異常分析診斷能力，無需登入伺服器。

• 彈性計費：支援按量（如流量，儲存量，呼叫次數，時長等）、固定的如年/月/日/時…等多種定價策略，可根據業務情況靈活動態切換匹配出一個最優計量模式。

• 極致體驗：包括應用分配/建立/資源申請/環境配置/開發測試/釋出/監控報警/排障定位等需要做到通暢與簡單，一站式體驗，避免繁雜的搭積木式操作。

• 鬆耦合/移植性：鬆耦合，可移植性也是雲產品追求的設計理念，避免單個產品輸出需要整站搬遷的事情出現，那麼這裡就包含環境和系統依賴的解耦，跨平臺的移植等，需具備標準化API介面抽象能力。

趨勢的把握

• 混合雲支援：公共雲當前還存在安全等問題的挑戰，特別對於傳統企業還面臨心智上的轉變，但為了消除在這波數字化轉型程式中而被遺棄的焦慮，所以企業非核心試水公共雲，核心業務專有云或私有云部署的混合雲模式過渡態，為做到混合雲下對業務的透明訪問及支援未來往公共雲上的平滑遷移，因此產品需保持雲上雲下一套體系的設計原則。

• 多雲選擇：客戶基於風險，靈活性，話語權，甚至一些行業法規等因素考慮，部分企業可能會選擇多家雲平臺部署，這是一個不能忽視的潛在趨勢。為消除客戶因技術耦合而被捆綁的顧慮，導致市場被瓜分，同時也為能吸收友商所流失的客戶，所以雲產品設計之初需具備開放的心態，相容開源生態標準或一些較成熟的商業軟體，保持與客戶技術棧保持相容，具體來說就是擁抱 CNCF，掌握主動權。

• 邊緣計算：隨著海量終端的出現以及 5G 等網路基礎設施的升級，傳統“中心-終端”架構會面臨高併發，大流量及高時延的挑戰，為應對此挑戰提出了“中心-邊緣-終端”架構，將中心的計算、儲存等服務能力下沉到邊緣，而終端的業務邏輯上移到邊緣，目前雖然關於邊緣計算的定義和標準尚未清晰，但從之前接觸過的幾個外部專案觀察，客戶已經對雲邊端協同提出了需求，最先感知的就是能源、製造及風電等行業，因此雲產品還需相容並考慮到雲邊端一體化的設計。

03

我眼中的雲原生化技術手段

為了支援雲原生的這些關鍵能力，CNCF 也列舉了一些關鍵的實現手段，包括容器、服務網格、微服務、不可變基礎設施和宣告式 API。

下面結合集團和螞蟻上雲過程中目前正在做的一些實踐，嘗試著做一些簡單描述與總結，讓其看起來更有些體感，這些事情主要集中在應用層面。

擁抱Kubernetes，整合 Kubernetes

宣告式的API與可擴充套件的程式設計介面，使其處於容器編排領域的領導者定位，成為容器平臺的事實標準。而當前阿里集團也是“All in Kubernetes”，開始全面推進集團業務的 Kubernetes 化以實現“集團上雲”。通過採用 Kubernetes 平臺，與雲原生靠攏，使基礎設施更加標準化，複雜度降低，從而加速技術的演進，同時 Kubernetes 也簡化了應用混合雲，多雲，邊緣雲的部署成本。

輕量級容器化

當前很多團隊是把容器當做 VM 在用，這種模式嚴重阻礙了基礎架構的演進，使釋出/升級/擴縮容彈性/容錯等變得極為困難（富容器裡面太多依賴的東西，有太多不確定性因素，不敢動的），同時與環境的強耦合使得移植性較差，因此目前也是結合 Kubernetes 的能力推動輕量級容器化改造（如應用日誌去狀態化，去 IP 依賴，去 ssh 登入，應用映象瘦身-非業務程式剝離到 sidecar，基礎運維能力下沉等），通過這波改造會帶動整個上下游系統實現面向終態化和不可變基礎設施的升級（本質上就是應用容器確定性，一致性，輕量性）。

安全容器

由於應用埠號佔用的一些限制，不得不獨佔物理機，虛擬化技術的出現使得機器資源利用率得到一定提升，但ECS不具備記憶體超賣能力，而且規格不靈活，加上 VM 技術自身的一些開銷，因此整體來說資源利用率還不是很高，直到容器的出現，記憶體可超賣了，且規格變得非常靈活，使得混部密度進一步提高，資源利用率大幅度提升（其實還有離線上混部，核心的隔離，精細化的排程等綜合結果，不過容器化技術是前提）。

普通的容器技術雖然輕量，但在安全隔離上不能滿足多租戶的訴求，而 ECS 雖然提供安全的隔離能力，但啟動速度慢，不滿足彈性伸縮的需求。因此安全容器技術就運用而生，結合了虛擬化的強隔離和容器的輕量級，比如 KataContainers，Google 開源的 gVisor 和後來 AWS 開源的 FireCracker 都是其中的代表。集團和螞蟻共建的 NanoVisor（做了很多安全加固和效能優化），阿里在 KataContainers 基礎上開發的“袋鼠安全容器”，也都是這方向上的探索。

ServiceMesh

把一大堆和業務邏輯無關的實現如服務發現，路由，負載均衡，限流降級等從業務應用中剝離出來，下沉到基礎設施的中介軟體(類似 TDDL 到 DRDS 的模式)，這種剝離收益使得應用與服務提供者解耦，減少系統變更帶來的風險，同時更加利於全域性服務治理/監控等，除此外還獲得了另外一個收益就是應用瘦身，間接加快了啟動速度，還有就是對多語言的支援。

日誌無盤化

日誌直接落入SLS，是解決應用去狀態化的一個關鍵手段，成為不可變基礎設施的重要前提，其次集中式的日誌儲存與查詢服務，避免因 ssh 登入伺服器而帶來的穩定性隱患。目前螞蟻團隊正在推進打造日誌無盤化專案，打造的分散式檔案系統，直接 mount 目錄寫入 NAS，SLS 直接去 NAS 讀（SLS 與 NAS 底層儲存系統都是盤古，這裡應該是有優化的，具體細節不太清楚，如有錯誤還請指正），顯然相比常規寫本地磁碟然後讀一遍採集到 SLS 的方式，螞蟻的方案更優。

應用啟動加速

應用啟動的提速對彈性非常關鍵。一些關鍵的瘦身手段如之前介紹的去富容器、ServiceMesh 技術，這裡沒提到的應用自身更細粒度微服務的改造等帶來啟動的優化外，中介軟體團隊提供的 CSE 方案，在不改變映象情況下，利用應用熱複製技術將啟動速度加速到了毫秒級，類似的加速技術相信後面會更多。

WebIDE

提供了雲端構建、執行、除錯的的環境，使得研發同學可以實現函數語言程式設計，部署，測試和釋出一體化體驗，提升了研發效率。

計量計費

從面向基礎設施資源轉向雲產品的計費模式，同時要打造面向大型企業客戶的資源管理解決方案，要處理多種複雜的業務形態如混部等，整個計量系統非常複雜，這塊細節不是太瞭解，就不展開了。

04

我對資料庫雲原生化的思考

應用層的形態差別太大，缺少標準與自動化的手段，且隨著系統複雜性的上升，業務同學很大的時間在解決各種系統的對接與學習上，換了一個平臺或系統又得重新來過，實際用到業務程式碼的開發時間被擠壓得非常少，而不得不利用晚上加班填補，從上面解決問題中看到雲原生也集中在應用層解決開發效率的問題。

對於資料庫系統來說，相對而言基本通過 SQL 介面已經把後端實現遮蔽掉了，業務不用關注資料庫的機器，高可用切換等，負擔可能會小很多，那資料庫的雲原生到底是啥，解決什麼問題呢？

從 AWS 推出的各種雲資料庫產品來看更多的在於強調彈性與按需付費的結合上，如果單從這些方面觀察感覺資料庫雲原生略顯單薄，而且貌似已經具備 Serverless 的某些特徵。

因此想從另外一些視角來闡述下當下我對資料庫系統雲原生的理解，當然也是圍繞前面章節中所總結的雲原生關鍵能力展開的，同時結合之前在資料庫團隊參與過一小段時間商業化過程的思考，談談個人的一些粗淺看法，但類似利用機器學習在資料庫智慧化及索引、查詢優化上的應用等不在本文討論範圍中，主要還是聚焦在一些具象問題的討論。

開源 VS 閉源

雲原生核心的推動力就是防止被廠商鎖定，而 CNCF 則是這個領域維持中立與平衡的事實標準。CNCF 中的核心專案和雲原生的理念，已經影響了很多使用者的心智，所以我建議資料庫也要建立雲原生生態和認可的標準，這樣會為前線架構師節省很多教育使用者的成本。當然開源自身不是目的，最主要的是把雲上多年積累的技術經驗藉助開源賦能全社會，打造以阿里雲資料庫產品為標準的生態體系。

HTAP 能力的支援

簡單的增刪改查已不能滿足線上業務的需求，兼具一定OLAP分析能力是接下來HTAP資料庫發展的新方向。技術層面上我不認為單一的行列混合儲存引擎是未來（Google Spanner 這麼用的，簡單說就是 page 邏輯切分為多個 mini page，record 按列切分到不同 mini page 中，可看論文），同一個叢集混合行存和列存例項，Paxos/Raft 協議實現一致性複製，列存引擎提供 AP 查詢（計算引擎可以再基於 spark 等），這才是我認為的 HTAP 未來架構，當然這只是效能優化層面的解決方案，更多的還需做體驗上的優化，如何做到使用者 SQL 與底層能力的自動匹配很關鍵，無需使用者標註，那麼優化器能力的升級一定未來一個重要課題，根據 Query 特點自動根據 SQL 選擇行存還是列存，或部分行存部分列存。

Scale out 的分散式 VS Scale up 的單機資料庫，融合是趨勢。

以 AWS Aurora、阿里雲 PolarDB 及騰訊 CynosDB 為代表的單機資料庫，通過儲存與計算的分離，使資料庫去狀態化，可根據負載自適應的對計算或儲存資源線上彈性伸縮，這是目前大部分市面上宣稱的 Cloud Native Database，幾個關鍵詞：安全，易管理，高效能，高可靠，彈性擴充套件，自運維，相容 PG/MySQL/Oracle。

而以 NewSQL 為代表的新型關係型分散式資料庫，因具備傳統單機關係型資料庫 ACID 特性，提供 SQL 訪問協議，同時基於一體化設計，零外部的元件依賴，實現自動選主與切換，自動水平擴充套件與負載均衡，使產品整體上具備自封閉能力，可大大降低運維複雜度，穩定性上更加可靠，因此被定義為下一代關係型資料庫系統，此類產品有 Google Spanner，阿里雲的 PolarDB-X，螞蟻的 OceanBase，百度的 CRDB，開源產品 TiDB 和 CockroachDB。而細心的讀者發現，或使用者能 get 到的資訊就是兩類產品都類似啊（懂行的人肯定知道差別，只是外在表現類似），彈性擴充套件、自運維…，我到底怎麼選擇？

既然雲服務的最大特點是使用者只關注業務邏輯（業務 SQL 拼接，表結構設計），那麼顯然答案就非常簡單了，複雜的選擇全部留給雲廠商，再者單機系統自身就是分散式系統的一個特殊形式而已，那麼我覺得兩者的融合是趨勢，兼具單機系統的易管理、儲存計算分離的 Scale out 和去狀態化，水平擴充套件的分散式能力，再加上自運維能力，應該是後續資料庫的一個重要演進方向。

預設或大部分情況下是單機形態（市場上大部分單機資料庫足夠了），根據業務負載自動支援彈性線上 Scale out 或 Scale up 能力，不過這裡面臨的一個挑戰就是單機向分散式過渡的相容能力，包含但不侷限於：事物、隔離、併發控制、SQL 支援、效能，甚至包括 BUG 和 feature 的一致性等，因為使用者的 SQL 和表結構定義不變，一旦遇到相容性問題，反饋給使用者的就是報錯。

問題之所以是問題，肯定是有一定的技術門檻，不過從側面上也反應了其核心競爭力，這是可以與友商或競品拉開代差的產品，所以我相信融合是未來的方向。

成本優化

儲存計算分離是去狀態化的標準方案，毫無例外資料庫也藉助了儲存計算分離具備了與應用同等的彈效能力，通過資料庫藉助大量的軟硬體一體化設計與優化等（如使用者態檔案系統，使用者態儲存網路 IO 技術 SPDK 與 DPDK，RDMA 網路技術，新硬體 NVMe SSD、3D XPOINT），使資料庫在儲存計算分離下達到甚至超越了本地磁碟的效能（在阿里雲智慧事業群合併前，集團資料庫團隊也藉助盤古完美支援了大促，可見效能已然無需質疑），隨著技術的發展，這些硬體成本會逐步降低，加上阿里雲的規模效應，管理成本的收益等，所以資料庫儲存計算分離一定是當下綜合評估後的最優方案，之前已列舉了一些有代表性的產品 Aurora/PolarDB 等。

同時根據上個觀點的判斷，下一代關係型資料庫也具備彈性計算分離形態，那麼資料庫的 3 副本與儲存的 3 副本共 9 份副本，顯然不符合雲對成本優化的要求，目前儲存通過 EC（Erasure Coding）技術可做到單副本 1.375 儲存成本，再加上壓縮技術等方案可進一步降低成本，但實際上這裡還有很多的考量，就不再展開了。資料庫多副本+儲存計算分離也是一個新方向，成本優化的問題雖然有一些解決方案，但是我認為還處於初步的實踐探索階段，相信未來一定會更加完善。

隨著 lsm-tree 的引擎引入，為分層儲存，冷熱分離的實現提供了技術可行性，不過冷熱資料的評估，業務查詢的不確定性等可能會帶來一定挑戰，一旦遇到效能波動可能就會遭受質疑，不過相信技術的力量。資料庫團隊打造的 X-Engine 儲存引擎就是為了解決這個問題而因運而生的。

建立生態

多個場合聽到或看到阿里雲對客戶打法的一些定義：頭部客戶靠直銷和生態，腰部客戶靠生態渠道，尾部主要靠市場口碑體驗驅動，前不久阿里雲北京峰會上顛總提到的體術->產品->商業->生態的論述，可見生態對於雲的重要性，得生態者得天下。雲面臨的困難在逐步轉移，從開始的不知道做什麼，做出來怎麼買，目前面臨著怎麼做服務的問題了，對資料庫這種具有一定門檻的領域來說更多體現在交付和售後支援的生態建設上，除了前面提到的建標準，產品的收斂融合等可以幫助到生態的建設外，保持被整合的設計理念也很重要，具體來說就是 API 介面的能力，除此外可能還需探索更多的辦法，任重而道遠。

打造資料庫自治化生態

資料庫產品面臨的一個很大問題就是種類太豐富了，以至於客戶迷茫，架構師也迷茫，能清楚定義出各產品的核心功能及特點真不是一件容易的事情，同時客戶在架構師的幫助下選擇了n多資料庫產品分別滿足各業務場景需求，對後期整體的維護成本簡直就是一個災難。

回到雲原生的本質，使用者只關注 SQL 和定義表結構，剩下的就交給雲廠商，顯然與理想狀態差距太大。而云廠商需要努力通過技術手段去解決這個問題，資料庫產品收斂融合我認為是一種比較好的方案，收斂為三個產品是一種理想狀態（OTLP 領域，OLAP 領域，NoSQL 領域），多模資料庫/HTAP 等已經體現了這麼一種趨勢的探索和實踐，依靠產品的收斂解決了很多痛點問題，而且也是相對能落地的方案。但作為雲原生資料庫肯定不甘於此，還是需要暢想下未來，能根據業務特點及負載匹配到最適合的資料庫產品，自動完成資料的遷移且對業務透明（體現在遷移無感知，使用者使用無感知），使用者與資料庫互動的唯一介面就是管控平臺和查詢語言 SQL，只要 這些介面 不變，在一個靜態的狀態下返回的結果一定是確定性的，不同的是給到使用者更快的體感。那麼這才是我認為的未來的雲原生資料庫，一個自治化的資料庫生態體系。

還有一些其他方向，就不詳細說明了，如：運維能力以 Operator 形式下沉至 Kubernetes。當然之前的模式也需要相容的，畢竟不是外部所有客戶基礎設施都是 K8s，智慧化管控運維、加密資料庫，混合雲/多雲/邊緣雲等產品化支援等。

05

總結

以上就是我這段時間對雲原生，資料庫在雲原生時代下的一些個人思考，內容略顯囉嗦，能看到最後的肯定是真愛，同時文中對雲原生的理解難免存在不當之處，歡迎大家指正與交流。關於雲原生的定義和特徵也在不斷變化和調整中，同時隨著雲端計算普及，相信最終會逐漸明朗。

本文編輯

李飛飛（飛刀） 

阿里雲智慧高階研究員

達摩院首席資料科學家

資料庫產品事業部負責人

張磊

阿里雲智慧容器平臺高階技術專家

Kubernetes 社群資深成員與專案維護者

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31555606/viewspace-2644227/，如需轉載，請註明出處，否則將追究法律責任。