阿里云物联网平台搭建-企业自搭平台的优劣势

经过三个项目的使用,对阿里物联网平台的机制也消化的差不多了,从刚开始的文档难懂,到现在的理解规则,并懂得在规则限制内使用。

一直用这套,在自搭前期也不免掉进了这个思维陷阱,幸好有后台工程师没有消化这套,碰撞的时候发现有很多不便之处,当企业有能力自己做的时候,还是发现有很多可以优化的地方,这些优化不是证明阿里这套不好,而是定位不一样,阿里着重考虑的是平台通用性,这会带来流量的浪费,与嵌入式资源的占用浪费。

特别是在协议上,TOPIC由于平台框架不够简易,数据交互不够简单,定义的物模型概念是非常好的,但是如果自搭的可以将TOPIC的信息更优化,将属性、事件、服务等内容放到payload里面的字段来区分,服务器topic的解析入口更优化,对于高并发的处理、拓展性更友好。

例:

下发设置一个值到设备

阿里:

1.JSON格式通过app到服务器到嵌入式透传,设置成功后嵌入式同步上报,服务器将最近数据同步保存,app全局订阅同步。这交互太多了,而且数据也不是一般的大,看似可靠,但是交互节点越多就增加了它的意外因素。

2.通过app到服务器JSON格式,服务器转成16进制下发到设备,设备上报16进制,服务器解析转成JSON,存储的同时转发给app。

自搭:

app调用服务器接口,服务器转发下发指令并等待设备返回ack结果,成功或失败,如果成功则将数据存储的同时将app的请求返回,app根据请求结果更新页面数据。

劣势:

在设备量大的时候需要高成本维护平台的稳定性,主要分为几个方面:1,人才少,门槛高,能够搭建这样的成熟的物联网平台的工程师或团队非常少,进本被bat瓜分了,当然onenet和涂鸦也挖了不少。2.服务器成本高,企业在规划时一般想要直接上百万计架构,在设备量少的时候服务器费用一年也得20-30万。3.可靠性、稳定性没有保证,自搭意味着平台没有经过市场验证,很多bug或架构能力都需要验证,而企业可能承担不了这种风险,谁也不想承担这种风险。