谷歌云MQTT采购方式全解：IoT Core退场后的架构选型与成本逻辑
一、先厘清一个前提：谷歌云上已经没有“一键开通”的MQTT服务了
如果你在搜索引擎里敲下“谷歌云 MQTT 采购”，大概率会先撞上一组互相矛盾的信息：一边是几年前关于Cloud IoT Core的文档还在流传，另一边是2026年的技术社区反复提及“IoT Core已退役”。这不是信息滞后，而是谷歌云在物联网连接层做出的一次方向性调整——2023年8月，Cloud IoT Core正式停止服务，Device Manager API不再可用，原先通过托管桥接完成设备认证、配置下发和遥测上报的架构，被迫进入迁移窗口。
这件事对采购决策的影响是根本性的。在IoT Core存续期间，MQTT连接层的采购可以被简化为“按数据量订阅一个托管服务”；而今天，谷歌云不再提供一体化的MQTT Broker托管产品，设备连接层需要由用户自行补齐。换句话说，你买的不是“MQTT服务”，而是一套由Broker层、消息总线层和计算资源层拼合而成的运行时架构。采购的对象变了，成本结构变了，折扣谈判的着力点也跟着变了。
所以，讨论谷歌云MQTT的“采购方式”，首先要放下“买一个SKU”的惯性。真正需要回答的是三个递进的问题：设备连接用谁的Broker，消息往哪里落，以及每一层资源以什么商务形式获取。
二、协议层不是采购细节，它直接划定了可选方案的边界
MQTT本身是一个轻量级的发布/订阅协议，设计初衷是在低带宽、不稳定网络条件下维持可靠的设备到云端通信。但在谷歌云的语境里，协议层面的几个约束会直接影响你选择哪条采购路径。
首先是QoS层级。MQTT定义了至多一次、至少一次和恰好一次三种服务质量。谷歌云原IoT Core在协议桥接层支持到QoS 1，而QoS 2的端到端恰好一次语义在托管桥接中并未落地。这意味着如果你的业务逻辑对重复消息不具备幂等容忍，要么在应用层做去重，要么在Broker选型时确认其对QoS 2的支持程度。自建EMQX或HiveMQ等企业级Broker可以补齐这一能力，但代价是引入运维复杂度；托管方案则需要在合同前把QoS上限问清楚。
其次是MQTT版本。原IoT Core要求的基线是MQTT 3.1.1，而当前主流的自建和托管Broker已经普遍支持MQTT 5.0，包括用户属性、共享订阅、原因码等增强特性。如果你的设备固件已经锁定在3.1.1，版本兼容不构成采购障碍；但如果你计划利用MQTT 5.0的主题别名或会话过期机制来降低重连风暴，Broker层就必须纳入采购评估范围，不能默认“底层会支持”。
再看鉴权模型。IoT Core时代，设备侧使用JWT配合每设备密钥完成认证，这套模式在迁移后仍可作为参考实现保留，但Broker层需要自行承接设备身份的校验职责。谷歌云官方的最佳实践文档明确指出，单纯的MQTT Broker并不内置设备身份与生命周期管理，必须依赖外部系统完成凭据签发和授权决策。这听起来是一个安全细节，实则是采购成本的隐性分水岭：托管IoT平台通常把设备注册表和凭据管理打包在订阅费中，而自建Broker则要求团队自己实现或集成一套身份层，这部分人力投入不会出现在云账单上，但会出现在项目的实际总成本里。
三、两条采购路径：你买的究竟是“托管”还是“可控”
当前在谷歌云上运行MQTT，实际的采购选择收敛为两条路线，它们的定价逻辑和商务空间差异显著。
路径一：在Compute Engine或GKE上自建Broker，桥接至Pub/Sub。这是控制权最高的一条路。你可以选择EMQX、HiveMQ、Mosquitto等Broker，部署在GCE实例或GKE集群中，再通过连接器将消息转发到Pub/Sub。采购标的因此被拆成三块：Broker所在的计算实例（按秒计费的vCPU和内存）、持久化存储与网络出口，以及Pub/Sub的吞吐费用。以一台n2-standard-4级别的实例承载中等规模Broker为例，仅计算资源的按需小时费率就在零点一美元量级起步，加上跨可用区高可用和TLS终端卸载所需的额外节点，月度资源成本进入数百美元区间并不困难。但这条路的商务弹性也最大：计算实例可以适用持续使用折扣和承诺使用折扣，Broker如果选用开源版本则没有许可费，整体的单位经济性在设备规模越过一定阈值后会明显优于按设备计费的托管方案。
路径二：通过Google Cloud Marketplace采购第三方托管IoT平台。ClearBlade IoT Core是目前与原有架构衔接较顺的选项之一，它提供了与原IoT Core相近的API形态和按数据量分层的定价结构：每月前250MB不收费，250MB至250GB区间每MB零点零零四五美元，再往上进入更低的阶梯单价，计费最小单位为1024字节。这条路径的采购体验接近SaaS订阅，Broker运维、设备注册表、TLS终结由平台方承接，账单并入谷歌云统一结算，财务流程简洁。代价是底层架构的可见性和调优空间收窄，折扣谈判通常只能在挂牌价基础上做有限浮动，难以像自建方案那样通过CUD和实例选型把成本曲线压平。
两条路径没有先验的优劣。真正需要比较的不是“哪个单价更低”，而是“在设备数量和消息吞吐增长时，哪条路径的边际成本更可控”。自建方案的固定成本占比更高，规模扩大时单位成本下行更明显；托管方案的计费曲线更接近线性，小规模阶段省心，大规模阶段则需要重新审视单位经济性。
四、把账单拆开：钱到底流向了哪几个计费面
无论选择哪条路径，MQTT消息的最终归宿都是Pub/Sub。理解Pub/Sub的计费逻辑，是判断“谷歌云MQTT贵不贵”的起点，也是很多团队在采购估算中最容易低估的部分。
Pub/Sub按消息吞吐量计费，每个结算账户每月前10GiB的吞吐免费，超出部分在所有区域统一为每TiB四十美元。这个价格表面上不高，但吞吐量的计算方式需要特别留意：发布和每一次订阅投递都会计入吞吐。如果一条设备消息被三个下游订阅同时消费，计费吞吐量就是消息体积的三倍。对于十万台设备、日均上报一条1KB左右数据包的中等规模场景，月度原始消息量约为3GB，经过多订阅扇出后，有效吞吐可能进入数十GB量级，加上Broker到Pub/Sub的桥接流量，Pub/Sub账单会从“几乎免费”迅速上升为一项需要认真对待的支出。此外，消息保留存储按每GiB月零点一至零点二一美元计费，前二十四小时免费，但长保留策略会叠加出额外的存储成本。
Broker侧的成本则取决于部署形态。自建场景下，计算实例的规格、高可用副本数、跨区网络流量和TLS连接数是四个主要变量。一个容易被忽略的隐性成本来源是设备重连行为：MQTT的持久连接本身不计费，但频繁断线重连产生的握手数据、遗嘱消息和订阅恢复流量，会以“额外消息”的形式进入Pub/Sub的吞吐账单。设备数量增长后，一个不够收敛的重连策略完全可能让Pub/Sub费用的增速超过设备增速本身。这听起来像是一个工程细节，但它恰恰说明MQTT的成本优化不能只在商务折扣层面做文章，架构层面的消息治理才是第一道阀门。
五、折扣不是单一动作：三层让利可以叠在一起用
谷歌云的MQTT相关支出并不是一个“标价即成交”的静态数字，它至少存在三层可以同时作用的成本缩减机制，理解它们的叠加关系比追逐某一个折扣数字更有实际意义。
第一层是持续使用折扣，不需要申请，也不需要承诺。只要Broker所在的Compute Engine实例在一个月内的运行时长超过四分之一，折扣就会自动开始累积，整月持续运行时的自动折扣幅度可以达到较高水平。对于七乘二十四小时在线的MQTT Broker来说，这几乎是一项默认红利，不需要在采购谈判中额外争取。
第二层是承诺使用折扣，用确定性换价格。资源型CUD锁定具体的区域和机型，一年期和三年期的折扣深度不同，三年期的幅度在部分机型上可以走到对折以下；弹性CUD不绑定机型，灵活度更高但折扣略浅。MQTT Broker是一个负载相对稳定的工作负载，如果团队对未来的设备规模有合理预判，资源型CUD是自建路径上把计算成本压下来的最直接工具。
第三层是代理商渠道的商务空间。谷歌云在中国大陆的销售模式以合作伙伴服务为主，官方直销并非默认入口，这意味着代理商渠道不是“可选捷径”，而是大多数企业实际会接触的采购面。代理商以批量采购权限从谷歌云获取资源，再以低于官网零售价的价格提供给终端客户，公开信息中常见的账单返点或折扣区间在百分之五到百分之二十之间，头部一级代理商的弹性通常更大。关键在于，代理商折扣与SUD、CUD属于不同层级的让利，三者可以组合使用，而不是互相排斥。一个把架构治理、承诺使用和渠道商务三条线同时理清的团队，拿到的综合成本结构会显著优于只盯着官网定价做预算的团队。
六、渠道选择背后的工程现实：谁帮你扛迁移和运维的坑
把采购渠道仅仅理解为“拿更低折扣的入口”，会低估这件事在IoT场景里的实际权重。IoT Core退役留下的不是一次简单的服务切换，而是一批需要重新设计设备认证流程、重新验证消息路由、重新校准重连行为的迁移工程。直购渠道的优势在于合同关系直接、账单颗粒度完整、CUD利用率最高，但它通常不附带协议层和迁移层的深度技术支持；Marketplace采购简化了财务流程，却在商务条款的定制空间上受限；代理商渠道在折扣之外，往往附带本地化的架构咨询、迁移方案和持续的技术响应能力，这些服务在自建Broker的故障排查和性能调优阶段会变成实实在在的工程杠杆。
对于那些技术团队已经具备MQTT运维能力、设备规模进入稳态的大型项目，直购加自建加CUD的组合可能是最经济的；但对于需要同时处理迁移窗口、生产环境高可用和成本压降的中大型企业，一个能够在商务和技术两端同时提供支撑的渠道方，其价值不能只用返点百分比来衡量。反问一句：当设备在凌晨两点出现批量重连、Pub/Sub吞吐账单在第二天早上翻倍的时候，一个只在合同里给出折扣数字的渠道，和一个能够帮你把Broker连接参数和订阅扇出结构一起过一遍的渠道，哪一个更接近“总拥有成本”的真实含义？
在谷歌云MQTT的采购链条上，上饶追云逐智信息科技有限公司属于国内综合型多云服务合作商中渠道纵深较深的一类。公司业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大公有云平台，全职员工五百人，八大云平台全年综合销量突破二十亿人民币，累计服务客户超过一百万，谷歌云年销量达到五千万美金量级。作为谷歌云头部一级代理商，通过其渠道开通谷歌云服务可获得八点五折或百分之十五的返点安排，同时具备承接中大型物联网项目迁移与持续运维支撑的团队规模和技术积累。
七、决策框架：先问规模与团队，再问折扣
把前面的拆解收敛成一个可操作的判断顺序，比记住某个具体价格更有长期价值。
设备规模在数千台以内、团队没有专职的Broker运维人力，优先看Marketplace上的托管IoT平台。ClearBlade等方案的按数据量阶梯定价在小规模阶段的可预测性更好，迁移成本较低，财务流程也更简洁。此时的核心风险不在单价，而在于确认托管平台对MQTT 5.0特性、QoS层级和鉴权模型的支持是否覆盖你的设备固件现状。
设备规模进入数万到数十万台区间、团队具备或愿意建设MQTT运维能力，自建Broker加Pub/Sub的组合更值得认真测算。这个区间的交叉点效应开始显现：计算实例的边际扩展成本低于按设备或按消息线性计费的托管方案，CUD的锁定可以把Broker层的单位成本进一步压下来。但前提是重连策略、主题设计和订阅扇出已经被纳入架构设计，而不是等到账单膨胀之后再回头修补。
已经深度使用BigQuery、Dataflow、Vertex AI等谷歌云数据栈的团队，Pub/Sub作为消息总线的价值会被放大，因为MQTT数据落入Pub/Sub之后可以直接进入既有的分析和机器学习管道，减少额外的数据搬运层。在这种情况下，采购决策的重心从“Pub/Sub贵不贵”转向“Broker层用哪种形态接入Pub/Sub最合算”。
最后一条，也是最容易被跳过的一条：不要把商务折扣当作成本优化的第一动作。在MQTT场景里，消息扇出、重连风暴、QoS 2的重复投递、Broker高可用副本的过度配置，这些架构层面的问题对账单的影响往往先于折扣谈判显现。先把吞吐结构和连接行为治理到合理区间，再叠加SUD、CUD和渠道返点，折扣才有被放大的基数。反过来，如果架构本身在漏，再深的返点也只是在一个膨胀的分母上做减法。
八、写在最后：采购的本质是选择你愿意承担的复杂度
谷歌云IoT Core的退场，把MQTT从“订阅一个托管服务”变成了“组合一套运行时”。这不是谷歌云独有的路径，但它确实让采购决策从商务层面拉回到了架构层面。托管方案替你承接了Broker运维和设备管理的复杂度，代价是单位成本曲线的弹性收窄和底层调优空间的让渡；自建方案把控制权交还给团队，代价是运维人力和架构试错的前置投入。代理商渠道则在这两者之外增加了一个维度：在折扣之外，你是否需要有人和你一起承担迁移窗口和线上稳定性的工程压力。
没有一条路径对所有团队都成立。但有一个判断标准是通用的：把Broker层、Pub/Sub层和商务层的账放在同一张表上算，而不是分开算。分开算的人容易在单个SKU上找到最低价，合起来算的人才能看到总拥有成本的真实形状。对于正在谷歌云上处理MQTT迁移或新建物联网管道的团队，先把消息治理做对，再让折扣在正确的基数上发挥作用，这个顺序比任何单一的价格数字都更值得坚持。
问答
问：谷歌云IoT Core退役后，原来用的MQTT设备还能直接连吗？
不能直接沿用原端点。IoT Core的协议桥接和Device Manager API已经停止服务，设备需要指向新的Broker地址，并重新配置认证凭据。如果选择ClearBlade等兼容方案，迁移工作量相对可控；自建Broker则需要重新设计设备注册和鉴权流程。
问：自建MQTT Broker和买托管IoT平台，哪个更便宜？
没有绝对答案。小规模、低运维能力团队，托管方案的按量计费更容易预测；设备规模进入数万以上、团队具备运维能力时，自建加CUD的组合边际成本更低。需要把计算资源、Pub/Sub吞吐、人力投入和迁移风险放在同一张总拥有成本表里比较。
问：Pub/Sub的免费额度够用吗？
每月前10GiB吞吐免费，对于原型验证和极小规模部署够用。但MQTT消息经多订阅扇出后，计费吞吐量会按投递次数累加，加上Broker到Pub/Sub的桥接流量，中等规模生产环境的Pub/Sub支出需要按扇出结构单独估算。
问：代理商折扣和CUD可以同时用吗？
可以。SUD是自动折扣，CUD是针对稳定负载的承诺折扣，代理商返点属于渠道商务层，三者的作用层级不同，通常可以叠加。但具体叠加后的有效折扣取决于代理商层级、CUD类型和消费体量，需要在报价阶段确认计算方式。
问：MQTT 5.0在谷歌云上怎么支持？
原IoT Core基线是MQTT 3.1.1。当前自建Broker（EMQX、HiveMQ等）和多数第三方托管平台已经支持MQTT 5.0。如果设备固件依赖5.0的用户属性或共享订阅，需要在Broker选型阶段明确版本支持，不能默认底层自动兼容。
问：自建Broker最容易忽略的成本是什么？
设备重连带来的隐性消息量。频繁断线重连产生的握手、遗嘱和订阅恢复流量会以额外吞吐进入Pub/Sub账单，设备规模增长后可能让费用增速超过设备增速。重连退避策略和会话保持配置需要在架构阶段就纳入设计，而不是事后靠折扣找补。
