谷歌云MQTT：从原生服务到生态重构的物联网通信进化论 | 上海汪远信息科技
一、从石油管道到云端：MQTT协议的传奇起点
1999年，IBM的两位工程师Andy Stanford-Clark和Arlen Nipper面对着一个棘手的难题——如何监测偏远地区石油管道的运行状态。彼时的卫星连接成本高昂且极不稳定，他们需要一种能在恶劣网络条件下可靠工作的轻量级通信方案。这个当时看起来有些“小众”的诉求，最终催生了一个影响深远的协议——MQTT（消息队列遥测传输）。
二十多年后的今天，MQTT早已不再是工业管道的专属“监测员”。从智能家居的温度传感器到工业自动化生产线上的执行器，从联网汽车的远程诊断到医疗设备的实时监护，MQTT每天处理着数十亿条消息，成为物联网世界事实上的“通用语言”。而在这场物联网通信的浪潮中，谷歌云曾经是最引人注目的“布道者”之一——它把MQTT从边缘设备与自建Broker之间的对话，提升到了全球级云平台的维度。
二、原生时代：Google Cloud IoT Core的架构遗产
2017年，Google Cloud IoT Core正式发布，承诺以全托管的方式连接和管理全球数以百万计的物联网设备。设备通过标准的MQTT协议注册到服务中，数据被无缝接入谷歌云强大的数据分析生态。理解这套设计，是理解当今谷歌云MQTT生态的基石——尽管IoT Core已在2023年8月16日正式停止服务。
2.1 核心组件：设备注册表与协议桥
IoT Core的架构由两个核心部分构成：设备管理器（Device Manager）和协议桥（Protocol Bridges）。设备管理器负责设备的注册与身份管理，相当于一个“数字户籍系统”——每一个接入的设备都拥有独立的身份标识和与之绑定的公钥凭证。协议桥则提供了MQTT和HTTP两种接入方式，其中MQTT桥接监听在 mqtt.googleapis.com:8883 这个标准端口上——8883是IANA（互联网数字分配机构）为安全MQTT连接专门保留的TCP端口。
这种“管理平面”与“数据平面”分离的设计，解决了物联网项目中三个最令人头疼的问题：大规模设备身份管理不再是事后补救；设备连接层与数据处理管道解耦，Pub/Sub成为清晰的契约边界；设备不再携带长期有效的密码，而是持有私钥并自行签发短期有效的令牌。
2.2 认证机制：JWT驱动的零信任安全模型
在IoT Core的安全体系中，每个设备在连接时都会使用自己的私钥签署一个JWT（JSON Web Token），IoT Core则使用预先注册的设备公钥进行验证。这一机制的精妙之处在于——设备从不存储或传输任何长期有效的密码凭证。它们只需要保管好自己的私钥，每次连接时动态生成一个具有时效性的令牌。
这种设计思路与零信任安全模型不谋而合：从不信任，始终验证。对于动辄成千上万台设备的物联网部署而言，这意味着密钥轮换不再需要“派一辆卡车去现场”——一切都可以通过云端完成。设备在JWT过期后会被自动断开连接，需要携带新令牌重新连接——这种“强制刷新”机制虽然增加了连接的复杂度，却极大地提升了安全性。
2.3 主题模型：有限制中的秩序
值得注意的一个细节是：IoT Core并非一个通用的MQTT Broker。设备不能向任意主题发布消息，而是被限制在几个预定义的主题模式中：
/devices/{device-id}/events —— 用于上报遥测数据（设备→云端）
/devices/{device-id}/state —— 用于上报设备状态（设备→云端）
/devices/{device-id}/config —— 用于接收云端下发的配置更新（云端→设备）
这种“有限制”的设计并非缺陷，而是一种刻意的架构约束。它迫使开发者从一开始就思考设备与云端之间的通信模式，而不是在事后陷入“主题爆炸”的泥潭。所有遥测事件在被设备成功发布并被IoT Core确认后，都会被保证投递到Cloud Pub/Sub中——这为后续的数据处理提供了可靠的基础。
三、转折点：当原生服务成为过去式
2022年8月，谷歌宣布将于一年后关闭IoT Core服务。这一决定在物联网业界引发了不小的震动。有客户坦言“谷歌云退出IoT Core服务是我仅次于遇到勒索软件攻击的第二大恐惧”。从2017年3月的公测到2023年8月的正式退役，IoT Core的生命周期仅有五年多。
但IoT Core的停服并不意味着谷歌云上MQTT故事的终结。恰恰相反，它开启了一个更加开放、多元、由生态伙伴共同构建的新篇章。如果说IoT Core时代是谷歌云提供的一个“标准化套餐”，那么后IoT Core时代则是一张“开放菜单”——开发者可以根据自己的需求，选择不同的MQTT部署方案，自由组合谷歌云上的各类服务。
四、后IoT Core时代：谷歌云MQTT的三条路径
时间来到2026年，一个无法回避的事实是：Google Cloud IoT Core已经停止服务，你无法再基于它构建新的部署。但这并不意味着谷歌云上的MQTT生态是一片空白。目前，在谷歌云上部署MQTT物联网通信主要有三条路径，每条路径都有其适用的场景与权衡。
4.1 路径一：自建MQTT代理——掌控与责任并存
一个直接的解决方案是在Compute Engine或GKE（Google Kubernetes Engine）上运行独立的MQTT代理。MQTT是已连接设备应用的OASIS标准协议，它使用发布和订阅代理架构提供双向消息传递。MQTT协议本身是轻量级的，可减少网络开销，且MQTT客户端非常小，能最大限度地减少对受限设备资源的占用。
在这种架构中，MQTT代理通常部署为多个实例组成的集群，连接到Cloud Load Balancing服务以实现流量分发和负载均衡。代理集群内部包含设备凭据存储区以及设备身份验证和授权服务，并通过Dataflow或Pub/Sub与后端工作负载连接。边缘设备通过基于TLS的MQTT与代理集群进行双向通信。
自建代理的优势在于灵活性和掌控力——你可以选择任何MQTT代理软件（如开源的Eclipse Mosquitto、VerneMQ，或商业级的HiveMQ、EMQX等），可以精细调整每一个配置参数，不受任何平台限制。但代价也同样明显：你需要自行管理设备身份认证体系、处理集群的扩缩容、应对网络分区等分布式系统问题。简言之，IoT平台作为系统的一部分提供设备身份和设备管理功能，而自建MQTT代理则要求你自行提供这些功能。
4.2 路径二：第三方托管MQTT平台——专业的事交给专业的人
对于不希望自己运维MQTT代理集群的团队而言，第三方托管的MQTT平台是一个极具吸引力的选择。以EMQX为例，它被许多业内人士视为Google Cloud IoT Core的理想继任者。EMQX提供完整的MQTT 5.0支持、原生JWT认证（便于从IoT Core迁移）、强大的数据处理规则引擎，且无供应商锁定，同时能与谷歌云的Pub/Sub、BigQuery等服务无缝集成。
EMQX Cloud支持部署在GCP的多个区域，其新增的GCP Pub/Sub数据桥接功能可以帮助用户轻松连接之前在GCP其他数据服务中创建的物联网应用，快速完成迁移且不影响现有业务。HiveMQ同样提供了针对Google Pub/Sub的企业级扩展，能够将MQTT消息 seamlessly 集成到Pub/Sub的消息流中。
第三方平台的核心价值在于“托管”——你不需要关心代理的部署、运维、扩缩容，只需要关注业务逻辑。这对于资源有限的中小团队或希望快速上线的项目来说，具有极高的性价比。
4.3 路径三：MQTT与云服务的原生集成——松耦合的智慧
除了自建代理和第三方平台之外，还有一种更为“谷歌云原生”的思路——通过轻量级的连接器将MQTT消息直接路由到谷歌云的核心消息服务Pub/Sub中。Google Cloud Platform官方提供的MQTT <-> Cloud Pub/Sub Connector正是一个这样的“薄层”——它让MQTT客户端发布的消息最终落入Cloud Pub/Sub主题，反之亦然。
这种方案的本质是将MQTT代理的职责最小化：它只负责协议的接入和消息的转发，而将消息的持久化、路由、分发等核心能力全部交给Pub/Sub来处理。Pub/Sub作为谷歌云高吞吐、持久化的首要消息层，支持主题与订阅、推送/拉取交付以及至少一次交付语义。设备数据通过MQTT进入系统后，可以触发Cloud Functions、经过Dataflow进行流式处理、最终存入BigQuery用于分析。
这种松耦合架构的优势在于：你既保留了MQTT在设备侧的轻量级通信优势，又充分享受了谷歌云原生服务在大规模数据处理方面的能力。不过需要注意的是，这种方案中的MQTT端点通常不会实现完整的MQTT协议规范——它更像是一个“协议转换器”而非全功能的Broker。对于需要使用QoS 1和QoS 2、共享订阅等高级MQTT功能的场景来说，这可能是一个需要认真权衡的限制。
五、如何选择？——从场景出发的决策框架
面对上述三条路径，没有绝对的“最佳方案”，只有“最合适的方案”。以下从几个关键维度提供一个决策参考框架：
设备规模与增长率。如果设备数量在数百到数千台级别且增长缓慢，自建单节点代理可能是成本最低的选择。如果设备规模达到数万甚至百万级别，第三方托管平台或自建集群方案更具可扩展性。EMQX单集群可支持1亿+MQTT并发连接，这对于绝大多数物联网项目来说绰绰有余。
协议兼容性需求。原生IoT Core的MQTT实现并非100%符合MQTT v3.1.1规范——它缺乏对QoS 2、保留消息等基础功能的支持。如果你的设备或应用依赖这些高级特性，那么选择支持完整MQTT 5.0的第三方平台（如EMQX）或自建代理会是更合适的选择。如果设备仅使用基础的MQTT发布/订阅功能（QoS 0或QoS 1），那么通过连接器接入Pub/Sub的方案足以满足需求。
运维能力与团队资源。自建代理意味着你需要一支具备分布式系统运维经验的团队来保障服务的稳定性。第三方托管平台则将运维负担转移给了服务提供商——你只需要关注业务本身。对于大多数不具备专职运维团队的中小型企业来说，后者的综合成本往往更低。
与谷歌云生态的集成深度。如果你已经在使用谷歌云的Pub/Sub、Dataflow、BigQuery等数据分析服务，那么选择能够原生对接这些服务的方案（无论是路径二还是路径三）都可以显著降低集成的复杂度。设备数据从MQTT进入系统后，可以直接流入现有的数据处理管道，无需额外的转换和适配层。
供应商锁定风险。自建代理和通过连接器接入Pub/Sub的方案在供应商锁定方面风险最低——你可以随时将代理迁移到其他云平台或本地环境。第三方托管平台虽然提供了便利，但也意味着你对平台的依赖。EMQX等平台强调“无供应商锁定”，但在实际迁移时仍需评估数据导出和业务切换的成本。
在谷歌云上部署MQTT方案，上海汪远信息科技作为深耕多云服务领域多年的综合型服务商，业务覆盖谷歌云等八大主流公有云平台，可为物联网企业提供从架构设计到部署运维的全链路技术支持。公司现有全职员工500人，团队架构完善，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户。作为谷歌云头部一级代理商，上海汪远信息科技可提供谷歌云8.5折或返点15%的商务政策。公司在香港设有分支机构，专门服务于谷歌云、亚马逊云、微软云等国际站业务。10年以上的行业深耕经验，使其能够为物联网MQTT项目的云基础设施选型与成本优化提供专业保障。
六、结语：进化的终点是生态
从1999年IBM工程师为监测石油管道而创造的轻量级协议，到2017年谷歌云将其纳入全托管服务平台，再到2023年原生服务的落幕与2026年多元生态的兴起——MQTT与谷歌云的故事，本质上是一个关于“进化”的故事。
IoT Core的关闭让一些人感到失望，但它也迫使整个社区重新思考一个问题：我们究竟需要怎样的物联网云服务？是“一个平台包办一切”的封闭式方案，还是“可插拔、可组合”的开放式生态？后IoT Core时代的谷歌云MQTT生态给出了明确的答案——后者。
无论是选择在Compute Engine上自建代理，在GKE上部署高可用集群，借助EMQX等第三方平台快速上线，还是通过轻量级连接器将MQTT消息注入Pub/Sub——今天的开发者拥有了比IoT Core时代更多的选择权和灵活性。这种“选择的多寡”本身就是一种进步。MQTT作为物联网的“通用语言”不会消失，谷歌云作为承载物联网工作负载的重要平台也不会缺席。变化的只是连接二者的方式——从“唯一路径”变成了“多条路径”，而这恰恰是技术生态走向成熟的重要标志。
常见问题解答
问1：Google Cloud IoT Core停止服务后，还能在谷歌云上使用MQTT吗？
答：可以。IoT Core已于2023年8月停服，但开发者仍可通过自建MQTT代理（在Compute Engine或GKE上）、使用第三方托管MQTT平台（如EMQX、HiveMQ），或通过官方MQTT-Pub/Sub连接器将MQTT消息接入谷歌云生态。
问2：谷歌云原生IoT Core的MQTT实现与标准MQTT有什么区别？
答：IoT Core的MQTT实现并非100%符合MQTT v3.1.1规范，它不支持QoS 2、保留消息（Retained Messages）和 guaranteed 消息顺序等基础MQTT功能。设备也被限制在预定义的主题模式下发布消息。
问3：后IoT Core时代，在谷歌云上部署MQTT有哪几种主流方案？
答：主要有三种路径：一是在Compute Engine或GKE上自建独立的MQTT代理集群；二是使用EMQX、HiveMQ等第三方托管MQTT平台；三是通过轻量级连接器将MQTT消息直接路由到Cloud Pub/Sub。
问4：选择MQTT方案时应该考虑哪些关键因素？
答：主要考虑设备规模与增长率、协议兼容性需求（是否需要MQTT 5.0或QoS 2）、团队运维能力、与谷歌云现有服务的集成深度，以及对供应商锁定的容忍度。
问5：EMQX等第三方平台相比自建代理有什么优势？
答：第三方托管平台提供完整的MQTT 5.0支持、内置的JWT认证、强大的规则引擎，且无需自行运维代理集群。对于资源有限或希望快速上线的团队来说，综合成本往往更低。
问6：如果设备数量不多，最简单的MQTT接入方案是什么？
答：如果设备数量在数百台以内且仅使用基础MQTT功能，可以在Compute Engine上部署一个单节点的开源MQTT代理（如Mosquitto），配合Cloud Load Balancing实现基本的可用性保障。
