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

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

消息隊列的常見用例包括：

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

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

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

什么是Apache Kafka

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

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

Kafka的局限性

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

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

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

???

Kafka on Kubernetes 架構(gòu)

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

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

什么是KubeMQ

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

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

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

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

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

在資源使用方面，KubeMQ 以最小的占用空間勝過 Kafka。KubeMQ docker 容器僅占用 30MB 空間。如此小的占地面積有助于容錯設(shè)置和簡化部署。與 Kafka 不同，將 KubeMQ 添加到本地工作站中的小型開發(fā) Kubernetes 環(huán)境非常簡單。但與此同時，KubeMQ 具有足夠的可擴展性，可以部署在運行在數(shù)百個本地和云托管節(jié)點上的混合環(huán)境中。這種易于部署的核心是kubemqctl，它是KubeMQ的命令行界面工具，類似于 Kubernetes 的 kubectl。

KubeMQ 優(yōu)于 Kafka 的另一個方面是它的速度。Kafka 是用 Java 和 Scala 編寫的，而 KubeMQ 是用 Go 編寫的，確保快速運行。在內(nèi)部基準操作中，KubeMQ 處理 100 萬條消息的速度比 Kafka 快 20%。

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

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

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

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

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

從 Kafka 到 KubeMQ 的透明遷移

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

為此，開發(fā)人員可以從使用 KubeMQ Kafka 連接器開始。KubeMQ 目標(biāo)和源連接器被配置為轉(zhuǎn)換來自 Kafka 的消息。在高層次上，KubeMQ 源連接器作為訂閱者消費來自 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 是一個消息隊列和消息代理，支持 Pub/Sub（有或沒有持久化）請求/回復(fù)（同步、異步）、至少一種交付、流模式和 RPC。因此，從 Kafka 遷移到 KubeMQ 時，無需重構(gòu)應(yīng)用程序代碼并適應(yīng)復(fù)雜的邏輯變化。

最后

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

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

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