|
|
|
|
公众号矩阵

KubeMQ,一种Kafka的替代品

本文将向您介绍一种作为Kafka替代品的KubeMQ,讨论它作为Kubernetes的原生消息队列,是如何在Kubernetes上实施,并让应用从中受益。

作者:陈峻来源:51CTO|2021-10-19 09:00

 

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

【编辑推荐】

  1. Kubernetes API 流量查看神器 - Mizu
  2. 值得推荐的九大Kubernetes仪表板工具
  3. 网络安全工程师教你:100多个Kali Linux白帽子与计算机安全工具正确使用技巧
  4. MIT开发新AI工具 加速新3D打印材料的发现
  5. 扫地机器人存漏洞!或可秒变窃听偷窥工具
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

带你轻松入门 RabbitMQ

带你轻松入门 RabbitMQ

轻松入门RabbitMQ
共4章 | loong576

50人订阅学习

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

14人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

42人订阅学习

视频课程+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微