作者介紹

張雲楊，前阿里雲資料庫產品負責人，2016-2019 年任阿里雲資料庫產品總監，負責 RDS、PolarDB、Redis、MongoDB 等核心產品。目前作者就職於雲猿生資料，主要負責雲原生資料控制面 KubeBlocks 和 Serverless MySQL 產品。歡迎雲端計算或資料庫行業從業者加微信交流。

作者微信：realzyy

Addon 照進生命的一個上午

許多年之後，面對研發同事的口若懸河，我都將會想起，Tony 跟我解釋什麼是 addon 的那個遙遠的上午。

Tony 是一個美籍華裔 Infra 工程師，常年混跡於 KubeCon 和 HackerNews，痴迷於新的產品技術、健身以及佈道。在他的個人主頁上，Tony 是這樣描述自己的：長期主義者，喜歡仔細思考選擇最優解，喜歡學習新東西，保持客觀。如果沒有後面的故事，恐怕我永遠也無法注意到他描述自己的另外一段話：概括能力過於跳躍，handwriting disorder。

在北京出差的某個早上，Tony 的頭像意外地閃爍起來。一般來說，產品經理不太會引起 Tony 的興趣，雖然在同一個地區但是雙方的上班時間存在時差，並不支援淋漓盡致的輸出。畢竟，高階的噴子都要求極低的延遲。好奇的我沒管住該死的手，讓他關注到了飛書訊息的“已讀”狀態。在簡單寒暄兩句後，Tony 興奮地給出了一個文件連結，並要求評審。“Addon KubeBlocks  控制平面可選特性開關功能”，標題的 handwriting disorder 沒難住我，我知道他想寫的是“KubeBlocks Addon 定義以及功能提議”。但願裡面內容還行，我向產品之父蘇傑禱告。

天氣開始熱起來了，我看他打了杯冰美式，問到：“什麼是 addon？”

Tony 不客氣地問：“你是不是沒看我的文件？”

“那個文件沒寫明白”，我心裡這樣想，但是嘴上很慫：“我沒看懂。對於一個資料庫控制平面而言，可選特性的意義是變化的。比如說新的引擎版本，或者更細粒度的備份功能，或者更豐富的監控指標，對使用者而言都是特性上面的變化。如果 addon 的定義是可選特性，那哪些特性是必選的，哪些又是可選的呢？”

“比如，負載均衡、監控系統、儲存介面都是可選的，它們都是 addon。”

“如果我在阿里雲上面執行 KubeBlocks，ACK 提供的儲存介面是必選的，那它就不是 addon。而在亞馬遜上面執行 KubeBlocks，EKS 提供的儲存介面是可選的，那它又是 addon。按照定義，儲存介面到底是不是 addon？”

Tony 放下了咖啡杯。從 Motivation、Goals、Non Goals，到使用者故事、使用場景，再到開發和測試計劃，那個下午我獲得了很多，但是好像也失去了很多。

“不行，我一定要搞明白 addon 是什麼。”

這麼多聰明的人裡面，肯定有誰能解釋清楚。我不由自主地瞥了一眼巧克力。我們的 CTO，有著黝黑的皮膚和宜人的性格，就像巧克力一樣絲滑且有智慧。

“簡單來說，addon 是工作負載（Kubernetes Workload）的一種抽象”，巧克力解釋道：“本質是包含 ClusterDefinition、ClusterVersion、Script 和 ConfigMap 等資源的 Helm Chart，比如 KubeBlocks 接入的 OceanBase 就是一種 addon。”

雖然有點像抬槓，但是我脫口而出：“那什麼又是抽象呢？”

“在軟體工程領域，抽象是指從問題或系統中提取主要特徵和行為。透過抽象可以提高重用性和可擴充性，提升理解和研究問題的效率。”

“不愧是精通 ChatGPT 的男人”，我硬著頭皮繼續問道：“那 addon 作為一種抽象，它解決了什麼問題？”

“當你只開發一種資料庫服務的時候，每個功能都是獨特的；當你開發了一百種資料庫服務的時候，99% 的功能都是重複的。addon 作為一種抽象，就是找出了這 99% 的功能，以便研發團隊集中力量提高它們的質量。這樣大家都能過上幸福的生活。”

巧克力已經回到座位上了。我還在回味這個餅是甜的還是鹹的，感覺吃到了但是又有點餓。

我下定決心去打擾珊博。珊博是坡縣國立大學資料庫科班出身，獲得了學術大佬的真傳。Tony 的文件讓人形神俱滅，而珊博的文件旁徵博引，有種飽腹感。我讀了她的 Addon Tutorials 系列，4 萬字抄一遍剛好水一篇碩士畢業論文。別看我，我沒有。

“如果開發者在 KubeBlocks 上面沒有找到想要的資料庫引擎，他們可以選擇自己動手做一個 addon，part time 參與的話 10 個工作日內可以完成”，珊博推了推眼鏡：“addon 的製作分為三步。一是設計資料庫叢集的部署拓撲結構，二是設計資料庫叢集的引數模版，三是增加 addon yaml 配置檔案。具體來說，……”

我彷彿看見了大象緩緩走進冰箱，趕緊示意珊博暫停：“addon 好像是 KubeBlocks 0.5 就已經具備的功能，為什麼這兩天釋出的 0.8 裡面感覺它有點若隱若現？”

“這是個好問題”，珊博又推了推眼鏡：“KubeBlocks 0.8 把 addon 程式碼拆了出來，這樣就能支援兩邊按不同節奏來發布了。比如說，KubeBlocks 的釋出節奏是 1.5 個月一個大版本，如果使用者想要接入一個新的資料庫，他隨時都可以寫個新的 addon 併發布出來，再也不需要等 KubeBlocks 更新版本了。當然，還有其它的好處，比如說……”

吃不了抽象的苦，就要吃具象的苦，不爭氣的口水從眼角流下來。

Addon：一種高效、開放的擴充機制

上面這幾個虛擬的小故事，是真真正正發生在 KubeBlocks 的研發過程中的。過程沒有那麼魔幻現實主義，但是討論的激烈程度遠勝於文章，畢竟研發同學們的奇思妙想只有經過深入的拷問，才可能真正變成產品的特性。規劃趕不上變化的事情比比皆是，但也還是要在這不確定性中尋求確定性，正如在虛無縹緲的抽象理念中尋求具象的事實般重要。

所以，addon 到底是什麼？我們最終達成了一個共識：

addon 是一種高效的擴充機制。透過 KubeBlocks Addon，開發者可以在 10 個工作日內新增一種新的資料庫引擎到 KubeBlocks 中，並獲得該資料庫引擎特有的基礎管理功能，包括但不限於生命週期管理、資料備份恢復、指標和日誌採集等。

同時，addon 也是一種開放的擴充機制，是 KubeBlocks 與其它資料控制面軟體的重要區別。我們嘗試透過 addon 機制，定義資料控制面的接入標準，降低 Kubernetes 支援新資料庫引擎的難度，加速資料庫容器化的程式，並以此為基礎推動雲原生平臺的應用深度與廣度。這件事很難，但是做成了很有意義。

在具體實現上，addon 體現為儲存在 Git 倉庫裡面的 helm chart 安裝包，裡面包含了支援一個資料庫引擎所需要的拓撲資訊、配置資訊和操作指令碼。KubeBlocks 官方社群提供的所有 addon helm chart 原始碼都可以在  找到，安裝包則全部放在  的釋出裡面。開發者也可以根據需要，編寫新的 helm chart 或者改寫存量的 helm chart，提升 KubeBlocks 管理的資料庫引擎種類和體驗。

KubeBlocks 0.8 將存量資料庫引擎的 helm chart 從 KubeBlocks repo 分離出來，並採取了 Apache v2 的授權模式，預期可以帶來如下收益：

• 資料庫引擎種類和版本迭代，與 KubeBlocks 自身版本的迭代解綁。開發者不需要關注 KubeBlocks 的發版週期，隨時可以接入新的資料庫引擎或者版本，也方便終端使用者在存量 KubeBlocks 叢集上測試新的資料庫引擎/版本。

• 資料庫引擎的定義實現了多版本，降低了 addon 升級可能造成的故障風險。資料庫引擎的定義是一種“後設資料”，對後設資料的“更新”操作實際上會影響所有存量資料庫叢集。KubeBlocks 0.8 將後設資料的“更新”操作變成了“新增”操作，讓升級過程變得更加可控。

透過 addon 機制，KubeBlocks 社群已經支援了幾十種資料庫引擎，其中不乏一些優秀的國產資料庫，比如 OceanBase、PolarDB-X、OpenGauss。如果您是資料庫廠商，正在頭疼如何滿足客戶提出的“雲原生”訴求，可以嘗試使用 KubeBlocks 快速解決這個問題。如果發現不能滿足需求的地方，歡迎您聯絡我們提供幫助。 

開源合作：

商業合作：marcom@apecloud.com