阿里云IoT、腾讯云IoT、AWS IoT 对比
阿里云物联网平台、腾讯云 IoT Explorer、AWS IoT Core 怎么选？从设备认证、物模型、设备影子、规则流转、海外节点和迁移成本对比，并给出托管平台与 EMQX、ThingsBoard 自建方案的判断顺序。
本文目录
做平台对比时，很多团队先去看控制台截图、计费页和产品清单，讨论半天，回到项目上还是没法拍板。阿里云IoT、腾讯云IoT、AWS IoT 当然都能接设备、收数据、做规则，但影响交付的，往往是项目准备把哪些能力放在云平台上，哪些能力留给设备、业务系统和 App 自己掌控。
如果当前已经在立项阶段，建议先把设备类型、接入协议、目标市场和上线节奏写清楚，再去比较平台。平台选错，后面最直接的代价未必是“功能少了一点”，更常见的是接口反复调整、联调时间被拉长、运维边界越来越乱。项目还没理完整，也可以先对照 物联网开发服务、MQTT 物联网系统开发服务 和 航标远程监测与运维平台案例 判断更接近哪类交付场景。
先把比较口径定住
第一步不用急着给三家排高低，先确认这次采购或开发，到底在解决哪一段问题。有的项目主要矛盾在设备接入，关心协议接得快不快、量产后运维顺不顺；有的项目看重海外部署和跨区域协作，平台只是整体架构里的一个环节；也有一些团队首期目标很务实，只想尽快把设备、云端和 App 跑通，先验证市场，再决定后面要不要把能力继续往自己手里收。
这一步不说透，后面的比较很容易失真。拿“功能多不多”当核心标准，常见结果是采购、研发、硬件、运营各自有一套判断，最后拼不成一张完整的交付图。更稳妥的做法，是先确认设备侧是自研还是模组方案，App 要不要深度定制，后端是否已有业务系统，后续是否要支持多区域、多型号或多角色运营。口径一旦定住，平台选择就不会飘。
三个平台更适合什么局面
阿里云IoT 更常见于国内业务占比高、设备量产节奏明确、交付团队希望尽快贴近现成云生态的项目。若你的硬件、App、业务系统都在国内推进，平台、短信、存储、监控等配套资源也倾向放在同一侧，项目协同通常会更顺。腾讯云IoT 也经常出现在类似场景里，但不少团队会把它放到已有腾讯云体系、微信生态或现成企业云资源已经在用的项目里评估。这样比，不是因为“绑定某个平台更先进”，更多还是现有资源、账号体系和运维分工本来就在影响实施成本。
AWS IoT 讨论得最多的场景，通常是海外市场、多区域部署，或者团队原本就按 AWS 体系来做基础设施管理。平台本身放进这样的上下文里，比较才有意义。若业务重心主要在国内，却把国际部署能力排在第一位，很多本地交付细节反而会被压后；反过来，如果项目需要兼顾多个国家和更复杂的云架构，把 AWS IoT 纳入主选项就很自然。
真正的判断重点，其实落在“平台适合你的现有组织方式吗”。有些团队设备协议能力强，愿意把平台当基础设施；有些团队更依赖平台侧现成能力，希望首期缩短试错时间。还有一些项目后续准备把设备管理、消息链路、报警流转和业务报表逐步拆细，这类项目就更要提前看清后期迁移和扩展的成本，而不是只看眼前能不能上线。
我们做过的平台选型
我们交付的几个项目，云端都没有直接用公有云 IoT 套件。BMS 平台基于开源 IoT 平台二次开发，部署在客户自己的服务器和域名下；冷链平台用 EMQX 接 4G DTU，后端是 Go 服务。这样数据和设备接入都在客户自己手里，分销商、MES 这类定制流程也更好接。公有云套件更适合设备规模大、定制少的项目，自建方案可以参考海外冷链设备管理平台案例。
托管 IoT 平台在整体架构里负责什么
托管 IoT 平台在整体架构中的位置：设备端、托管平台、云产品、自研业务
无论选哪家，托管 IoT 平台解决的都是**「连接与设备管理」：设备认证、消息通道、物模型、设备影子、规则流转和固件分发。App、Web 后台、组织权限、告警工单、报表这些业务系统仍然要自己开发**。很多团队以为「上了云平台就有现成系统」，立项后才发现工作量主要在业务层。
三家平台的技术概念对照
| 概念 | 阿里云物联网平台 | 腾讯云 IoT Explorer | AWS IoT Core |
|---|---|---|---|
| 设备身份 | 产品 + 设备名 + 设备密钥（一机一密 / 一型一密） | 产品 + 设备名 + 密钥或证书 | X.509 证书为主 |
| 设备数据建模 | 物模型（属性、服务、事件） | 数据模板 / 物模型 | 无强制模型，常配合 Shadow |
| 设备状态镜像 | 设备影子 | 设备影子 | Device Shadow |
| 消息转发到云服务 | 数据流转 / 规则引擎 | 规则引擎 | Rules Engine（SQL 风格） |
| 固件升级 | OTA 升级服务 | 固件升级 | AWS IoT Jobs |
表中为各平台常见的概念对应关系，具体能力、命名和限制以各平台官方文档为准。
从工程角度看，迁移成本主要来自两处：一是设备认证方式（证书体系和密钥签名算法不同），二是设备侧是否深度绑定了某家的物模型 SDK。设备只用标准 MQTT、认证参数可配置的话，换平台基本只是改服务端。
用托管平台还是自建：判断顺序
托管 IoT 平台与自建 Broker 的判断顺序
把上图六个问题按顺序回答，大部分项目能很快定下来。我们的经验是：
- 固件已定型、只会标准 MQTT 或私有协议的设备（例如冷链 DTU、灯具控制器的 TCP 私有协议），自建 Broker + 桥接服务更灵活，不用迁就平台的物模型。
- 客户要求私有化或本地部署的项目，托管平台基本排除，直接用 EMQX、ThingsBoard 等开源方案。我们的储能电站云平台就是在 ThingsBoard 上做二次开发，业务功能放在独立服务里，便于以后升级底座。
- 设备量大、功能标准、团队缺运维的消费类产品，托管平台能省掉 Broker 集群、证书、备份这些长期运维工作。
自建方案的常见组合
| 需求 | 常见选型 |
|---|---|
| MQTT Broker | EMQX（集群、规则、认证插件）、Mosquitto（轻量单机） |
| 开源 IoT 平台底座 | ThingsBoard、ThingsPanel 等，适合二次开发 |
| 时序数据 | TDengine、TimescaleDB、InfluxDB |
| 业务服务 | Go / Java 微服务 + PostgreSQL / MySQL |
| 部署 | Docker Compose（中小规模）、Kubernetes（多实例高可用） |
降低平台锁定的四个做法
- 设备认证参数可配置：域名、端口、用户名、密码 / 证书都能通过配置或 OTA 修改；我们在航标项目里就是让自建服务兼容原平台的接入协议，迁移时设备只改域名。
- 主题和报文用自己的规范：平台物模型只在服务端做映射，设备侧不依赖某家的 SDK 结构。
- 原始数据自己留一份：通过规则流转或订阅，把原始报文和关键数据同步到自有数据库，避免历史数据只存在平台里。
- 业务系统和平台之间加一层适配：业务代码调用自己的设备服务接口，而不是直接调用云厂商 API。
决策前别漏掉交付和维护边界
平台选型一旦进入实施阶段，最容易出问题的不是购买动作本身，问题往往出在边界没有写清。设备鉴权谁负责，消息链路由谁维护，规则处理做到哪一层，App 里哪些功能直接依赖平台能力，哪些必须保留自定义空间，出现异常时是谁来排查，这些问题如果停留在口头沟通里，报价再快、排期再满，后面还是会卡在联调和验收。
平台对比最好和交付方案一起看。若项目已经准备启动，建议先把设备清单、接入协议、目标用户、上线区域和后期运维方式整理出来，再通过 联系我们 获取平台选型建议。想先把周期、预算和私有化边界过一遍，也可以顺手看看 常见问题。平台只是方案中的一层，项目能不能顺利推进，取决于前期边界有没有收稳。
常见问题
阿里云物联网平台和 AWS IoT Core 最大的区别是什么？
设备认证和数据建模思路不同：阿里云常用产品 + 设备名 + 密钥的三元组和物模型，AWS IoT Core 以 X.509 证书和 Device Shadow 为主、不强制物模型。另一个现实差别是海外节点覆盖和国内合规要求。
设备三元组是什么？
指产品标识、设备名称和设备密钥三项参数，设备用它们计算签名来连接平台。一机一密是每台设备一套密钥，一型一密是同一产品共用密钥后再动态注册。
先用云平台，后面能迁移到自建平台吗？
能，但要提前设计：设备认证参数可配置、主题和报文不依赖平台 SDK、原始数据同步到自有数据库。做到这三点，迁移主要是服务端工作。
海外设备用哪家云平台？
看主要销售地区和数据合规要求。全球覆盖需求强的通常考虑 AWS，也可以用自建 Broker 在目标地区分别部署，我们的智能鱼缸平台就是国内云和美国云分开部署。
用了云 IoT 平台还需要开发后台吗？
需要。云平台提供设备连接和管理能力，面向你的客户、经销商和运维人员的业务后台、App、权限和报表仍然要单独开发。
小团队做物联网平台，选托管还是开源？
没有专人运维时优先托管平台；有私有化要求、设备协议特殊或者需要深度定制业务时，选 EMQX、ThingsBoard 这类开源方案更合适。