经过三个项目的使用，对阿里物联网平台的机制也消化的差不多了，从刚开始的文档难懂，到现在的理解规则，并懂得在规则限制内使用。
一直用这套，在自搭前期也不免掉进了这个思维陷阱，幸好有后台工程师没有消化这套，碰撞的时候发现有很多不便之处，当企业有能力自己做的时候，还是发现有很多可以优化的地方，这些优化不是证明阿里这套不好，而是定位不一样，阿里着重考虑的是平台通用性，这会带来流量的浪费，与嵌入式资源的占用浪费。
特别是在协议上，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或架构能力都需要验证，而企业可能承担不了这种风险，谁也不想承担这种风险。
