KubeMQ简介，阿里Golang研发岗二面

最新推荐文章于 2024-08-07 10:12:31 发布

2401_84253251

最新推荐文章于 2024-08-07 10:12:31 发布

阅读量1k

点赞数 27

分类专栏：程序员文章标签： golang 开发语言后端

本文链接：https://blog.csdn.net/2401_84253251/article/details/137709859

版权

17 篇文章 1 订阅

订阅专栏

由于 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 基础架构）。但是，总的来说，与主要云提供商提供的同等托管服务相比，它仍然需要更多的管理和运营开销。特别是如果您花费大量时间对其进行优化以满足您的扩展目标。

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