金蝶云蒼穹云中間件管理架構(gòu)實(shí)踐(金蝶云蒼穹技術(shù)架構(gòu))
作者 | 李仲玄,徐瑛
策劃 | 王一鵬
審校 | 冬雨
中間件是解決共性問(wèn)題的標(biāo)準(zhǔn)化工具,是一種支撐技術(shù),不可或缺。但因其種類多,數(shù)量大的特性,給運(yùn)維管理帶來(lái)了很高的難度。本次分享將介紹基于 Kubernetes 構(gòu)建的云原生中間件平臺(tái)架構(gòu),介紹 kubebuilder 的腳手架構(gòu)建流程,以及 Operator 的工作原理.并以數(shù)據(jù)庫(kù)為例,介紹在實(shí)際推進(jìn)的場(chǎng)景中遇到的問(wèn)題與解決方案,同時(shí)也分享云原生中間件面臨的挑戰(zhàn)的思考與對(duì)未來(lái)的展望。
分享主要分為四個(gè)部分展開(kāi):第一部分中間件管理現(xiàn)狀;第二部分借助云原?優(yōu)勢(shì),提供更好的管理;第三部分云中間件管理平臺(tái)架構(gòu)之路;第四部分未來(lái)展望。
本文整理自金蝶云蒼穹云原生部門高級(jí)研發(fā)李仲玄、金蝶云蒼穹云原生部門產(chǎn)品經(jīng)理徐瑛在DIVE全球基礎(chǔ)軟件創(chuàng)新大會(huì)2022的演講分享,主題為“金蝶云蒼穹云中間件管理架構(gòu)實(shí)踐”。
以下為整理內(nèi)容:
中間件管理現(xiàn)狀
中間件是為了解決復(fù)雜問(wèn)題的支撐技術(shù),在一般的軟件架構(gòu)中是不可或缺的一部分。它是研發(fā)利器,其定義非常廣泛,包含非常多種類型,常見(jiàn)的包括像數(shù)據(jù)庫(kù)中間件、消息隊(duì)列中間件,還有微服務(wù)組件中間件,可見(jiàn)中間件的特征是種類非常的多,涵蓋范圍非常廣,數(shù)量也非常大,這就給我們的管理上增加了難度。
中間件常用的管理方式主要有四種,分別是混合云、公有云、私有云和本地管理。這四種管理方式各有優(yōu)劣,像本地安裝包管理方式,它可以使用本地物理資源降低成本,但運(yùn)維都是純?nèi)斯さ?,通常都是直接使?span id="qsh1b7padf" class="candidate-entity-word" data-gid="474369">運(yùn)維腳本,運(yùn)維門檻就比較高,并且人工出錯(cuò)的概率比較大,整體運(yùn)維效率會(huì)比較低。
第二種私有云方式是建設(shè)一朵私有云,把整個(gè)中間件的資源和運(yùn)維都給管理起來(lái),其劣勢(shì)在于,需要專項(xiàng)投入建設(shè)。
第三種公有云方式是把需要的資源和運(yùn)維能力完全托管到公有云廠商,我們可以減少運(yùn)維和資源管理這部分的麻煩,但是會(huì)和公有云廠商深入綁定,整個(gè)運(yùn)維狀況不是很透明,不是很了解底層到底是怎么樣的運(yùn)維狀態(tài)。
第四種是混合云方式,目的是希望能夠?qū)①Y源分布在多種云上,以降低整體的風(fēng)險(xiǎn),其劣勢(shì)在于統(tǒng)一管理比較難。
上述四種管理方式共同的擔(dān)憂主要分為兩大類,一類是運(yùn)維管理,一類是成本控制。運(yùn)維管理主要圍繞著可用性、可靠性、性能優(yōu)化這幾類問(wèn)題。而資源缺乏、人員配備的問(wèn)題,都屬于成本控制類的問(wèn)題。
解決這些擔(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)維操作要簡(jiǎn)單,做到可視化的部署、容災(zāi)、監(jiān)控分析、告警全生命周期的運(yùn)維管理;
第四點(diǎn)是高可用、高可靠的保障。
上述說(shuō)的這幾點(diǎn),我們運(yùn)用云原生都能很好地解決。
第一點(diǎn)松耦合,它剛好與容器契合,將中間件本身、應(yīng)用和它的配置打包成鏡像,能在不同的資源池上進(jìn)行,不同的環(huán)境上部署,通過(guò)容器編排工具可以根據(jù)申請(qǐng)的資源在資源池中選擇合適的節(jié)點(diǎn)調(diào)度、部署,輕松實(shí)現(xiàn)多實(shí)例面向混合資源池的部署。
第二點(diǎn)彈性擴(kuò)縮,它主要分為兩類,一類是資源池的彈性擴(kuò)縮,另一類是中間件自身利用的彈性擴(kuò)縮?;谫Y源池的彈性擴(kuò)縮,使用計(jì)算存儲(chǔ)分離架構(gòu),我們可以去實(shí)現(xiàn)計(jì)算資源和存儲(chǔ)資源獨(dú)立靈活的擴(kuò)縮容,去滿足我們實(shí)際的業(yè)務(wù)需求?;谥虚g件應(yīng)用,也可按需實(shí)現(xiàn)中間件規(guī)格的擴(kuò)縮容。這兩種彈性擴(kuò)縮,我們都可以通過(guò)容器編排工具實(shí)現(xiàn)。
第三點(diǎn)是運(yùn)維操作簡(jiǎn)單,需要具備快速發(fā)布部署、中間件的管理、異地容災(zāi)整個(gè)生命周期的可視化界面管理?;谌萜髦虚g件,自身就具有快速部署和發(fā)布的能力,能夠自動(dòng)隔離故障結(jié)點(diǎn),將應(yīng)用遷移至健康的結(jié)點(diǎn),讓整個(gè)應(yīng)用系統(tǒng)具有比較強(qiáng)的資源能力,簡(jiǎn)化運(yùn)維管理的復(fù)雜度。
最后一點(diǎn)是可觀測(cè)性,它不僅是中間件運(yùn)維平臺(tái)能力,還是所有運(yùn)維平臺(tái)都需要的能力,它就包含監(jiān)控、日志、告警等等一系列的內(nèi)容。云原生本身就有比較成熟的可觀測(cè)服務(wù)工具。
中間件本身是一個(gè)比較復(fù)雜的系統(tǒng),運(yùn)維也比較煩瑣,部署、故障恢復(fù)、監(jiān)控、報(bào)警、測(cè)試都需要比較專業(yè)的運(yùn)維人員手動(dòng)完成,不僅成本比較高,而且也可能會(huì)出現(xiàn)手工失誤。將中間件做成云服務(wù)的優(yōu)勢(shì)是運(yùn)維簡(jiǎn)單容易上手,能夠高效實(shí)現(xiàn)大批量實(shí)例的自動(dòng)化運(yùn)維。我們主要是一個(gè)三到六臺(tái)的小規(guī)模的 K8S 集群,主要分為 Master 節(jié)點(diǎn)跟 Node 節(jié)點(diǎn),Master 節(jié)點(diǎn)是集群的控制節(jié)點(diǎn),負(fù)責(zé)整個(gè)集群的管理和控制,基本上所有的控制指令都是發(fā)給 Master,并且由他來(lái)調(diào)度 Node 具體的執(zhí)行命令。Node 節(jié)點(diǎn)是工作負(fù)載節(jié)點(diǎn),主要負(fù)責(zé)拉取容器。
我們使用的是聲明式 API,只給出最終的狀態(tài),通過(guò)狀態(tài)機(jī)去協(xié)調(diào),目標(biāo)系統(tǒng)就會(huì)對(duì)資源進(jìn)行操作以達(dá)到要求,調(diào)用者不需任何干預(yù)。其優(yōu)勢(shì)是讓分布式系統(tǒng)之間的交付變得簡(jiǎn)單,不需要關(guān)心任何過(guò)程細(xì)節(jié),這種方式也大大減少了使用者的工作量,極大地提升開(kāi)發(fā)效率。
Kubernetes 現(xiàn)在已經(jīng)是比較流行的云原生分布式操作系統(tǒng),其最大的優(yōu)勢(shì)就在于拓展性,比如計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)都可以根據(jù)使用者的需求進(jìn)行拓展,另一個(gè)重要的拓展是 CRD 特性,通過(guò) Custom Resource Definition 開(kāi)發(fā)者可以定義自己的資源,對(duì)應(yīng)的 Operator 來(lái)實(shí)現(xiàn)自身的控制邏輯。CRD 本質(zhì)就是一個(gè) YAML 文件,需要我們自己去寫,寫完之后再通過(guò) Operator 去控制,Operator 也需要我們自己去寫,將我們對(duì)中間件的理解、實(shí)踐全部結(jié)合在一起,實(shí)現(xiàn)自動(dòng)化的、可自我恢復(fù)的、可自我調(diào)節(jié)的功能。CR 是該 CRD 定義的一個(gè)具體實(shí)際對(duì)象,根據(jù)我們自己的資源需求去實(shí)現(xiàn)。
以前開(kāi)發(fā) Operator 需要開(kāi)發(fā)者實(shí)現(xiàn)對(duì)資源的監(jiān)聽(tīng),對(duì)資源事件的隊(duì)列化,以及后面整套控制邏輯,比較繁瑣。正因?yàn)槿绱?,市面上出現(xiàn)了多款的開(kāi)發(fā) Operator 的腳手架,比較常見(jiàn)的有 Operator SDK 和 Kubebuilder。Kubebuilder 是 Kubernetes SIG 官方團(tuán)隊(duì)原生打造的,它相對(duì)使用起來(lái)會(huì)比較簡(jiǎn)單,按如圖步驟即可實(shí)現(xiàn)整個(gè)生命周期。
如圖是 Operator 的主要架構(gòu),我們只要實(shí)現(xiàn) Reconciler 這個(gè)函數(shù),Kubebuilder 幫助我們實(shí)現(xiàn)了大部分的功能。它遵從聲明式編程理念,對(duì)象定義、控制器部署、Kubebuilder 生成的代碼、自動(dòng)生成的 Scheme、Kubernetes 原生資源都會(huì)儲(chǔ)存到我們自定義的 CRD。GVK 是資源種類的描述,一個(gè) JKV 只會(huì)存在一個(gè)對(duì)應(yīng)的 Share informer,主要監(jiān)聽(tīng)對(duì)應(yīng)資源的創(chuàng)建、倉(cāng)儲(chǔ)、更新操作,通知所有 Watch,Controller 將對(duì)應(yīng)的資源對(duì)象都添加到一個(gè)隊(duì)列里面,最終觸發(fā)到開(kāi)發(fā)者的調(diào)和程序,即 Reconcile 函數(shù),里面主要是我們要做的運(yùn)維。這里需要遵守很多 Kubernetes 規(guī)范,比如針對(duì) Kubernetes 標(biāo)準(zhǔn)的 Resource 使用編排,統(tǒng)一叫聲明式調(diào)度,不需要自己操作,讓 Kubernetes 幫你去部署。
我們?cè)趯?shí)際使用中會(huì)出現(xiàn)了一些問(wèn)題,我們總結(jié)了四個(gè)問(wèn)題:
第一個(gè)是過(guò)于自動(dòng)化,比如自動(dòng)主動(dòng)切換類型,導(dǎo)致他們自己都無(wú)法感知到,害怕主從切換過(guò)程中會(huì)丟失數(shù)據(jù);
第二個(gè)是持久化存儲(chǔ)的選擇,之前我們優(yōu)先考慮使用分布式存儲(chǔ),因?yàn)榭梢员容^靈活,但是經(jīng)過(guò)測(cè)試發(fā)現(xiàn)速度沒(méi)辦法達(dá)到預(yù)期,所以最終選擇本地存儲(chǔ);
第三個(gè)是需要更快的啟動(dòng),比如需要快速測(cè)試;
第四個(gè)是可以恢復(fù)數(shù)據(jù)、備份數(shù)據(jù)。
下面介紹我們的五個(gè)功能實(shí)踐。
第一個(gè)是添加手動(dòng)主從切換,一開(kāi)始使用自動(dòng)化的主從切換,但是自動(dòng)化主從切換有些弊端,因?yàn)榛诋惒綇?fù)制,自動(dòng)切換可能在主機(jī)宕機(jī)的時(shí)候會(huì)丟失數(shù)據(jù),所以增加了一個(gè)手動(dòng)主從切換的特性,讓用戶更安心。
第二個(gè)是納管物理機(jī)數(shù)據(jù)庫(kù),為什么我們要使用納管物理機(jī)?因?yàn)榇蟛糠掷峡蛻舳际怯梦锢頇C(jī)來(lái)部署 MySQL 的,直接讓他們使用容器化,他們會(huì)有所顧慮,為了打消他們的顧慮,我們認(rèn)為需要提供一種過(guò)度性的方案,讓他們既能嘗試又不影響現(xiàn)在的服務(wù)。
第三個(gè)是兼容帶數(shù)據(jù)的鏡像,有一個(gè)測(cè)試平臺(tái)想通過(guò)鏡像的方式快速啟動(dòng)。我們?cè)谌萜鲃?chuàng)建之前加入了一個(gè) init 程序,通過(guò)這個(gè) init 程序?qū)㈢R像里面的數(shù)據(jù)拷貝到持久化存儲(chǔ) PV,當(dāng) MySQL 容器真正啟動(dòng)的時(shí)候自動(dòng)掛載到 PV,它就會(huì)有鏡像里面的數(shù)據(jù)從而不會(huì)被覆蓋掉。
第四個(gè)是針對(duì)于用戶在使用過(guò)程中需要修改密碼,我們中間添加了一個(gè) MySQL 的 User CRD,等于 root 這個(gè)賬戶由 Operator 統(tǒng)一使用,用戶用自己定義的賬戶,當(dāng) MySQL User 創(chuàng)建完后,就會(huì)產(chǎn)生一個(gè)對(duì)象,Operator 檢測(cè)到,把這個(gè) User 里的賬戶密碼插入到數(shù)據(jù)庫(kù)里,這樣對(duì)多個(gè)用戶的 User 進(jìn)行管理,也可以做用戶的級(jí)別分級(jí),回收了 root 賬戶的功能。
第五個(gè)是定時(shí)備份數(shù)據(jù),我們一開(kāi)始使用的是全量備份,但定時(shí)做全量備份花費(fèi)的時(shí)間會(huì)比較長(zhǎng),并且占用的空間也比較浪費(fèi)。于是我們?cè)黾恿嗽隽康臄?shù)據(jù)恢復(fù),這需要先有個(gè)全量的數(shù)據(jù),基于它綁定增量備份時(shí)間點(diǎn)和增量數(shù)據(jù)的位置,要恢復(fù)某個(gè)時(shí)間點(diǎn)的時(shí)候,就先去恢復(fù)全量的數(shù)據(jù),通過(guò)時(shí)間綁定的位置恢復(fù)增量數(shù)據(jù)。
我們后續(xù)還會(huì)迎接一些挑戰(zhàn),這些挑戰(zhàn)主要集中在以下四個(gè)方面:
- 容器穩(wěn)定性
- 客戶信任度
- 兼容更輕量的容器編排引擎
- 更完善的監(jiān)控系統(tǒng)
未來(lái)展望
云計(jì)算是一個(gè)發(fā)展方向,是將業(yè)務(wù)無(wú)關(guān)的管理功能和運(yùn)維功能盡量下沉到基礎(chǔ)設(shè)施,應(yīng)用可以聚焦在業(yè)務(wù)能力的開(kāi)發(fā)、運(yùn)營(yíng)。這個(gè)趨勢(shì)演化過(guò)程也影響了云計(jì)算的發(fā)展方向。從一開(kāi)始的虛擬化到 IaaS 跟 PaaS,到應(yīng)用系統(tǒng)的部分管理職責(zé)交給平臺(tái)的運(yùn)維過(guò)程,我們應(yīng)該重視軟件開(kāi)發(fā)人員和運(yùn)維人員的溝通合作,通過(guò)自動(dòng)化流程使軟件構(gòu)建、測(cè)試、發(fā)布更加迅速,并且可靠。云原生技術(shù)也是目前技術(shù)階段、企業(yè) IT、系統(tǒng)的最佳模式的集合,企業(yè)通過(guò)遵循云原生技術(shù)和設(shè)計(jì)模式,可以充分發(fā)揮云計(jì)算平臺(tái)優(yōu)勢(shì),同時(shí)也可以最大限度地減少對(duì)開(kāi)發(fā)效率的影響,實(shí)現(xiàn)穩(wěn)定高效的系統(tǒng)。
技術(shù)是一個(gè)不斷發(fā)展的一個(gè)過(guò)程,云計(jì)算技術(shù)也是一個(gè)不斷的迭代的過(guò)程,相應(yīng)的開(kāi)發(fā)習(xí)慣和方法也會(huì)試著改變。
好文推薦:
GitHub 爆贊的 RocketMQ 分布式中間件學(xué)習(xí)手冊(cè),竟一夜下載量破 10W
計(jì)算存儲(chǔ)分離在京東云消息中間件 JCQ 上的應(yīng)用
一發(fā)一存一消費(fèi),跟著 p8 大佬深入學(xué)習(xí) Java 中間件技術(shù)及其應(yīng)用開(kāi)發(fā)
深度解讀|NebulaGraph x 阿里云計(jì)算巢,云上構(gòu)建超大規(guī)模圖數(shù)據(jù)庫(kù)