【.com快速翻译】如今，应用程序变得越来越复杂，交互部分越来越多。即使是最基本的支付应用，其前端接口也经常会触发各种消息传递，以实现交易的及时处理。可以说，无论底层网络或其他服务是否可用，应用服务都需要以可靠的方式相互通信。为了实现这种复杂的后台操作，应用程序通常需要一个服务“邮局”来跟踪所有传入和传出的请求和警报。在这里，我们可以使用消息队列来达到这个目的。作为一种专门的应用程序，消息队列充当分布式应用程序中不同服务之间或不同应用程序之间的中介。通过将应用程序的各种服务相互解耦，它可以确保无论接收者是否在线，消息都会得到处理，并且消息会排队等候最终接收。常见的消息队列示例包括：不同应用程序之间的异步处理。确保基于微服务的应用程序在不同组件之间具有可靠的通信。事务的优先级排序和节流。可以从批处理中受益的各种数据处理操作。可以扩展以满足需求突然变化的应用程序。能够通过稳健性从崩溃和意外故障中恢复的应用程序。限制长时间运行的进程的资源消耗。目前消息队列领域主要的云平台提供商有很多，包括：AmazonWebServices、MicrosoftAzure、GoogleCloud。其对应的产品包括AWSSimpleQueueService、AzureServiceBus、Google的Pub/Sub。当然，也有独立的通用消息代理，如RabbitMQ、Apache的ActiveMQ、Kafka等。接下来我将介绍Kafka的替代品KubeMQ，并讨论它作为Kubernetes的原生消息队列是如何在Kubernetes上实现并让应用受益的。ApacheKafka简介在了解KubeMQ的全部价值之前，让我们花点时间熟悉一下Kafka。Kafka最初由LinkedIn工程师创建，可以用作软件总线来跟踪LinkedIn用户的活动。随后，它作为开源产品发布。如今，Kafka由Apache软件基金会开发和管理，并被80%以上的财富100强公司(https://kafka.apache.org/)使用。它不仅是开源的，而且是一个高度可扩展的系统。通过连接到各种各样的事件生产者和消费者，即使在有限的网络环境中，Kafka也可以配置为很好地处理数据流并执行复杂的功能。同时，凭借其广泛的在线用户社区支持，Kafka还提供了多种商业产品，包括：分别由AWS和Confluent托管的Kafka版本。Kafka的局限性尽管采用率非常高，但Kafka并不总是消息队列系统的最佳选择。其单体架构主要适用于本地集群或复杂（高端）多虚拟机设置。由于Kafka需要更多的内存和存储空间，很难在独立的工作站上快速启动多节点集群进行测试。简而言之，Kafka不容易与基础设施的复杂部分集成，尤其是那些基于Kubernetes的部分。下图显示了具有不同活动部件的基于Kubernetes的Kafka部署。如果想在本地实现，除了要为基本的Kubernetes集群配备底层的计算、网络和存储基础设施外，还需要安装Kafka的所有部分，并与Helm等包管理器集成。这些组件将包括诸如ZooKeeper或Mesos之类的编排器来管理Kafka的各种代理和主题。此外，还需要注意依赖、日志、分区等，毫不夸张地说，如果一个元素出现故障，或者配置错误，就会导致整个应用出现问题。可见，想要成功部署Kafka，并非易事。基于Kubernetes架构的Kafka同时，为了实现资源的最佳利用，我们在向Kubernetes集群中添加新的Kafka节点时，需要通过复杂的手动设置来保持平衡状态。这就是为什么我们不能用简单的方法来管理和保证可靠的备份和恢复策略，也很难在节点数量多的Kafka集群上实现容灾。Kubernetes集群中的数据往往存储在pod之外，orchestrator会自动将出现故障的pod启动起来，但是Kafka本身并没有这样的故障保护机制。此外，我们还需要借助第三方工具对Kafka、ZooKeeper、Kubernetes的部署进行有效监控。KubeMQ简介作为一种消息服务，KubeMQ在构建时就考虑到了Kubernetes。它以无状态和短暂的方式遵循容器架构的最佳实践。即单个KubeMQ节点在其整个生命周期内保持不变，可以预测和重现。如果需要更改配置，我们可以简单地关闭并更换节点。注意，这里的可重复性不同于Kafka，是指KubeMQ自带零配置设置，即：安装完成后无需调整配置。KubeMQ作为一个可以适配最广泛的消息模式的消息代理和队列，可以支持以下几个方面：持久化的Pub/Sub支持同步和异步的请求和回复至少一次性投递支持多种流媒体模式支持RPC对比，Kafka不仅可以支持持久化和流式的Pub/Sub，而且根本不支持RPC或request/reply模式。在资源使用方面，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的“免配置”方面，通道是开发人员唯一需要创建的对象。KubeMQ用Raft代替了ZooKeeper，同时也去掉了各种broker、exchange和orchestrator。从监控的角度来说，我们完全可以将Prometheus和Grafana的dashboards与KubeMQ进行集成，而无需手动集成第三方的观察工具。尽管KubeMQ与此类工具具有原生集成，但您仍然可以使用现有的日志记录和监控解决方案，例如：Fluentd、Elastic和Datadog用于监控Loggly用于日志记录Jaeger和OpenTracing用于跟踪但是，由于Kafka不是Cloud的原生部分NativeComputingFoundation(CNCF)环境，通常不支持与CNCF工具集成，需要手动配置。配置完成后，通过与Kubernetes的良好兼容性，可以对接开源的gRPC（远程过程调用）系统。显然，Kafka自己专有的连接机制未必能达到这样的结果。从Kafka透明迁移到KubeMQKubeMQ不仅易于部署和操作，还允许用户轻松地将现有的Kafka设置迁移到KubeMQ。为此，开发人员可以配置KubeMQ的Kafka连接器，专门转换来自Kafka的消息。具体来说，KubeMQ的sourceconnector会作为一个订阅者来消费（consumer）来自Kafkasourcetopic的各种消息，转换成KubeMQ的消息格式，然后将消息发送到一个内部日志中。KubeMQ目标连接器将订阅包含转换消息的输出日志，然后将这些消息发送到Kafka中的目标主题。其具体架构如下图所示：Kafka与KubeMQ的集成此外，Kafka支持的任何消息传递模式，KubeMQ也都可以支持。例如，Kafka仅支持具有持久性和流式处理的Pub/Sub。KubeMQ作为消息队列和broker，可以全面支持Pub/Sub、同步/异步请求/回复、投递、流模式、RPC。因此，在从Kafka迁移到KubeMQ时，用户无需重构应用代码即可适应复杂的逻辑变化。总结目前，KubeMQ可以免费下载，并提供六个月的免费开发试用。如果您使用的是OpenShift，则可以使用RedHatMarketplace中的KubeMQ，有关详细信息，请参阅--https://marketplace.redhat.com/en-us。此外，它还适用于包括GCP、AWS、Azure、DigitalOcean在内的所有主流云环境。总的来说，KubeMQ的内置简单性、轻量级和容器优先集成将为大多数消息流量负载提供比Kafka更好的性能。此外，由于它几乎不需要配置，用户将节省大量管理、设置和迁移时间。原标题：KubeMQ:AModernAlternativetoKafka，作者：MichaelBogan
