作者 | 李仲玄，徐瑛

策劃 | 王一鵬

審校 | 冬雨

中間件是解決共性問題的標(biāo)準(zhǔn)化工具，是一種支撐技術(shù)，不可或缺。但因其種類多，數(shù)量大的特性，給運(yùn)維管理帶來了很高的難度。本次分享將介紹基于 Kubernetes 構(gòu)建的云原生中間件平臺架構(gòu),介紹 kubebuilder 的腳手架構(gòu)建流程,以及 Operator 的工作原理.并以數(shù)據(jù)庫為例，介紹在實(shí)際推進(jìn)的場景中遇到的問題與解決方案，同時(shí)也分享云原生中間件面臨的挑戰(zhàn)的思考與對未來的展望。

分享主要分為四個(gè)部分展開：第一部分中間件管理現(xiàn)狀；第二部分借助云原?優(yōu)勢，提供更好的管理；第三部分云中間件管理平臺架構(gòu)之路；第四部分未來展望。

本文整理自金蝶云蒼穹云原生部門高級研發(fā)李仲玄、金蝶云蒼穹云原生部門產(chǎn)品經(jīng)理徐瑛在DIVE全球基礎(chǔ)軟件創(chuàng)新大會2022的演講分享，主題為“金蝶云蒼穹云中間件管理架構(gòu)實(shí)踐”。

以下為整理內(nèi)容：

中間件管理現(xiàn)狀

中間件是為了解決復(fù)雜問題的支撐技術(shù)，在一般的軟件架構(gòu)中是不可或缺的一部分。它是研發(fā)利器，其定義非常廣泛，包含非常多種類型，常見的包括像數(shù)據(jù)庫中間件、消息隊(duì)列中間件，還有微服務(wù)組件中間件，可見中間件的特征是種類非常的多，涵蓋范圍非常廣，數(shù)量也非常大，這就給我們的管理上增加了難度。

中間件常用的管理方式主要有四種，分別是混合云、公有云、私有云和本地管理。這四種管理方式各有優(yōu)劣，像本地安裝包管理方式，它可以使用本地物理資源降低成本，但運(yùn)維都是純?nèi)斯さ?，通常都是直接使?span id="qsh1b7padf" class="candidate-entity-word" data-gid="474369">運(yùn)維腳本，運(yùn)維門檻就比較高，并且人工出錯(cuò)的概率比較大，整體運(yùn)維效率會比較低。

第二種私有云方式是建設(shè)一朵私有云，把整個(gè)中間件的資源和運(yùn)維都給管理起來，其劣勢在于，需要專項(xiàng)投入建設(shè)。

第三種公有云方式是把需要的資源和運(yùn)維能力完全托管到公有云廠商，我們可以減少運(yùn)維和資源管理這部分的麻煩，但是會和公有云廠商深入綁定，整個(gè)運(yùn)維狀況不是很透明，不是很了解底層到底是怎么樣的運(yùn)維狀態(tài)。

第四種是混合云方式，目的是希望能夠?qū)①Y源分布在多種云上，以降低整體的風(fēng)險(xiǎn)，其劣勢在于統(tǒng)一管理比較難。

上述四種管理方式共同的擔(dān)憂主要分為兩大類，一類是運(yùn)維管理，一類是成本控制。運(yùn)維管理主要圍繞著可用性、可靠性、性能優(yōu)化這幾類問題。而資源缺乏、人員配備的問題，都屬于成本控制類的問題。

解決這些擔(dān)憂的最終目的是要降本增效，我們認(rèn)為可以有以下四點(diǎn)去達(dá)到這個(gè)目的：

第一點(diǎn)是拒絕資源綁定，采用松耦合的架構(gòu)去屏蔽底層資源差異，從而降低成本，分擔(dān)風(fēng)險(xiǎn)；

第二點(diǎn)是資源池能夠彈性擴(kuò)縮，根據(jù)不同時(shí)期的業(yè)務(wù)需求進(jìn)行整體的擴(kuò)縮容，去滿足我們的業(yè)務(wù)需求；

第三點(diǎn)是運(yùn)維操作要簡單，做到可視化的部署、容災(zāi)、監(jiān)控分析、告警全生命周期的運(yùn)維管理；

第四點(diǎn)是高可用、高可靠的保障。

上述說的這幾點(diǎn)，我們運(yùn)用云原生都能很好地解決。

第一點(diǎn)松耦合，它剛好與容器契合，將中間件本身、應(yīng)用和它的配置打包成鏡像，能在不同的資源池上進(jìn)行，不同的環(huán)境上部署，通過容器編排工具可以根據(jù)申請的資源在資源池中選擇合適的節(jié)點(diǎn)調(diào)度、部署，輕松實(shí)現(xiàn)多實(shí)例面向混合資源池的部署。

第二點(diǎn)彈性擴(kuò)縮，它主要分為兩類，一類是資源池的彈性擴(kuò)縮，另一類是中間件自身利用的彈性擴(kuò)縮?；谫Y源池的彈性擴(kuò)縮，使用計(jì)算存儲分離架構(gòu)，我們可以去實(shí)現(xiàn)計(jì)算資源和存儲資源獨(dú)立靈活的擴(kuò)縮容，去滿足我們實(shí)際的業(yè)務(wù)需求?；谥虚g件應(yīng)用，也可按需實(shí)現(xiàn)中間件規(guī)格的擴(kuò)縮容。這兩種彈性擴(kuò)縮，我們都可以通過容器編排工具實(shí)現(xiàn)。

第三點(diǎn)是運(yùn)維操作簡單，需要具備快速發(fā)布部署、中間件的管理、異地容災(zāi)整個(gè)生命周期的可視化界面管理。基于容器中間件，自身就具有快速部署和發(fā)布的能力，能夠自動隔離故障結(jié)點(diǎn)，將應(yīng)用遷移至健康的結(jié)點(diǎn)，讓整個(gè)應(yīng)用系統(tǒng)具有比較強(qiáng)的資源能力，簡化運(yùn)維管理的復(fù)雜度。

最后一點(diǎn)是可觀測性，它不僅是中間件運(yùn)維平臺能力，還是所有運(yùn)維平臺都需要的能力，它就包含監(jiān)控、日志、告警等等一系列的內(nèi)容。云原生本身就有比較成熟的可觀測服務(wù)工具。

中間件本身是一個(gè)比較復(fù)雜的系統(tǒng)，運(yùn)維也比較煩瑣，部署、故障恢復(fù)、監(jiān)控、報(bào)警、測試都需要比較專業(yè)的運(yùn)維人員手動完成，不僅成本比較高，而且也可能會出現(xiàn)手工失誤。將中間件做成云服務(wù)的優(yōu)勢是運(yùn)維簡單容易上手，能夠高效實(shí)現(xiàn)大批量實(shí)例的自動化運(yùn)維。我們主要是一個(gè)三到六臺的小規(guī)模的 K8S 集群，主要分為 Master 節(jié)點(diǎn)跟 Node 節(jié)點(diǎn)，Master 節(jié)點(diǎn)是集群的控制節(jié)點(diǎn)，負(fù)責(zé)整個(gè)集群的管理和控制，基本上所有的控制指令都是發(fā)給 Master，并且由他來調(diào)度 Node 具體的執(zhí)行命令。Node 節(jié)點(diǎn)是工作負(fù)載節(jié)點(diǎn)，主要負(fù)責(zé)拉取容器。

我們使用的是聲明式 API，只給出最終的狀態(tài)，通過狀態(tài)機(jī)去協(xié)調(diào)，目標(biāo)系統(tǒng)就會對資源進(jìn)行操作以達(dá)到要求，調(diào)用者不需任何干預(yù)。其優(yōu)勢是讓分布式系統(tǒng)之間的交付變得簡單，不需要關(guān)心任何過程細(xì)節(jié)，這種方式也大大減少了使用者的工作量，極大地提升開發(fā)效率。

Kubernetes 現(xiàn)在已經(jīng)是比較流行的云原生分布式操作系統(tǒng)，其最大的優(yōu)勢就在于拓展性，比如計(jì)算、存儲、網(wǎng)絡(luò)都可以根據(jù)使用者的需求進(jìn)行拓展，另一個(gè)重要的拓展是 CRD 特性，通過 Custom Resource Definition 開發(fā)者可以定義自己的資源，對應(yīng)的 Operator 來實(shí)現(xiàn)自身的控制邏輯。CRD 本質(zhì)就是一個(gè) YAML 文件，需要我們自己去寫，寫完之后再通過 Operator 去控制，Operator 也需要我們自己去寫，將我們對中間件的理解、實(shí)踐全部結(jié)合在一起，實(shí)現(xiàn)自動化的、可自我恢復(fù)的、可自我調(diào)節(jié)的功能。CR 是該 CRD 定義的一個(gè)具體實(shí)際對象，根據(jù)我們自己的資源需求去實(shí)現(xiàn)。

以前開發(fā) Operator 需要開發(fā)者實(shí)現(xiàn)對資源的監(jiān)聽，對資源事件的隊(duì)列化，以及后面整套控制邏輯，比較繁瑣。正因?yàn)槿绱?，市面上出現(xiàn)了多款的開發(fā) Operator 的腳手架，比較常見的有 Operator SDK 和 Kubebuilder。Kubebuilder 是 Kubernetes SIG 官方團(tuán)隊(duì)原生打造的，它相對使用起來會比較簡單，按如圖步驟即可實(shí)現(xiàn)整個(gè)生命周期。

如圖是 Operator 的主要架構(gòu)，我們只要實(shí)現(xiàn) Reconciler 這個(gè)函數(shù)，Kubebuilder 幫助我們實(shí)現(xiàn)了大部分的功能。它遵從聲明式編程理念，對象定義、控制器部署、Kubebuilder 生成的代碼、自動生成的 Scheme、Kubernetes 原生資源都會儲存到我們自定義的 CRD。GVK 是資源種類的描述，一個(gè) JKV 只會存在一個(gè)對應(yīng)的 Share informer，主要監(jiān)聽對應(yīng)資源的創(chuàng)建、倉儲、更新操作，通知所有 Watch，Controller 將對應(yīng)的資源對象都添加到一個(gè)隊(duì)列里面，最終觸發(fā)到開發(fā)者的調(diào)和程序，即 Reconcile 函數(shù)，里面主要是我們要做的運(yùn)維。這里需要遵守很多 Kubernetes 規(guī)范，比如針對 Kubernetes 標(biāo)準(zhǔn)的 Resource 使用編排，統(tǒng)一叫聲明式調(diào)度，不需要自己操作，讓 Kubernetes 幫你去部署。

我們在實(shí)際使用中會出現(xiàn)了一些問題，我們總結(jié)了四個(gè)問題：

第一個(gè)是過于自動化，比如自動主動切換類型，導(dǎo)致他們自己都無法感知到，害怕主從切換過程中會丟失數(shù)據(jù)；

第二個(gè)是持久化存儲的選擇，之前我們優(yōu)先考慮使用分布式存儲，因?yàn)榭梢员容^靈活，但是經(jīng)過測試發(fā)現(xiàn)速度沒辦法達(dá)到預(yù)期，所以最終選擇本地存儲；

第三個(gè)是需要更快的啟動，比如需要快速測試；

第四個(gè)是可以恢復(fù)數(shù)據(jù)、備份數(shù)據(jù)。

下面介紹我們的五個(gè)功能實(shí)踐。

第一個(gè)是添加手動主從切換，一開始使用自動化的主從切換，但是自動化主從切換有些弊端，因?yàn)榛诋惒綇?fù)制，自動切換可能在主機(jī)宕機(jī)的時(shí)候會丟失數(shù)據(jù)，所以增加了一個(gè)手動主從切換的特性，讓用戶更安心。

第二個(gè)是納管物理機(jī)數(shù)據(jù)庫，為什么我們要使用納管物理機(jī)？因?yàn)榇蟛糠掷峡蛻舳际怯梦锢頇C(jī)來部署 MySQL 的，直接讓他們使用容器化，他們會有所顧慮，為了打消他們的顧慮，我們認(rèn)為需要提供一種過度性的方案，讓他們既能嘗試又不影響現(xiàn)在的服務(wù)。

第三個(gè)是兼容帶數(shù)據(jù)的鏡像，有一個(gè)測試平臺想通過鏡像的方式快速啟動。我們在容器創(chuàng)建之前加入了一個(gè) init 程序，通過這個(gè) init 程序?qū)㈢R像里面的數(shù)據(jù)拷貝到持久化存儲 PV，當(dāng) MySQL 容器真正啟動的時(shí)候自動掛載到 PV，它就會有鏡像里面的數(shù)據(jù)從而不會被覆蓋掉。

第四個(gè)是針對于用戶在使用過程中需要修改密碼，我們中間添加了一個(gè) MySQL 的 User CRD，等于 root 這個(gè)賬戶由 Operator 統(tǒng)一使用，用戶用自己定義的賬戶，當(dāng) MySQL User 創(chuàng)建完后，就會產(chǎn)生一個(gè)對象，Operator 檢測到，把這個(gè) User 里的賬戶密碼插入到數(shù)據(jù)庫里，這樣對多個(gè)用戶的 User 進(jìn)行管理，也可以做用戶的級別分級，回收了 root 賬戶的功能。

第五個(gè)是定時(shí)備份數(shù)據(jù)，我們一開始使用的是全量備份，但定時(shí)做全量備份花費(fèi)的時(shí)間會比較長，并且占用的空間也比較浪費(fèi)。于是我們增加了增量的數(shù)據(jù)恢復(fù)，這需要先有個(gè)全量的數(shù)據(jù)，基于它綁定增量備份時(shí)間點(diǎn)和增量數(shù)據(jù)的位置，要恢復(fù)某個(gè)時(shí)間點(diǎn)的時(shí)候，就先去恢復(fù)全量的數(shù)據(jù)，通過時(shí)間綁定的位置恢復(fù)增量數(shù)據(jù)。

我們后續(xù)還會迎接一些挑戰(zhàn)，這些挑戰(zhàn)主要集中在以下四個(gè)方面：

• 容器穩(wěn)定性
• 客戶信任度
• 兼容更輕量的容器編排引擎
• 更完善的監(jiān)控系統(tǒng)

未來展望

云計(jì)算是一個(gè)發(fā)展方向，是將業(yè)務(wù)無關(guān)的管理功能和運(yùn)維功能盡量下沉到基礎(chǔ)設(shè)施，應(yīng)用可以聚焦在業(yè)務(wù)能力的開發(fā)、運(yùn)營。這個(gè)趨勢演化過程也影響了云計(jì)算的發(fā)展方向。從一開始的虛擬化到 IaaS 跟 PaaS，到應(yīng)用系統(tǒng)的部分管理職責(zé)交給平臺的運(yùn)維過程，我們應(yīng)該重視軟件開發(fā)人員和運(yùn)維人員的溝通合作，通過自動化流程使軟件構(gòu)建、測試、發(fā)布更加迅速，并且可靠。云原生技術(shù)也是目前技術(shù)階段、企業(yè) IT、系統(tǒng)的最佳模式的集合，企業(yè)通過遵循云原生技術(shù)和設(shè)計(jì)模式，可以充分發(fā)揮云計(jì)算平臺優(yōu)勢，同時(shí)也可以最大限度地減少對開發(fā)效率的影響，實(shí)現(xiàn)穩(wěn)定高效的系統(tǒng)。

技術(shù)是一個(gè)不斷發(fā)展的一個(gè)過程，云計(jì)算技術(shù)也是一個(gè)不斷的迭代的過程，相應(yīng)的開發(fā)習(xí)慣和方法也會試著改變。

好文推薦：

GitHub 爆贊的 RocketMQ 分布式中間件學(xué)習(xí)手冊，竟一夜下載量破 10W

計(jì)算存儲分離在京東云消息中間件 JCQ 上的應(yīng)用

一發(fā)一存一消費(fèi)，跟著 p8 大佬深入學(xué)習(xí) Java 中間件技術(shù)及其應(yīng)用開發(fā)

深度解讀｜NebulaGraph x 阿里云計(jì)算巢，云上構(gòu)建超大規(guī)模圖數(shù)據(jù)庫