从一名开发者角度看物联网

从一名开发者角度看物联网

物联网一词由一两年前的炙手可热，到现在的不温不火，其背后原因到底是什么？

个人认为之前人们在想象物联网的宏大，实现一个令人非常向往的未来世界就是用物联网技术的。现在大家开始真正去做了，物联网绝不仅仅是物连上网那么简单（其实并不简单），如果像人们想象的那种物联网，不仅仅包含传感网，也包含数据融合，数据的挖掘，全新的芯片等等不同的各个方面，当然也有终端和用户的交互。一件事情想起来是美好的，做起来就非常困难，这绝对不是之前技术的简单拼凑，也许物联网会用到很多之前的一些相关领域的知识，但也一定会需要大量全新的知识。

技术公司们仍在继续开发和发布各种物联网设备和应用，这些设备和应用能够控制用户家中的照明灯、恒温器、门锁和各种形形色色的家电设备。有些设备和应用甚至可以被捆绑在一起，但是对于普通消费者来说，整个物联网市场仍然太混乱了，而且有一种支离破碎的感觉。尽管苹果、谷歌和其他一些公司推出了一些系统，试图提高该领域的秩序和一致性，但整体表现混乱却是不争的事实。

总之，“物联网仍是一团糟”很好地说明了物联网的现状。

我是一个Android开发者，大学学习物联网专业，所以对其中的一些技术还是有一些浅薄的认识。一个技术只有被大量的开发者使用，开发出各色的产品，才能够走入用户的视野。Android正是这样，因为google给了开发者足够简单的开发环境，所以才会有千奇百怪的Android APP产生。

这里以一个简单的智能家居情景说明，说明物联网需要用到的知识。

1.需要在家中的各种电器上加入传感器，对传感器内部逻辑编程涉及到的是硬件编程，操作系统编程。
2.然后需要对传感器进行组网，ZigBee和Wifi协议各有优缺（或者说都不适合，需要一种新的协议），选择Wifi后TCP是否适用，选择TCP后Http是否适用？
3.不同传感器有不同的数据格式，如何进行数据的融合，存储在服务端又是一个难点，大量非结构化数据的涌入势必需要NoSql的支持
4.获取到数据，能利用这些数据做些什么，就是一些机器学习，数据挖掘的事情了
5.然后将一些用户关心的东西给呈现给用户（不一定是手机）

因为没有一个完善的体系，所以几乎每一步都需要不同专业的人员进行开发，造成开发成本高昂。无法将一个idea迅速产品化，这也是物联网时代创业举步维艰的原因。其实刚刚提到的只是一些最最基本的问题，比如对新型电源的需求，比如对新型芯片的需求非常非常多，但这些问题其实都并不影响一个开发体系的形成。因为一个好的体系应该是各层相互抽象的。比如ISO 七层模型，TCP即可以在802.3上工作也可以在802.11上工作。

作为一名开发者，我们需要关心什么？
我们需要关心调用哪个方法就可以实现哪个功能（也就是API）,至于底层是如何适配多种情况的，我们并不关心。就像我们开发Android应用，并不需要关心CPU是（X86还是ARM）的（SO文件除外，因为So文件是C编译的，具有平台依赖性），Android是基于jvm虚拟机的，虚拟机帮助我们将相同的代码适配为不同的指令。

作为一名应用的开发者，我相信我不需要知道，传感器是使用哪种操作系统或他们之间的通信采用的哪一种协议，而是去调用一个加入网络的方法，一个节点就会加入到一个传感器网络中，调用一个发送消息的方法，就可以进行节点间的数据传输。
同样，我们不需要知道机器学习训练参数的过程，我们只需要调用一个方法去调用某个模型训练数据，就可以预测一些值。（当然这样对于调参还是要掌握原理的，但我说明的是需要不过于纠结里面细节）

这里，我说一些题外话，所有数据的处理都放到云端是对云作用的一种夸大而且是对网络真正全覆盖的假想，数据模型的训练放在云上是毋庸置疑的，但是已经训练好的模型，一些对实时性要求高的场景（比如车载，一个信号不好可能就是一场车祸）还是应该放在本地，那么问题来了，机器学习（特别深度学习）一般运算非常大而且与众不同，传感器上的cpu很可能就运算过慢，这个时候就非常需要一种专门用于机器学习的芯片（类似GPU专门用于图像处理）。很多公司都开始致力于这个方向的开发，我之前实习的公司地平线机器人就是在做这件事情。
但无论是CPU，GPU还是新一代芯片都毫不影响一个开发体系的形成，因为这些都是抽象的。

可能有人认为我说的体系其实就是一个框架，进行一些封装而已，但绝对不是这样的，这个体系，首先需要的是一份标准，将各个层次进行连接的标准，如果标准不同，各个层次间便很难实现通信。这也是这个体系迟迟不能出现的原因。

个人认为，这个体系的难点还是在无线传感网这一部分，协议不明确是最大的问题，传统的通信协议不再适应于物联网的场景。大家都知道不能使用传统协议，但是提出新的协议的方向甚至层次都有非常大的差异。

这个协议并不一定是一个协议，可能是一组协议，传感器之间可能需要一种协议，传感器和云端的通信可能又需要一种协议。（协议层次不同）。

比如从应用层提出的MQTT协议，它也是基于TCP/IP的，个人认为一个较大的汇聚节点（需要直接和云连接的节点）是该协议的适用点，而普通传感节点并不适合适用这种底层是TCP的协议。

下面简单介绍下MQTT协议的特点：
由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

精简，不添加可有可无的功能。
发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
允许用户动态创建主题，零运维成本。
把传输量降到最低以提高传输效率。
把低带宽、高延迟、不稳定的网络等因素考虑在内。
支持连续的会话控制。
理解客户端计算能力可能很低。
提供服务质量管理。
假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

而传感器之间的通信协议，比如现在热议的Wifi和ZigBee之争。如果选择Wifi,TCP是否继续适合？在我看来，TCP有3个缺点不适合于传感网通信。
1.报文头过长
2.可靠性和流控依赖发送方
3.完全可靠
第一点很明显，一般传感器的数据只有几个字节，所以TCP20个字节头实在有些喧宾夺主了。第二点，传感网中传感器节点向汇聚节点发送数据（上行数据）的频率明显大于汇聚节点向传感器节点发送数据的频率（下行数据），而传感器节点一般资源非常受限，所以这种依赖发送方进行可靠性和流控的机制也非常不合适。第三点，有人说，完全可靠难道不好吗？可靠是要付出代价的，因为我们的上行数据一般是有冗余的，所以并不需要这样完全可靠。

相比而言服务端方面，近些年涌现出的大量云服务大大简化了我们对服务端的维护，同时也降低了成本。比如IBM提供的Bluemix在灵活性和简洁性上都是非常不错的选择。

总之，物联网要像移动互联网这么火爆，必须有大量的产品形成，现在看来还有很长的一段路要走，协议的制定，标准的统一，体系平台的形成，每一步的踏出都非常艰难，但其市场价值和给人们带来的生活体验也同样是无穷的。