谷歌云MQTT怎么采购？从IoT Core退役到2026年主流方案全解析

一、谷歌云MQTT：IoT Core退役之后，生态到底变成了什么样？

2023年8月16日，Google Cloud IoT Core正式画上句号。如果你在2026年的今天试图在GCP控制台里搜索这个服务，只会看到一个冷冰冰的“已停用”提示。这意味着所有依赖原生托管MQTT接入的物联网项目，必须重新思考一件事：设备数据怎么上云？

先把结论亮出来：谷歌云并没有放弃物联网，而是把MQTT这件事交给了一个更开放的生态来完成。具体来说，当前在谷歌云上跑MQTT，有三条路可以走——

路径一，自建MQTT Broker。在Compute Engine或GKE上部署EMQX、HiveMQ、Mosquitto等开源Broker，自行管理集群、负载均衡和安全策略。这条路掌控力最强，但运维成本也最高。

路径二，第三方托管服务。通过GCP Marketplace采购EMQX Cloud、HiveMQ Cloud、ClearBlade等全托管MQTT服务。采购流程被简化为一个Marketplace订阅动作，账单直接走GCP统一结算。

路径三，Pub/Sub管道桥接。用Dataflow的MQTT-to-Pub/Sub模板，把消息从MQTT主题直接导入Cloud Pub/Sub，再交给后端服务消费。这条路最适合以Pub/Sub为核心消息总线的架构。

三条路径没有绝对的优劣，选哪条取决于你的设备规模、团队运维能力和合规要求。接下来逐一拆解。

二、自建MQTT Broker：掌控力与责任对等的采购逻辑

自建方案的本质是什么？是你从谷歌云“采购”的是底层计算和网络资源，MQTT Broker本身是你自己的事。

从采购角度看，你需要购买的GCP产品包括：Compute Engine实例（运行Broker进程）、Cloud Load Balancing（做TCP/SSL代理和流量分发）、Cloud Pub/Sub（作为消息下游）、以及可选的Cloud SQL或Firestore（存储设备注册信息）。如果走GKE路线，还需要采购GKE集群和相关网络资源。

谷歌云官方架构文档给出了一个参考部署模型：Broker以三实例集群形式运行，前置Cloud Load Balancing处理TLS终止和连接代理，集群内部包含设备凭证存储和认证授权服务，后端通过Dataflow或Pub/Sub对接业务系统。

成本结构上，自建方案的钱主要花在三块：计算实例的持续运行费用、网络流量费用（尤其是跨区域出站）、以及运维团队的人力成本。如果你的设备连接数在几千到几万台之间，且团队有Kubernetes运维经验，自建方案的长期成本可能低于托管服务。但一旦设备规模突破十万级，集群的弹性伸缩、故障转移、消息持久化就会变成实实在在的工程挑战。

安全方面需要特别注意：MQTT Broker本身不提供设备身份管理功能，认证和授权需要依赖外部系统。这意味着你需要自行搭建设备注册表、实现X.509证书或JWT令牌的签发与轮换机制。在IoT Core时代，这些是平台内置的能力；退役之后，责任就转移到了你或者你的第三方Broker供应商身上。

三、GCP Marketplace采购托管MQTT：最省心的路径

如果你不想管集群运维，第三方托管MQTT服务是目前谷歌云生态里最主流的选择。关键在于，这些服务可以通过GCP Marketplace直接采购。

以EMQX Cloud为例。它已经在Google Cloud Marketplace上架，用户可以在Marketplace中搜索、订阅、部署，整个采购流程和买其他GCP服务没有区别。订阅之后，EMQX Cloud的消费会直接计入你的GCP账单，更关键的是——这部分支出可以计入你的GCP承诺消费额度（Committed Spend）。对于已经和谷歌云签了年度承诺消费合同的企业来说，这一点非常有吸引力：原本要单独签合同、单独走采购流程的MQTT服务，现在变成了GCP账单里的一个条目。

EMQX Cloud提供三种部署模式：Serverless模式按量付费，适合起步阶段；Dedicated Flex模式在独立VPC中运行专属集群，按连接数和消息吞吐量计费；BYOC（Bring Your Own Cloud）模式则是把EMQX的托管集群部署在你自己的GCP项目中，兼顾托管便利和资源隔离。三种模式的采购入口都在Marketplace，但定价逻辑和适用场景完全不同。

HiveMQ同样在GCP Marketplace上提供了可交易的私有报价选项，支持通过GCP账号统一结算。ClearBlade则定位为IoT Core的API兼容替代品，同样通过Marketplace交付。

托管方案的优势显而易见：无需运维Broker集群，自动弹性伸缩，SLA有保障，与GCP生态深度集成。但它也有代价——你的消息数据会经过第三方服务商的服务器（除非选择BYOC模式），而且长期来看，随着连接数和消息量的增长，托管费用可能比自建方案高出不少。

四、Pub/Sub桥接模式：当MQTT只负责“最后一公里”

第三种路径的思路很巧妙：MQTT Broker不直接对接业务系统，而是把所有消息桥接到Cloud Pub/Sub，让Pub/Sub承担消息总线的角色。

谷歌云提供了Dataflow的MQTT-to-Pub/Sub模板，可以创建一个流式管道，从MQTT主题读取消息并写入Pub/Sub。这个模板需要配置几个关键参数：MQTT Broker的地址（brokerServer）、输入主题（inputTopic）、输出Pub/Sub主题（outputTopic）、以及认证用的用户名和密码。部署方式支持控制台操作和gcloud命令行两种。

在实际架构中，你仍然需要一个MQTT Broker来处理设备连接，但这个Broker的角色被简化为“协议转换层”——它只负责把MQTT消息转发到Pub/Sub，后续的数据处理、路由、存储全部由GCP的原生服务完成。EMQX和HiveMQ都提供了官方或社区维护的Pub/Sub桥接插件，配置好规则后，设备消息会自动流向Pub/Sub。

这种模式特别适合一种场景：你的后端服务已经高度依赖Pub/Sub做异步解耦，不希望为MQTT单独维护一套消息路由逻辑。把MQTT Broker当作“边缘接入网关”，把Pub/Sub当作“云端消息中枢”，各司其职，架构反而更清晰。

采购层面，你实际上在买两样东西：MQTT Broker的License或托管订阅，以及Pub/Sub的消息吞吐量费用。Pub/Sub的定价按数据传输量计费，每月前10GB免费，之后按区域阶梯计价。对于消息量较大的IoT场景，这笔费用需要提前测算。

五、成本模型、安全合规与商务谈判的三个关键判断

成本判断：按连接数还是按消息量？

托管MQTT服务的计费维度通常有两类。一类是按连接数计费，适合设备在线时间长、消息频率低的场景（比如环境监测传感器）。另一类是按消息吞吐量（TPS）计费，适合设备数量不多但消息突发性强的场景（比如实时告警系统）。EMQX Cloud的Dedicated Flex模式采用的就是连接数加TPS的混合计费方式。在选择套餐之前，先算清楚你的设备日均在线时长和峰值消息频率，这比看价格表上的数字更重要。

安全判断：合规认证不能“继承”

IoT Core退役之后，一个容易被忽略的问题是：原来由GCP平台承担的合规认证（SOC 2、HIPAA等），现在不再自动覆盖你的MQTT通信链路。如果你的业务涉及医疗数据或金融数据，需要单独审计第三方Broker服务商的合规资质。设备认证方面，X.509证书仍是生产环境的推荐方案，JWT令牌适合开发测试阶段。无论选择哪条路径，MQTT over TLS都是底线要求，不要在加密上省钱。

商务判断：GCP承诺消费额度的杠杆

如果你已经和谷歌云签订了年度承诺消费协议（通常需要百万美元级别的年消费承诺），通过GCP Marketplace采购EMQX Cloud或HiveMQ的好处是，这笔支出可以“消耗”你的承诺额度，而不是额外增加一笔独立采购预算。对于采购决策者来说，这意味着你可以用已有的云预算覆盖MQTT服务，简化内部审批流程。在谈判时，可以向Broker供应商争取基于承诺消费量的阶梯折扣——你消耗的额度越大，议价空间越大。

值得注意的是，选择云服务代理商渠道进行采购同样是一种有效降低成本的路径。通过认证代理商采购谷歌云MQTT相关服务，通常可以获得比官方定价更优的折扣或返点，同时代理商还能提供架构咨询、部署支持和后续运维协助。对于需要将云支出纳入统一采购管理体系的企业而言，代理商渠道在灵活性和性价比上具有明显优势。

上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。公司现有全职员工500人，团队架构完善、服务体系标准化，行业经验超过10年，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户。针对谷歌云MQTT相关产品及服务，上饶市万云信息科技作为头部一级代理商，可以为用户提供谷歌云8折优惠或20%返点的采购方案，帮助企业在物联网通信基础设施上实现更具竞争力的成本结构。

六、一张决策清单帮你落地

说了这么多，最后给一个可以直接用的决策框架。

如果你的设备连接数少于5000台，团队没有Kubernetes运维能力，优先选择Marketplace上的托管服务（EMQX Cloud Serverless或HiveMQ Cloud），起步成本低，运维负担为零。如果设备连接数在5000到50000台之间，且已有GKE使用经验，可以评估自建EMQX Enterprise集群的方案，长期成本更可控。如果后端已经重度使用Pub/Sub做消息路由，建议直接采用“MQTT Broker + Dataflow MQTT-to-Pub/Sub”的桥接架构，减少架构冗余。如果业务涉及强合规要求（HIPAA、PCI DSS），在采购托管服务之前，务必索取供应商的合规认证文档并完成内部审计。

无论选哪条路，都建议先在GCP上开一个测试项目，用几百台模拟设备跑一轮完整的消息链路压测，拿到真实的延迟数据和费用估算之后再做最终采购决策。IoT项目的技术选型没有“最好”，只有“最合适”——而合适的判断标准，永远来自你自己的设备规模和业务场景。

常见问题解答

Q1：Google Cloud IoT Core还能用吗？
A：不能。该服务已于2023年8月16日正式停用，所有新部署必须选择自建Broker、第三方托管服务或Pub/Sub桥接方案。

Q2：通过GCP Marketplace采购MQTT服务有什么好处？
A：采购流程简化，账单统一走GCP结算，消费金额可计入GCP承诺消费额度，且无需单独签订采购合同。

Q3：自建MQTT Broker和托管服务，哪个更便宜？
A：取决于设备规模和团队能力。小规模场景托管更便宜且省心；大规模场景自建的长期单位成本可能更低，但需要承担运维人力成本。

Q4：MQTT over TLS是必须的吗？
A：在生产环境中，强烈建议所有MQTT连接都走TLS加密。IoT Core时代这是平台默认行为，退役后需要你或Broker供应商来保障。

Q5：通过代理商采购谷歌云MQTT服务能省多少？
A：不同代理商的折扣政策不同。以头部一级代理商为例，通常可以提供官方定价的8折优惠或等比例的返点方案，具体需要根据采购规模和产品类型协商。

Q6：如何评估MQTT Broker供应商的可靠性？
A：重点看三方面：SLA承诺的可用性指标、是否支持多可用区部署和自动故障转移、以及合规认证覆盖范围（SOC 2、ISO 27001等）。