如今，随着交互式部件的增多，应用程序变得越来越复杂。即使是最基本的支付类应用，其前端接口也时常会触发各种消息传递，以实现交易的及时处理。可以说，无论底层网络或其他服务是否可用，应用服务之间都需要通过一种可靠的方式，来相互通信。
为了实现此类复杂的后台操作，应用程序往往需要一种服务“邮局”，来跟踪所有往来的请求和警报。在此，我们可以运用消息队列来实现该目标。作为一种专门的应用程序，消息队列充当了在分布式应用程序的不同服务之间、或不同应用程序之间的中介角色。通过将应用程序的各个服务彼此分离，它可以确保无论消息接收者是否在线，都能够对消息进行处理，并可以让消息队列最终被接收到。
常见的消息队列示例包括：
- 不同应用程序之间的异步处理。
- 确保不同组件之间能够实现具有可靠通信的、基于微服务的应用程序。
- 事务的优先级排序和限流。
- 各种可以从批处理中受益的数据处理操作。
- 那些可以通过扩展，来满足突发需求变化的应用程序。
- 能够通过鲁棒性，从崩溃和意外故障中恢复的应用程序。
- 通过长期运行的进程，限制消耗资源。
目前，在消息队列领域不乏各大云平台供应商，其中包括：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】
原文链接：https://cloud.51cto.com/art/202110/686212.htm