如今，企业组织之间的竞争是残酷的。每个组织都希望在其系统之间即时、实时或近乎实时地交换信息，以便做出更好、更快的决策。为了使此类信息持续流动，应用程序组件之间的集成需要无缝。为了充分利用云计算的所有优势，如今构建的应用程序需要是云原生的、灵活的、可扩展的，并且可以快速部署。这样的应用程序被拆分为几个称为微服务的小组件。每个微服务都可以独立于其他微服务运行。每个服务都需要有一种方式来相互通信，以便它们可以协同工作。这就是消息代理的用武之地。消息代理是混合环境中的云组件与本地系统之间的通信连接器。

面向企业的完整消息传递解决方案

您可以在具有不同企业云环境的不同域中针对各种业务问题实施消息代理。它们是应用程序间通信的最佳选择，并确保消息（信息数据包）按要求传递。您通常可以在金融交易和支付处理、电子商务订单处理和履行、保护高度敏感数据等中找到消息代理。物联网 （IoT） 的兴起引入了许多产生大量数据的电子设备。在这里，通信发生在机器之间，电子设备相互通信。在这个级别上，消息代理也用于设备之间的实时通信，这对于数据分析和商业智能至关重要，使您能够实时为客户提供服务。

您必须可靠地存储消息并保证消息的传递，以确保应用程序之间的通信正确发生。为此，消息代理使用称为消息队列的组件。我们可以优化消息队列，以对消息进行排序和存储，直到应用程序使用它们。消息队列按传输的确切顺序存储消息，并且它们一直保留在队列中，直到应用程序收到它们。

因此，从根本上说，消息队列用于通过发送和接收消息数据来促进应用程序之间的通信。应用程序收到消息数据后，应用程序将使用它们与数据库、业务逻辑和 Web 浏览器进行交互。消息队列不知道消息数据包中的内容。消息队列是一个可靠且安全的传输层，用于在应用程序之间移动数据。它们使用一堆应用程序编程接口来发送和接收消息数据。这些应用程序编程接口支持所有平台上的 Visual Basic、Java、C、COBOL 等。

KubeMQ 简介

KubeMQ 是一个企业级、实时、高可用、可扩展且安全的消息代理和消息队列，也是 Kubernetes 原生解决方案。该工具也是轻量级的，因此我们可以在一分钟内将 KubeMQ 部署到容器中。KubeMQ 容器大小仅为 30 MB。KubeMQ 是一个 Go 编程语言应用程序。KubeMQ 可以轻松与 Prometheus、Datadog、Zipkin 等第三方工具集成，以及许多其他云原生应用程序。KubeMQ 是支持高效内存使用和低延迟的大容量消息传递的消息队列。消息传递工具还支持多种消息传递模式，例如发布-订阅（又名发布/订阅）、持久队列、基于 CQRS 的 RPC 流。

与 Kafka、RabbitMQ 或 ActiveMQ 相比，该工具是一个相对较新的解决方案。但是在 Kubernetes 方面，KubeMQ 比其他平台有很大的优势。KubeMQ 是一个 Kubernetes 原生消息代理，因此只需一个命令即可将该工具部署在 Kubernetes 集群上，无需任何额外的清单或模板。这是企业组织选择 KubeMQ 的主要原因之一，如果他们的应用程序运行在 Kubernetes 集群上。

如果您是企业组织，则可以使用 KubeMQ 将您的开发和运营工作流程集成到一个统一的系统中，从而节省大量金钱和时间。您也无需成为专家即可使用该工具，因为它使用起来非常简单且对 DevOps 友好。KubeMQ 可帮助您加快开发和生产周期。

KubeMQ 的主要功能

• 一个用于 Kubernetes 后端的分布式基础架构消息传递平台
• 超快、小巧、轻量级的 Docker 容器。
• 消息传递支持至少一次、最多一次且恰好一次的传递模型。
• 支持基于 FIFO 的持久队列、RPC 命令、具有持久性的发布-订阅（事件存储）、发布-订阅事件和查询消息传递模式。
• 支持 WebSocket 传输协议、REST 和 gRPC，支持 TLS。
• 内置跟踪、指标和缓存。
• 该工具提供了一个流畅的监控仪表板。
• 提供 Go、Java、Python、C#、PHP、Ruby、Node、jQuery 和 cURL 的 SDK。
• 不需要消息代理配置。

KubeMQ 的优缺点

优点：

• KubeMQ 创始人团队由一群 IT 资深人士组成，在开发强大且可扩展的技术方面拥有 20 多年的经验。
• KubeMQ 现在在生产环境中实时支持数十亿条消息。
• 与金融、医疗保健、电子商务、电信和网络系统轻松集成。
• 加快您的开发和生产周期。
• 为组织节省了大量运营成本。
• 支持一组丰富的连接器来连接微服务。

缺点：

• 在与 SQL 系统集成时存在一些限制。
• NodeJs 的 SDK 很难遵循。
• 目前还没有官方的 KubeMQ 社区。
• 尚不存在对 C# 客户端库的跟踪支持。

解决方案用例和注意事项

由于 KubeMQ 是一个 Kubernetes 原生解决方案，因此该工具有几个地方真正闪耀，也有几个方面可能和将会出现挑战。在大多数复杂的架构设计中，对于任何关键解决方案组件，都没有灵丹妙药，也没有万能的答案，KubeMQ 也不例外。

优点

• 这个工具很容易与依赖它的 Kuberntes 工作负载一起部署，使 KubeMQ 从本地开发到生产的整个过程中都很容易使用。
• 作为 Kubernetes 工作负载本身，该工具非常适合您希望在不同云提供商之间或云与本地之间提供一致的消息传递/队列解决方案的情况。
• KubeMQ 解决了许多消息传递需求，使其成为一个可以代替其他几个解决方案的单一解决方案。对于方案一，如果您需要发布/订阅、工作线程消息队列和流式队列，以便单独跟踪生产者和使用者。场景二，在 AWS 中，您可能需要将 SQS、SNS 和 Managed Streaming for Kafka 用作离散服务。KubeMQ 可以做到这一切。

缺点

• 默认情况下，Kubernetes 不一定能为你提供一个很好的基础设施环境来运行 KubeMQ 可以支持的所有用例。一些 KubeMQ 使用案例需要高速本地存储才能获得良好的吞吐量，如果您将其放入 AWS 中的典型 EKS 集群中，您可能会发现 gp2（或 gp3）EBS 存储的组合不足以满足您的流工作负载来处理您的创建者卷。您可能还会发现，您没有小型通用工作线程节点实例所需的网络吞吐量，无法限制流量。您可能需要拥有具有本地 NVMe 和高速网络的特殊工作节点，然后进行高级设置以确保 KubeMQ 仅在那里运行并专门使用这些高速卷。
• 虽然 KubeMQ 解决了许多用例，但它可能不是最适合、最快或最具可扩展性的选项。对于纯工作线程队列使用案例，您只需插入 AWS SQS 之类的工具，即可支持大规模扩展，而无需思考、工作或规划。对于具有 AWS SNS 等选项的大规模发布/订阅，情况类似。
• 增加 基于 Kubernetes 的解决方案（如 KubeMQ）的运营开销与管理专用 VM 的负担几乎不同（假设您现在已经在管理 Kubernetes 基础架构）。但是，总的来说，与主要云提供商提供的同等托管服务相比，它仍然需要更多的管理和运营开销。特别是如果您花费大量时间对其进行优化以满足您的扩展目标。

由您来决定灵活性的优势是否超过运营开销的优势，有时诸如多云要求（以及因此需要配置/支持来自不同提供商的不同托管服务）或需要支持在云和本地运行工作负载等因素将有助于明确哪种架构适合您。

结论

在这种数字化工作中，软件开发人员经常面临在应用程序/服务之间发送和接收消息数据的问题。在开发此类工具之前，开发人员使用端点进行通信和消息交换，但现在您有了消息代理和消息队列。这些是企业组织用于在应用程序/服务之间进行通信的现代、可靠和安全的方式。由于 KubeMQ 是 Kubernetes 原生的，因此该工具非常适合作为 Kubernetes 集群上的消息传递系统。