【51CTO.com快譯】為了實(shí)現(xiàn)這種復(fù)雜的操作，必須有某種類型的服務(wù)“郵局”來(lái)跟蹤所有請(qǐng)求和警報(bào)。實(shí)現(xiàn)這一目標(biāo)的工具便是消息隊(duì)列。

消息隊(duì)列是一種專門的應(yīng)用程序，它充當(dāng)分布式應(yīng)用程序的不同服務(wù)之間或不同應(yīng)用程序之間的中介。它將應(yīng)用程序服務(wù)彼此分離，確保無(wú)論消息接收者是否可用，都會(huì)進(jìn)行處理。消息隊(duì)列確保最終成功接收所有消息。

消息隊(duì)列的常見(jiàn)用例包括：

• 不同應(yīng)用程序之間的異步處理。
• 基于微服務(wù)的應(yīng)用程序，其中不同組件之間的可靠通信至關(guān)重要。
• 事務(wù)排序和限制。
• 可以從批處理的簡(jiǎn)化效率中受益的數(shù)據(jù)處理操作。
• 必須可擴(kuò)展以滿足突然和意外需求變化的應(yīng)用程序。
• 應(yīng)用程序必須具有足夠的彈性才能從崩潰和意外故障中恢復(fù)。
• 通過(guò)長(zhǎng)時(shí)間運(yùn)行的進(jìn)程限制資源消耗。

消息隊(duì)列領(lǐng)域不乏供應(yīng)商。像Amazon Web Services、Microsoft Azure和谷歌cloud這樣的大型云平臺(tái)都有自己的產(chǎn)品(AWS Simple Queue Service、Azure的服務(wù)總線和谷歌的Pub/Sub)。也有獨(dú)立的通用消息代理，如RabbitMQ、Apache的ActiveMQ和Kafka。

本文介紹了一個(gè)名為KubeMQ的現(xiàn)代Kubernetes原生消息隊(duì)列，以嘗試讓已經(jīng)在Kubernetes上使用kafka的組織如何從中受益。

什么是Apache Kafka

要了解 KubeMQ 的全部?jī)r(jià)值，我們首先需要花一些時(shí)間來(lái)了解 Kafka。Kafka 最初由 LinkedIn 工程師創(chuàng)建，作為跟蹤 LinkedIn 用戶活動(dòng)的軟件總線。它后來(lái)作為開源產(chǎn)品發(fā)布，今天，Kafka 由 Apache 軟件基金會(huì)開發(fā)和管理。

Apache 指出，超過(guò) 80% 的財(cái)富 100 強(qiáng)公司信任并使用 Kafka。盡管是開源的，但眾所周知它是一個(gè)高度可擴(kuò)展的系統(tǒng)，可以連接到廣泛的事件生產(chǎn)者和消費(fèi)者。它可以配置為使用數(shù)據(jù)流執(zhí)行復(fù)雜的功能，即使在有限的網(wǎng)絡(luò)環(huán)境中也能很好地工作。憑借在線用戶社區(qū)中廣泛可用的支持，Kafka 還提供多種商業(yè)產(chǎn)品。例如，AWS 提供托管 Kafka，Confluent 也是如此。

Kafka的局限性

盡管采用率很高，但 Kafka 并不總是作為消息隊(duì)列系統(tǒng)的最佳選擇。它具有單體架構(gòu)，適用于本地集群或高端多虛擬機(jī)設(shè)置。鑒于 Kafka 需要多少內(nèi)存和存儲(chǔ)空間，在獨(dú)立工作站上快速啟動(dòng)多節(jié)點(diǎn)集群以進(jìn)行測(cè)試可能是一項(xiàng)挑戰(zhàn)。

簡(jiǎn)而言之，將 Kafka 與你的基礎(chǔ)設(shè)施集成所需的所有復(fù)雜部分成功地整合在一起并不容易。對(duì)于基于 Kubernetes 的架構(gòu)尤其如此。

如下圖所示，基于 Kubernetes 的 Kafka 部署有不同的活動(dòng)部分。除了為基本 Kubernetes 集群配置底層計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)基礎(chǔ)設(shè)施（如果你在本地實(shí)施），你還需要安裝所有 Kafka 部分并將其與 Helm 等包管理器集成。這些組件可以包括一個(gè)協(xié)調(diào)器，如 ZooKeeper 或 Mesos，用于管理 Kafka 的代理和主題。其他需要注意的地方包括依賴、日志、分區(qū)等。如果甚至缺少一個(gè)元素或配置錯(cuò)誤，事情都不會(huì)奏效——成功部署 Kafka 并非易事。

???

Kafka on Kubernetes 架構(gòu)

將新的 Kafka 節(jié)點(diǎn)添加到 Kubernetes 集群需要復(fù)雜的手動(dòng)平衡以保持最佳資源使用。這就是為什么沒(méi)有簡(jiǎn)單的方法來(lái)管理和確保可靠的備份和恢復(fù)策略；對(duì)運(yùn)行在大量節(jié)點(diǎn)上的 Kafka 集群進(jìn)行防災(zāi)并不容易。與 Kubernetes 集群中的數(shù)據(jù)保存在 pod 之外，并且編排器自動(dòng)啟動(dòng)失敗的 pod 不同，Kafka 沒(méi)有這樣的原生防故障機(jī)制。

最后，對(duì) Kafka/ZooKeeper/Kubernetes 部署的有效監(jiān)控需要第三方工具。

什么是KubeMQ

Kube MQ 是一種消息服務(wù)，從頭開始構(gòu)建時(shí)就考慮到了 Kubernetes。遵循容器架構(gòu)最佳實(shí)踐，KubeMQ 旨在實(shí)現(xiàn)無(wú)狀態(tài)和短暫的。也就是說(shuō)，一個(gè) KubeMQ 節(jié)點(diǎn)將在其整個(gè)生命周期內(nèi)保持不變、可預(yù)測(cè)和可重現(xiàn)。如果需要更改配置，則會(huì)關(guān)閉并更換節(jié)點(diǎn)。

這種可重復(fù)性意味著，與 Kafka 不同，KubeMQ 帶有零配置設(shè)置，安裝后無(wú)需調(diào)整配置。

KubeMQ 旨在適應(yīng)最廣泛的消息模式。它是一個(gè)消息代理和消息隊(duì)列，支持以下內(nèi)容：

• 具有或不具有持久性的 Pub/Sub
• 請(qǐng)求/回復(fù)（同步、異步）
• 最多一次交貨
• 至少一次交付
• 流媒體模式
• RPC

相比之下，Kafka 只支持具有持久性和流式傳輸?shù)?Pub/Sub。Kafka 根本不支持 RPC 和請(qǐng)求/回復(fù)模式。

在資源使用方面，KubeMQ 以最小的占用空間勝過(guò) Kafka。KubeMQ docker 容器僅占用 30MB 空間。如此小的占地面積有助于容錯(cuò)設(shè)置和簡(jiǎn)化部署。與 Kafka 不同，將 KubeMQ 添加到本地工作站中的小型開發(fā) Kubernetes 環(huán)境非常簡(jiǎ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)行。在內(nèi)部基準(zhǔn)操作中，KubeMQ 處理 100 萬(wàn)條消息的速度比 Kafka 快 20%。

回到 KubeMQ 的“免配置”方面，通道是開發(fā)人員唯一需要?jiǎng)?chuàng)建的對(duì)象。你可以忘記代理、交換和協(xié)調(diào)器——KubeMQ 的 Raft 代替 ZooKeeper 完成所有這些工作。

從監(jiān)控的角度來(lái)看，通過(guò) Prometheus 和 Grafana 的儀表板與 KubeMQ 完全集成，因此你無(wú)需手動(dòng)集成第三方可觀察性工具的額外工作。但是，由于 KubeMQ 與工具的原生集成，你仍然可以使用現(xiàn)有的日志記錄和監(jiān)控解決方案，包括：

• Fluentd、Elastic 和 Datadog，用于監(jiān)控
• Loggly，用于記錄
• Jaeger 和 Open Tracing，用于跟蹤

由于Kafka 不是云原生計(jì)算基金會(huì) (CNCF) 環(huán)境的原生部分，因此通常不支持與 CNCF 工具的集成，必須手動(dòng)配置。

如果配置好，可以通過(guò)開源的gRPC遠(yuǎn)程過(guò)程調(diào)用系統(tǒng)進(jìn)行連接，其與Kubernetes的卓越兼容性是眾所周知的。Kafka 自己專有的連接機(jī)制不一定能提供可比的結(jié)果。

從 Kafka 到 KubeMQ 的透明遷移

除了 KubeMQ 的部署和操作簡(jiǎn)單之外，將現(xiàn)有的 Kafka 設(shè)置移植到 KubeMQ 也很簡(jiǎn)單。

為此，開發(fā)人員可以從使用 KubeMQ Kafka 連接器開始。KubeMQ 目標(biāo)和源連接器被配置為轉(zhuǎn)換來(lái)自 Kafka 的消息。在高層次上，KubeMQ 源連接器作為訂閱者消費(fèi)來(lái)自 Kafka 源主題的消息，將消息轉(zhuǎn)換為 KubeMQ 消息格式，然后將消息發(fā)送到內(nèi)部日志。KubeMQ 目標(biāo)連接器訂閱包含轉(zhuǎn)換消息的輸出日志，然后將消息發(fā)送到 Kafka 中的目標(biāo)主題。高層架構(gòu)如下圖所示：

???

Kafka 與 KubeMQ 的集成

此外，Kafka 支持的任何消息傳遞模式都由 KubeMQ 支持。例如，Kafka 僅支持具有持久性和流的 Pub/Sub。KubeMQ 是一個(gè)消息隊(duì)列和消息代理，支持 Pub/Sub（有或沒(méi)有持久化）請(qǐng)求/回復(fù)（同步、異步）、至少一種交付、流模式和 RPC。因此，從 Kafka 遷移到 KubeMQ 時(shí)，無(wú)需重構(gòu)應(yīng)用程序代碼并適應(yīng)復(fù)雜的邏輯變化。

最后

對(duì)于大多數(shù)工作負(fù)載，KubeMQ內(nèi)置的簡(jiǎn)單性、輕量級(jí)和容器優(yōu)先集成將提供優(yōu)于 Kafka 的性能。此外，所需的幾乎為零的配置將節(jié)省大量的管理和設(shè)置時(shí)間。正如我們提到的，遷移很簡(jiǎn)單。

KubeMQ 是免費(fèi)下載的，附帶六個(gè)月的免費(fèi)開發(fā)試用版。如果你使用 OpenShift，可以在 Red Hat Marketplace 中使用 KubeMQ 。它還適用于所有主要云環(huán)境，包括 GCP、AWS、Azure 和 DigitalOcean。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】