【.com快言】为了实现这个复杂的操作，必须有某种服务“邮局”来跟踪所有请求和警报。用于此的工具是消息队列。消息队列是一种专门的应用程序，充当分布式应用程序的不同服务之间或不同应用程序之间的中介。它将应用程序服务彼此解耦，确保消息接收者无论是否可用都得到处理。消息队列确保所有消息最终都被成功接收。消息队列的常见用例包括：不同应用程序之间的异步处理。基于微服务的应用程序，其中不同组件之间的可靠通信至关重要。事务排序和限制。可以从批处理的简化效率中受益的数据处理操作。必须扩展以满足突然和意外的需求变化的应用程序。应用程序必须具有足够的弹性以从崩溃和意外故障中恢复。限制长时间运行的进程的资源消耗。消息队列领域不乏供应商。AmazonWebServices、MicrosoftAzure和GoogleCloud等大型云平台都有自己的产品（AWSSimpleQueueService、Azure的ServiceBus和Google的Pub/Sub）。还有独立的通用消息代理，例如RabbitMQ、Apache的ActiveMQ和Kafka。本文介绍了一个名为KubeMQ的现代Kubernetes原生消息队列，试图了解已经在Kubernetes上使用Kafka的组织如何从中受益。什么是ApacheKafka要了解KubeMQ的全部价值，我们首先需要花一些时间了解Kafka。Kafka最初是由LinkedIn工程师创建的，作为用于跟踪LinkedIn用户活动的软件总线。它后来作为开源产品发布，如今，Kafka由Apache软件基金会开发和管理。Apache表示，超过80%的财富100强公司信任并使用Kafka。虽然是开源的，但众所周知，它是一个高度可扩展的系统，可以连接到范围广泛的事件生产者和消费者。它可以配置为使用数据流执行复杂的功能，即使在有限的网络环境中也能正常工作。凭借在线用户社区的广泛支持，Kafka还提供了多种商业产品。例如，AWS和Confluent一样提供托管的Kafka。Kafka的局限性尽管采用率很高，但Kafka并不总是消息队列系统的最佳选择。它具有单体架构，适用于本地集群或高端多虚拟机设置。鉴于Kafka需要多少内存和存储，在独立工作站上快速启动多节点集群以进行测试可能具有挑战性。简而言之，要成功地将Kafka与您的基础设施集成所需的所有复杂部分组合在一起并不容易。对于基于Kubernetes的架构尤其如此。如下图所示，基于Kubernetes的Kafka部署有不同的移动部分。除了为基本Kubernetes集群配置底层计算、网络和存储基础设施（如果您在本地实施），您还需要安装所有Kafka部分并将其与Helm等包管理器集成。这些组件可以包括管理Kafka的代理和主题的协调器，例如ZooKeeper或Mesos。其他需要注意的地方包括依赖项、日志、分区等。即使缺少一个元素或配置错误，事情也不会奏效——成功部署Kafka并非易事。Kubernetes架构上的Kafka将新的Kafka节点添加到Kubernetes集群需要复杂的手动平衡，以保持最佳的资源使用。这就是为什么没有简单的方法来管理和确保可靠的备份和恢复策略；对运行在大量节点上的Kafka集群进行灾难防护并不容易。与数据保存在pod外部并且编排器自动启动失败的pod的Kubernetes集群不同，Kafka没有这种本机故障保护机制。最后，Kafka/ZooKeeper/Kubernetes部署的有效监控需要第三方工具。什么是KubeMQKubeMQ是一种基于Kubernetes从头开始??构建的消息服务。遵循容器架构最佳实践，KubeMQ被设计为无状态和短暂的。也就是说，KubeMQ节点将在其整个生命周期内保持不变、可预测和可重现。如果需要更改配置，则关闭并更换节点。这种可重现性意味着，与Kafka不同，KubeMQ带有零配置设置，安装后不需要调整配置。KubeMQ旨在适应最广泛的消息传递模式。它是一个消息代理和消息队列，支持以下内容：Pub/Subrequest/replywithorwithoutpersistence(synchronous,asynchronous)at-most-oncedeliveryat-least-oncedeliverystreamingmodeRPC相比之下，Kafka只支持Pub/Sub具有持久性和流式传输。Kafka根本不支持RPC和请求/回复模式。在资源使用方面，KubeMQ以最小的占用空间胜过Kafka。KubeMQdocker容器只需要30MB。如此小的占用空间有助于容错设置并简化部署。与Kafka不同，将KubeMQ添加到本地工作站上的小型开发Kubernetes环境非常简单。但与此同时，KubeMQ具有足够的可扩展性，可以部署在运行在数百个本地和云托管节点上的混合环境中。这种易于部署的核心是kubemqctl，它是KubeMQ的命令行界面工具，类似于Kubernetes的kubectl。KubeMQ优于Kafka的另一个方面是它的速度。Kafka使用Java和Scala编写，而KubeMQ使用Go编写，确保快速运行。在内部基准测试操作中，KubeMQ处理100万条消息的速度比Kafka快20%。回到KubeMQ的“免配置”方面，通道是开发人员唯一需要创建的对象。您可以忘掉代理、交换器和协调器——KubeMQ的Raft代替ZooKeeper完成所有这些。从监控的角度来看，通过Prometheus和Grafana的仪表板与KubeMQ完全集成，因此您不需要手动集成第三方可观察性工具的额外工作。但是，由于KubeMQ与工具的原生集成，您仍然可以使用现有的日志记录和监控解决方案，包括：Fluentd、Elastic和Datadog用于监控Loggly，用于日志记录Jaeger和OpenTracing用于跟踪，因为Kafka不是Cloud的原生部分NativeComputingFoundation(CNCF)环境，因此通常不支持与CNCF工具集成，必须手动配置。如果配置正确，可以通过开源的gRPC远程过程调用系统建立连接，该系统以与Kubernetes的出色兼容性而闻名。Kafka自己专有的连接机制不一定能提供可比较的结果。从Kafka到KubeMQ的透明迁移除了KubeMQ易于部署和操作之外，将现有的Kafka设置迁移到KubeMQ也很简单。为此，开发人员可以从使用KubeMQKafka连接器开始。KubeMQ目标和源连接器配置为转换来自Kafka的消息。在较高的层次上，KubeMQ源连接器充当订阅者以使用来自Kafka源主题的消息，将消息转换为KubeMQ消息格式，然后将消息发送到内部日志。KubeMQ目标连接器订阅包含转换消息的输出日志，并将消息发送到Kafka中的目标主题。高层架构如下图所示：Kafka和KubeMQ集成另外，Kafka支持的任何消息传递模式都由KubeMQ支持。例如，Kafka仅支持具有持久性和流式处理的Pub/Sub。KubeMQ是一个消息队列和消息代理，支持Pub/Sub（有或没有持久化）请求/回复（同步、异步）、至少一种传递、流模式和RPC。因此，从Kafka迁移到KubeMQ时，无需重构应用代码和适配复杂的逻辑变化。最后，KubeMQ内置的简单性、轻量级和容器优先集成将为大多数工作负载提供比Kafka更好的性能。此外，所需的配置几乎为零，可节省大量管理和设置时间。正如我们提到的，迁移很简单。KubeMQ可免费下载，并提供为期六个月的免费开发试用。如果您使用OpenShift，KubeMQ可在RedHatMarketplace中获得。它还适用于所有主要的云环境，包括GCP、AWS、Azure和DigitalOcean。【翻译稿件，合作网站转载请注明原译者和出处.com】
