KubeMQ,一種Kafka的替代品
譯文【51CTO.com快譯】如今,隨著交互式部件的增多,應(yīng)用程序變得越來越復(fù)雜。即使是最基本的支付類應(yīng)用,其前端接口也時(shí)常會(huì)觸發(fā)各種消息傳遞,以實(shí)現(xiàn)交易的及時(shí)處理。可以說,無論底層網(wǎng)絡(luò)或其他服務(wù)是否可用,應(yīng)用服務(wù)之間都需要通過一種可靠的方式,來相互通信。
為了實(shí)現(xiàn)此類復(fù)雜的后臺(tái)操作,應(yīng)用程序往往需要一種服務(wù)“郵局”,來跟蹤所有往來的請求和警報(bào)。在此,我們可以運(yùn)用消息隊(duì)列來實(shí)現(xiàn)該目標(biāo)。作為一種專門的應(yīng)用程序,消息隊(duì)列充當(dāng)了在分布式應(yīng)用程序的不同服務(wù)之間、或不同應(yīng)用程序之間的中介角色。通過將應(yīng)用程序的各個(gè)服務(wù)彼此分離,它可以確保無論消息接收者是否在線,都能夠?qū)ο⑦M(jìn)行處理,并可以讓消息隊(duì)列最終被接收到。
常見的消息隊(duì)列示例包括:
- 不同應(yīng)用程序之間的異步處理。
- 確保不同組件之間能夠?qū)崿F(xiàn)具有可靠通信的、基于微服務(wù)的應(yīng)用程序。
- 事務(wù)的優(yōu)先級排序和限流。
- 各種可以從批處理中受益的數(shù)據(jù)處理操作。
- 那些可以通過擴(kuò)展,來滿足突發(fā)需求變化的應(yīng)用程序。
- 能夠通過魯棒性,從崩潰和意外故障中恢復(fù)的應(yīng)用程序。
- 通過長期運(yùn)行的進(jìn)程,限制消耗資源。
目前,在消息隊(duì)列領(lǐng)域不乏各大云平臺(tái)供應(yīng)商,其中包括:Amazon Web Services、Microsoft Azure和Google Cloud等。其對應(yīng)的產(chǎn)品有AWS Simple Queue Service、Azure Service Bus以及Google的Pub/Sub。當(dāng)然,其中也有諸如:RabbitMQ、Apache的ActiveMQ和Kafka等獨(dú)立的通用消息代理。
下面,我將向您介紹一種作為Kafka替代品的KubeMQ,討論它作為Kubernetes的原生消息隊(duì)列,是如何在Kubernetes上實(shí)施,并讓應(yīng)用從中受益。
Apache Kafka的簡介
在了解KubeMQ的全部價(jià)值之前,先讓我們花一些時(shí)間來熟悉一下Kafka。最初由LinkedIn工程師創(chuàng)建的Kafka,可作為軟件總線(software bus)被用于跟蹤LinkedIn用戶的各項(xiàng)活動(dòng)。隨后,它被作為開源的產(chǎn)品發(fā)布出來。如今,Kafka已由Apache軟件基金會(huì)開發(fā)和管理,并被超過80%的財(cái)富100強(qiáng)公司所使用(https://kafka.apache.org/)。它不但開源,而且是一個(gè)高度可擴(kuò)展的系統(tǒng)。通過廣泛地連接到各類事件生產(chǎn)者和消費(fèi)者,Kafka可以被配置為,即使在有限的網(wǎng)絡(luò)環(huán)境中,也能夠很好地使用數(shù)據(jù)流,并執(zhí)行各項(xiàng)復(fù)雜的功能。同時(shí),憑借著其擁有廣泛的在線用戶社區(qū)支持,Kafka還提供了多種商業(yè)產(chǎn)品,其中包括:由AWS和Confluent分別提供托管的Kafka版本。
Kafka的局限性
盡管采用率非常高,但Kafka并不總是消息隊(duì)列系統(tǒng)的最佳選擇。其單體式架構(gòu),主要適用于本地的集群、或復(fù)雜(high-end)的多虛擬機(jī)設(shè)置。鑒于Kafka需要較多的內(nèi)存和存儲(chǔ)空間,它很難支持在獨(dú)立的工作站上,快速啟動(dòng)多的節(jié)點(diǎn)集群,以開展測試。簡而言之,Kafka與基礎(chǔ)設(shè)施中復(fù)雜部分的集成并不容易,尤其是那些基于Kubernetes的架構(gòu)。
下圖展示了基于Kubernetes的Kafka部署,并帶有的不同移動(dòng)部分。如果您想在本地實(shí)施,那么除了為基本的Kubernetes集群配備底層計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)等基礎(chǔ)設(shè)施之外,還需要安裝Kafka的所有部分,并將其與Helm等包管理器相集成。這些組件會(huì)包含一個(gè)諸如:ZooKeeper或Mesos的編排器,用于管理Kafka的各個(gè)代理和主題。此外,您還需要注意依賴關(guān)系、日志、分區(qū)等方面。毫不夸張地說,如果有一個(gè)元素失效、或被錯(cuò)誤配置,就可能會(huì)給整體應(yīng)用帶來麻煩??梢?,成功地部署Kafka,其實(shí)并不容易。
基于Kubernetes架構(gòu)的Kafka
同時(shí),為了達(dá)到最佳的資源使用狀態(tài),我們需要在將新的Kafka節(jié)點(diǎn)添加到Kubernetes集群時(shí),通過復(fù)雜的手動(dòng)設(shè)置來保持平衡狀態(tài)。這也就是為什么我們無法使用簡單的方法,來管理和確??煽康膫浞莺突謴?fù)策略,也難以在具有大量節(jié)點(diǎn)的Kafka集群上,實(shí)現(xiàn)災(zāi)備的原因。Kubernetes集群中的數(shù)據(jù)往往被保存在pod之外,而編排器會(huì)自動(dòng)spin up失敗的pod,但是Kafka卻沒有此類原生的故障防護(hù)機(jī)制。
此外,我們還需要通過第三方工具,對Kafka、ZooKeeper、以及Kubernetes的部署進(jìn)行有效的監(jiān)控。
KubeMQ的簡介
作為一種消息服務(wù),KubeMQ在構(gòu)建之初就考慮到了Kubernetes。它以無狀態(tài)和短暫的方式,遵循了容器架構(gòu)的優(yōu)秀實(shí)踐。也就是說,單個(gè)KubeMQ節(jié)點(diǎn)將在其整個(gè)生命周期內(nèi)保持不變,且可以被預(yù)測和重現(xiàn)。如果需要更改配置的話,我們可以直接關(guān)閉并更換該節(jié)點(diǎn)。注意,此處的可重復(fù)性與Kafka不同,它意味著,KubeMQ帶有零配置設(shè)置,即:在安裝完成后無需調(diào)整配置。
作為一個(gè)能夠適應(yīng)最廣泛的、消息模式的消息代理與隊(duì)列,KubeMQ可以支持如下方面:
- 具有持久性的Pub/Sub
- 支持同步和異步的請求與回復(fù)
- 至少一次性交付
- 支持各種流媒體模式
- 支持RPC
相比之下,Kafka不但只能夠支持具有持久性和流式傳輸?shù)腜ub/Sub,而且根本不支持RPC或請求/回復(fù)模式。
在資源使用方面,KubeMQ以最小的占用空間勝過了Kafka。由于KubeMQ的docker容器僅占用30MB空間,因此它有助于容錯(cuò)設(shè)置,并能簡化部署。與Kafka不同的是,用戶很容易將KubeMQ添加到本地工作站中的小型Kubernetes開發(fā)環(huán)境中。同時(shí),KubeMQ具有足夠的可擴(kuò)展性,可以被部署在運(yùn)行著數(shù)百個(gè)本地和云托管節(jié)點(diǎn)的混合環(huán)境中。這種易部署性的核心是kubemqctl。它是KubeMQ的命令行界面工具,類似于Kubernetes的kubectl。
KubeMQ優(yōu)于Kafka的另一個(gè)方面在速度上。Kafka是用Java和Scala編寫而成,而KubeMQ是用Go語言編寫的,可確保其快速運(yùn)行。同時(shí),在內(nèi)部基準(zhǔn)的操作中,KubeMQ處理100萬條消息的速度,要比Kafka快20%。
在KubeMQ的“免配置”方面,通道(channel)是開發(fā)人員唯一需要?jiǎng)?chuàng)建的對象。KubeMQ通過Raft代替了ZooKeeper,同時(shí)也省去了各種代理、交換和編排器。
從監(jiān)控的角度來看,我們可以通過將Prometheus和Grafana的儀表板,與KubeMQ完全集成,而無需手動(dòng)集成第三方觀測類工具。盡管KubeMQ可與此類工具實(shí)現(xiàn)原生的集成,但是您仍然可以使用如下現(xiàn)有的日志記錄和監(jiān)控解決方案:
- 將Fluentd、Elastic和Datadog用于監(jiān)控
- 將Loggly用于記錄
- 將Jaeger和Open Tracing用于跟蹤
不過,由于Kafka不是云原生計(jì)算基金會(huì)(Cloud Native Computing Foundation,CNCF)環(huán)境的原生部分,因此它通常不支持與CNCF的工具相集成,而需要手動(dòng)配置。
而在完成配置之后,它可以通過與Kubernetes的良好兼容性,實(shí)現(xiàn)與開源的gRPC(遠(yuǎn)程過程調(diào)用)系統(tǒng)的連接。顯然,Kafka自帶的專有連接機(jī)制,不一定能夠達(dá)到該結(jié)果。
從Kafka到KubeMQ的透明遷移
KubeMQ不但部署和操作簡單,而且可以讓用戶輕松地將現(xiàn)有的Kafka設(shè)置,移植到KubeMQ上。為此,開發(fā)人員可以將KubeMQ的Kafka連接器,配置為專門轉(zhuǎn)換來自Kafka的消息。具體而言,KubeMQ的源連接器將被作為訂閱者,去消費(fèi)(consume)來自Kafka源主題的各類消息,并將它們轉(zhuǎn)換為KubeMQ的消息格式,進(jìn)而將消息發(fā)送到某個(gè)內(nèi)部日志處。而KubeMQ的目標(biāo)連接器,則會(huì)訂閱包含已轉(zhuǎn)換消息的輸出日志,然后將這些消息,發(fā)送到Kafka中的某個(gè)目標(biāo)主題處。其具體架構(gòu)如下圖所示:
Kafka與KubeMQ的集成
此外,那些被Kafka支持的任何消息傳遞模式,也都能夠被KubeMQ所支持。例如,Kafka僅支持具有持久性和流式的Pub/Sub。而作為消息隊(duì)列和代理的KubeMQ,可以完全支持Pub/Sub、同步/異步的請求/回復(fù)、交付、流模式、以及RPC。因此,從Kafka遷移到KubeMQ時(shí),用戶無需重構(gòu)應(yīng)用程序代碼,即可適應(yīng)復(fù)雜的邏輯變化。
小結(jié)
目前,KubeMQ可以被免費(fèi)下載,并附帶有六個(gè)月的免費(fèi)開發(fā)試用版。如果您正在使用 OpenShift的話,則可以在Red Hat Marketplace中使用KubeMQ,具體請參見--https://marketplace.redhat.com/en-us。此外,它還適用于包括GCP、AWS、Azure、以及DigitalOcean在內(nèi)的所有主流云端環(huán)境。
總的說來,就大多數(shù)消息流量負(fù)載而言,KubeMQ內(nèi)置的簡單性、輕量級、以及容器優(yōu)先集成性,將能夠提供優(yōu)于Kafka的性能。同時(shí),由于它幾乎不需要任何配置,因此用戶將節(jié)省大量的管理、設(shè)置、以及遷移時(shí)間。
原文標(biāo)題:KubeMQ: A Modern Alternative toKafka,作者:Michael Bogan
【51CTO譯稿,合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】