[[429604]]

【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】