译文
作者:陈峻 2021-10-19 09:00:00
云计算
Kafka 本文将向您介绍一种作为Kafka替代品的KubeMQ,讨论它作为Kubernetes的原生消息队列,是如何在Kubernetes上实施,并让应用从中受益。
公司主营业务:网站设计制作、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。成都创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联公司推出崇礼免费做网站回馈大家。
【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上实施,并让应用从中受益。
在了解KubeMQ的全部价值之前,先让我们花一些时间来熟悉一下Kafka。最初由LinkedIn工程师创建的Kafka,可作为软件总线(software bus)被用于跟踪LinkedIn用户的各项活动。随后,它被作为开源的产品发布出来。如今,Kafka已由Apache软件基金会开发和管理,并被超过80%的财富100强公司所使用(https://kafka.apache.org/)。它不但开源,而且是一个高度可扩展的系统。通过广泛地连接到各类事件生产者和消费者,Kafka可以被配置为,即使在有限的网络环境中,也能够很好地使用数据流,并执行各项复杂的功能。同时,凭借着其拥有广泛的在线用户社区支持,Kafka还提供了多种商业产品,其中包括:由AWS和Confluent分别提供托管的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在构建之初就考虑到了Kubernetes。它以无状态和短暂的方式,遵循了容器架构的优秀实践。也就是说,单个KubeMQ节点将在其整个生命周期内保持不变,且可以被预测和重现。如果需要更改配置的话,我们可以直接关闭并更换该节点。注意,此处的可重复性与Kafka不同,它意味着,KubeMQ带有零配置设置,即:在安装完成后无需调整配置。
作为一个能够适应最广泛的、消息模式的消息代理与队列,KubeMQ可以支持如下方面:
相比之下,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可与此类工具实现原生的集成,但是您仍然可以使用如下现有的日志记录和监控解决方案:
不过,由于Kafka不是云原生计算基金会(Cloud Native Computing Foundation,CNCF)环境的原生部分,因此它通常不支持与CNCF的工具相集成,而需要手动配置。
而在完成配置之后,它可以通过与Kubernetes的良好兼容性,实现与开源的gRPC(远程过程调用)系统的连接。显然,Kafka自带的专有连接机制,不一定能够达到该结果。
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,一种Kafka的替代品
网站链接:http://www.gawzjz.com/qtweb/news43/161993.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联