作者 | 李仲玄，徐瑛

策劃 | 王一鵬

審校 | 冬雨

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第四點是高可用、高可靠的保障。

上述說的這幾點，我們運用云原生都能很好地解決。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面介紹我們的五個功能實踐。

第一個是添加手動主從切換，一開始使用自動化的主從切換，但是自動化主從切換有些弊端，因為基于異步復(fù)制，自動切換可能在主機宕機的時候會丟失數(shù)據(jù)，所以增加了一個手動主從切換的特性，讓用戶更安心。

第二個是納管物理機數(shù)據(jù)庫，為什么我們要使用納管物理機？因為大部分老客戶都是用物理機來部署 MySQL 的，直接讓他們使用容器化，他們會有所顧慮，為了打消他們的顧慮，我們認為需要提供一種過度性的方案，讓他們既能嘗試又不影響現(xiàn)在的服務(wù)。

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

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

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

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

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

未來展望

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

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

好文推薦：

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

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

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

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