[[429604]]

【51CTO.com快譯】如今，隨著交互式部件的增多，應用程序變得越來越復雜。即使是最基本的支付類應用，其前端接口也時常會觸發各種消息傳遞，以實現交易的及時處理。可以說，無論底層網絡或其他服務是否可用，應用服務之間都需要通過一種可靠的方式，來相互通信。

為了實現此類復雜的后臺操作，應用程序往往需要一種服務“郵局”，來跟蹤所有往來的請求和警報。在此，我們可以運用消息隊列來實現該目標。作為一種專門的應用程序，消息隊列充當了在分布式應用程序的不同服務之間、或不同應用程序之間的中介角色。通過將應用程序的各個服務彼此分離，它可以確保無論消息接收者是否在線，都能夠對消息進行處理，并可以讓消息隊列最終被接收到。

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

• 不同應用程序之間的異步處理。
• 確保不同組件之間能夠實現具有可靠通信的、基于微服務的應用程序。
• 事務的優先級排序和限流。
• 各種可以從批處理中受益的數據處理操作。
• 那些可以通過擴展，來滿足突發需求變化的應用程序。
• 能夠通過魯棒性，從崩潰和意外故障中恢復的應用程序。
• 通過長期運行的進程，限制消耗資源。

目前，在消息隊列領域不乏各大云平臺供應商，其中包括：Amazon Web Services、Microsoft Azure和Google Cloud等。其對應的產品有AWS Simple Queue Service、Azure Service Bus以及Google的Pub/Sub。當然，其中也有諸如：RabbitMQ、Apache的ActiveMQ和Kafka等獨立的通用消息代理。

下面，我將向您介紹一種作為Kafka替代品的KubeMQ，討論它作為Kubernetes的原生消息隊列，是如何在Kubernetes上實施，并讓應用從中受益。

Apache Kafka的簡介

在了解KubeMQ的全部價值之前，先讓我們花一些時間來熟悉一下Kafka。最初由LinkedIn工程師創建的Kafka，可作為軟件總線(software bus)被用于跟蹤LinkedIn用戶的各項活動。隨后，它被作為開源的產品發布出來。如今，Kafka已由Apache軟件基金會開發和管理，并被超過80%的財富100強公司所使用(https://kafka.apache.org/)。它不但開源，而且是一個高度可擴展的系統。通過廣泛地連接到各類事件生產者和消費者，Kafka可以被配置為，即使在有限的網絡環境中，也能夠很好地使用數據流，并執行各項復雜的功能。同時，憑借著其擁有廣泛的在線用戶社區支持，Kafka還提供了多種商業產品，其中包括：由AWS和Confluent分別提供托管的Kafka版本。

Kafka的局限性

盡管采用率非常高，但Kafka并不總是消息隊列系統的最佳選擇。其單體式架構，主要適用于本地的集群、或復雜(high-end)的多虛擬機設置。鑒于Kafka需要較多的內存和存儲空間，它很難支持在獨立的工作站上，快速啟動多的節點集群，以開展測試。簡而言之，Kafka與基礎設施中復雜部分的集成并不容易，尤其是那些基于Kubernetes的架構。

下圖展示了基于Kubernetes的Kafka部署，并帶有的不同移動部分。如果您想在本地實施，那么除了為基本的Kubernetes集群配備底層計算、網絡和存儲等基礎設施之外，還需要安裝Kafka的所有部分，并將其與Helm等包管理器相集成。這些組件會包含一個諸如：ZooKeeper或Mesos的編排器，用于管理Kafka的各個代理和主題。此外，您還需要注意依賴關系、日志、分區等方面。毫不夸張地說，如果有一個元素失效、或被錯誤配置，就可能會給整體應用帶來麻煩。可見，成功地部署Kafka，其實并不容易。

基于Kubernetes架構的Kafka

同時，為了達到最佳的資源使用狀態，我們需要在將新的Kafka節點添加到Kubernetes集群時，通過復雜的手動設置來保持平衡狀態。這也就是為什么我們無法使用簡單的方法，來管理和確保可靠的備份和恢復策略，也難以在具有大量節點的Kafka集群上，實現災備的原因。Kubernetes集群中的數據往往被保存在pod之外，而編排器會自動spin up失敗的pod，但是Kafka卻沒有此類原生的故障防護機制。

此外，我們還需要通過第三方工具，對Kafka、ZooKeeper、以及Kubernetes的部署進行有效的監控。

KubeMQ的簡介

作為一種消息服務，KubeMQ在構建之初就考慮到了Kubernetes。它以無狀態和短暫的方式，遵循了容器架構的優秀實踐。也就是說，單個KubeMQ節點將在其整個生命周期內保持不變，且可以被預測和重現。如果需要更改配置的話，我們可以直接關閉并更換該節點。注意，此處的可重復性與Kafka不同，它意味著，KubeMQ帶有零配置設置，即：在安裝完成后無需調整配置。

作為一個能夠適應最廣泛的、消息模式的消息代理與隊列，KubeMQ可以支持如下方面：

• 具有持久性的Pub/Sub
• 支持同步和異步的請求與回復
• 至少一次性交付
• 支持各種流媒體模式
• 支持RPC

相比之下，Kafka不但只能夠支持具有持久性和流式傳輸的Pub/Sub，而且根本不支持RPC或請求/回復模式。

在資源使用方面，KubeMQ以最小的占用空間勝過了Kafka。由于KubeMQ的docker容器僅占用30MB空間，因此它有助于容錯設置，并能簡化部署。與Kafka不同的是，用戶很容易將KubeMQ添加到本地工作站中的小型Kubernetes開發環境中。同時，KubeMQ具有足夠的可擴展性，可以被部署在運行著數百個本地和云托管節點的混合環境中。這種易部署性的核心是kubemqctl。它是KubeMQ的命令行界面工具，類似于Kubernetes的kubectl。

KubeMQ優于Kafka的另一個方面在速度上。Kafka是用Java和Scala編寫而成，而KubeMQ是用Go語言編寫的，可確保其快速運行。同時，在內部基準的操作中，KubeMQ處理100萬條消息的速度，要比Kafka快20%。

在KubeMQ的“免配置”方面，通道(channel)是開發人員唯一需要創建的對象。KubeMQ通過Raft代替了ZooKeeper，同時也省去了各種代理、交換和編排器。

從監控的角度來看，我們可以通過將Prometheus和Grafana的儀表板，與KubeMQ完全集成，而無需手動集成第三方觀測類工具。盡管KubeMQ可與此類工具實現原生的集成，但是您仍然可以使用如下現有的日志記錄和監控解決方案：

• 將Fluentd、Elastic和Datadog用于監控
• 將Loggly用于記錄
• 將Jaeger和Open Tracing用于跟蹤

不過，由于Kafka不是云原生計算基金會(Cloud Native Computing Foundation，CNCF)環境的原生部分，因此它通常不支持與CNCF的工具相集成，而需要手動配置。

而在完成配置之后，它可以通過與Kubernetes的良好兼容性，實現與開源的gRPC(遠程過程調用)系統的連接。顯然，Kafka自帶的專有連接機制，不一定能夠達到該結果。

從Kafka到KubeMQ的透明遷移

KubeMQ不但部署和操作簡單，而且可以讓用戶輕松地將現有的Kafka設置，移植到KubeMQ上。為此，開發人員可以將KubeMQ的Kafka連接器，配置為專門轉換來自Kafka的消息。具體而言，KubeMQ的源連接器將被作為訂閱者，去消費(consume)來自Kafka源主題的各類消息，并將它們轉換為KubeMQ的消息格式，進而將消息發送到某個內部日志處。而KubeMQ的目標連接器，則會訂閱包含已轉換消息的輸出日志，然后將這些消息，發送到Kafka中的某個目標主題處。其具體架構如下圖所示：

Kafka與KubeMQ的集成

此外，那些被Kafka支持的任何消息傳遞模式，也都能夠被KubeMQ所支持。例如，Kafka僅支持具有持久性和流式的Pub/Sub。而作為消息隊列和代理的KubeMQ，可以完全支持Pub/Sub、同步/異步的請求/回復、交付、流模式、以及RPC。因此，從Kafka遷移到KubeMQ時，用戶無需重構應用程序代碼，即可適應復雜的邏輯變化。

小結

目前，KubeMQ可以被免費下載，并附帶有六個月的免費開發試用版。如果您正在使用 OpenShift的話，則可以在Red Hat Marketplace中使用KubeMQ，具體請參見--https://marketplace.redhat.com/en-us。此外，它還適用于包括GCP、AWS、Azure、以及DigitalOcean在內的所有主流云端環境。

總的說來，就大多數消息流量負載而言，KubeMQ內置的簡單性、輕量級、以及容器優先集成性，將能夠提供優于Kafka的性能。同時，由于它幾乎不需要任何配置，因此用戶將節省大量的管理、設置、以及遷移時間。

原文標題：KubeMQ: A Modern Alternative toKafka，作者：Michael Bogan

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