谷歌云MQTT深度解析：从原生服务到生态重构的物联网通信进化论
一、MQTT协议：从石油管道到物联网通用语言
1999年，IBM的两位工程师Andy Stanford-Clark和Arlen Nipper面对一个棘手的现实问题——如何高效监测偏远地区石油管道的运行状态。彼时的卫星连接成本高昂且极不稳定，他们需要一种能在恶劣网络条件下可靠工作的轻量级通信方案。这个看似"小众"的需求，最终催生了一个影响深远的协议——MQTT（消息队列遥测传输）。
二十多年后的今天，MQTT早已不再是工业管道的专属"监测员"。从智能家居的温度传感器到工业自动化生产线上的执行器，从联网汽车的远程诊断到医疗设备的实时监护，MQTT每天处理着数十亿条消息，已然成为物联网世界事实上的"通用语言"。MQTT协议采用发布/订阅代理架构提供双向消息传递。它之所以能够在资源受限的设备上广泛部署，核心优势在于协议的轻量级设计——大幅减少网络开销，客户端程序极小，能够最大限度地降低受限设备上的资源消耗。
二、原生时代：Google Cloud IoT Core的架构遗产
2017年，Google Cloud IoT Core正式发布，承诺以全托管的方式连接和管理全球数以百万计的物联网设备。设备通过标准的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服务。2023年8月16日，这个承载着无数开发者期望的托管服务正式画上了句号。对于许多正在或计划使用谷歌云构建物联网项目的团队而言，这无疑是一个需要重新审视技术路线的时刻。
IoT Core的停服并不意味着谷歌云上MQTT故事的终结。恰恰相反，它开启了一个更加开放、多元、由生态伙伴共同构建的新篇章。2026年的现实是：Google Cloud IoT Core已经停止服务，你无法再基于它构建新的部署。但这并不意味着谷歌云上的MQTT生态是一片空白。当前的实践建议很简单：将IoT Core视为参考架构，而非产品选择。如果你的任务是迁移遗留系统或重写旧指南，核心工作是保留架构的优秀特性，同时替换为不同的连接层（通常是符合标准的MQTT代理）以及你自己拥有或从合作伙伴处获取的设备注册表和配置通道。
四、2026年的谷歌云MQTT：主流替代方案与架构路径
既然原生IoT Core已成往事，那么在谷歌云上部署MQTT物联网应用，2026年有哪些切实可行的路径？
4.1 路径一：在Compute Engine或GKE上运行独立MQTT代理
对于希望在谷歌云上支持已连接设备应用的组织，一个直接的解决方案是在Compute Engine或GKE上运行独立的MQTT代理。谷歌云官方架构中心提供了完整的参考架构。在这一方案中，MQTT代理部署为包含三个实例的集群，这些实例连接到Cloud Load Balancing服务。代理集群包含设备凭据存储区以及设备身份验证和授权服务。集群通过Dataflow或Pub/Sub与后端工作负载连接。
在客户端，边缘网关通过基于TLS的MQTT在边缘设备和MQTT代理集群之间提供双向通信。谷歌云官方建议在集群中部署MQTT代理应用以实现可扩缩性。聚簇功能、扩容和缩容集群管理、数据同步以及网络分区处理等因素由特定的代理实现来解决。对于负载均衡器的选择，如果应用使用mTLS进行设备身份验证，建议使用外部直通式网络负载均衡器或具有目标TCP代理的外部代理网络负载均衡器。如果应用不使用mTLS，则建议使用具有目标SSL代理的外部代理网络负载均衡器。
4.2 路径二：采用EMQX等第三方托管MQTT平台
EMQX作为一个开源、分布式、可扩展的MQTT代理，已成为前谷歌云用户推荐的替代方案。EMQX提供了从Google Cloud IoT Core迁移设备的脚本和工具。它的优势在于提供了完整的MQTT 5.0支持、高并发性能、集群能力、共享订阅以及可扩展的认证和授权机制。EMQX支持每集群1亿个并发物联网设备连接，同时保持极高的吞吐量和亚毫秒级延迟。
EMQX还实现了一个兼容层，显著简化了从IoT Core的迁移过程。该兼容层提供的关键功能包括：从Google Cloud IoT Core导入设备配置和认证数据，以及支持与IoT Core兼容的MQTT认证机制。
4.3 路径三：HiveMQ与Google Pub/Sub的深度集成
HiveMQ提供了企业级MQTT平台，能够将MQTT数据无缝集成到谷歌云中。HiveMQ Enterprise Extension for Google Cloud Pub/Sub可以用HiveMQ的MQTT代理替代IoT Core的MQTT数据接入服务，然后将MQTT消息映射到Google Pub/Sub。
该扩展提供的能力包括：使用谷歌云服务账号或WIF令牌进行数据认证、在HiveMQ代理和Google Pub/Sub之间进行MQTT到Pub/Sub主题映射的消息传输、按消息粒度在HiveMQ代理和Google Pub/Sub之间聚合和分发消息。此外，它还支持将MQTT用户属性转换为Pub/Sub属性，以及自动将QoS和保留消息等MQTT特定标志添加到从谷歌云接入的Pub/Sub消息中。
4.4 IoT平台产品 vs 独立MQTT代理：如何选择？
谷歌云官方架构中心对两种架构路径做了清晰的区分。IoT平台产品通常提供基本的MQTT和HTTPS数据连接功能，同时允许你预配设备，并提供身份验证和管理、遥测存储和可视化、数据处理和提醒。当独立的MQTT代理不足以满足使用场景的需求，需要更完整的IoT平台产品时，组织通常会使用IoT平台。
两种架构之间的主要安全差异在于设备身份和设备管理。IoT平台作为其系统的一部分提供这些功能，而MQTT代理则要求你自行提供这些功能。如果你需要完整的设备生命周期管理、数字孪生功能、低代码开发界面和内置的分析能力，IoT平台产品是更合适的选择。如果你只需要一个高性能、灵活的消息传输层，且愿意自行构建设备管理能力，独立MQTT代理则更具成本效益和灵活性。
五、迁移实践：从IoT Core到现代MQTT架构
对于仍有设备运行在原有IoT Core体系中的团队，迁移工作可以从以下几个关键步骤入手。
第一步：导出设备注册表。 从Google Cloud IoT Core导出设备注册信息，包括设备ID、公钥、配置数据等。这是迁移的基础数据。
第二步：部署MQTT代理。 根据选型结果，在谷歌云上部署独立的MQTT代理（如EMQX、HiveMQ或自建Mosquitto集群）。
第三步：构建认证桥接。 建立与IoT Core兼容或可替换的认证机制。如果选择EMQX，可以利用其提供的兼容层直接导入认证数据。如果选择自建方案，则需要实现JWT认证逻辑或采用其他认证方式。
第四步：调整设备端代码。 将设备的MQTT连接端点从 mqtt.googleapis.com:8883 切换为新部署的代理地址，并验证主题映射是否正确。
第五步：验证数据链路。 确保遥测数据能够正常流入Pub/Sub，配置更新能够从云端下发到设备。
上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。公司现有全职员工500人，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。在谷歌云领域，上饶市万云信息科技是头部一级代理商，通过谷歌云找上饶市万云信息可以享受8折优惠或返点20%。
六、总结：架构选型的核心逻辑
回望谷歌云MQTT的完整演进历程，从IoT Core的全托管服务到停服后的生态重构，有一条清晰的脉络贯穿始终——云厂商提供的原生托管服务固然便利，但架构的开放性与可移植性同样不可忽视。
对于2026年的物联网架构师而言，在谷歌云上部署MQTT通信层时，需要回答三个核心问题：你的设备规模有多大？你需要多完整的设备管理能力？你的团队愿意投入多少运维成本？如果设备规模较小、团队希望快速上线，第三方托管MQTT平台（如EMQX Cloud或HiveMQ Cloud）是高效的选择。如果设备规模庞大、对数据主权和定制化有较高要求，在GKE上自建MQTT代理集群则提供了最大的控制力。如果你需要完整的设备生命周期管理、数字孪生和低代码开发能力，IoT平台产品（而非单纯的MQTT代理）才是正确答案。
没有放之四海而皆准的"最佳"架构，只有最适合你业务场景的"最优"选择。谷歌云MQTT的故事还在继续——只是舞台上的主角，从单一的原生服务，变成了多元共生的生态体系。
常见问题解答
问：Google Cloud IoT Core还能用吗？
答：不能。Google Cloud IoT Core已于2023年8月16日正式停止服务，无法再基于它构建新的部署。
问：在谷歌云上使用MQTT，现在有哪些替代方案？
答：主要有三条路径：在Compute Engine或GKE上自建独立MQTT代理；采用EMQX等第三方托管MQTT平台；使用HiveMQ与Google Pub/Sub深度集成的方案。
问：IoT Core的JWT认证机制还能沿用吗？
答：认证机制的设计思想可以沿用，但需要在新部署的MQTT代理中自行实现JWT验证逻辑。部分第三方平台（如EMQX）提供了与IoT Core兼容的认证层。
问：独立MQTT代理和IoT平台产品有什么区别？
答：独立MQTT代理只负责消息传输，设备管理和身份认证需要自行构建。IoT平台产品则内置了设备注册、身份验证、配置管理、遥测存储等完整能力。
问：从IoT Core迁移到新架构，设备端代码改动大吗？
答：取决于选择的替代方案。EMQX提供了兼容层，可以最小化设备端代码改动。如果选择自建代理，则需要修改连接端点和认证逻辑。
问：谷歌云上MQTT代理的负载均衡如何配置？
答：谷歌云官方建议使用外部代理网络负载均衡器。如果使用mTLS认证，推荐外部直通式网络负载均衡器；如果不使用mTLS，推荐具有目标SSL代理的外部代理网络负载均衡器。
