关于IOT（物联网）现在被宣传得非常的热闹了，但是它是不是真值得这么大力的宣传呢？从它的核心来看，IOT仍然是互联网，只是接入了很多物品。只是这些物品和我们过去用去接入互联网的计算机有很大的不同。简单的说，IOT和互联网是一样的但又有所差别。
过时的新闻?1982年，卡耐基梅隆大学的几个学生 Mike Kazar, David Nichols, John Zsarnay 和 Ivor Durham就把一台苏打水售卖机接入了互联网，也就是后来我们所知的阿帕奇网络，他们可以远程的通过命令行终端查看到是否还有苏打水在卖，以及苏打水罐子是不是已经凉了。这可能是第一个“接入互联网的物品”，从那之后，成千上万的设备被开发出来并静静的接入到了网络中。
因此，为何“物联网”在今天得到这么大的关注，考虑到它其实没有取得任何重大的技术突破?事实上，IOT的出现和当今世界最主要的几项技术趋势都有关联：
1. 摩尔定律##最重要的趋势就是继承了摩尔定律，各种硬件和生产工艺的创新使得硬件更便宜，功耗更低，性能更加强劲。
2. 操作系统##更廉价快速的硬件还不是唯一的推动力。更廉价的开源软件比如linux和RTOS都使得硬件更轻易的增加网络功能（通过wifi或者是其它通信方式), 以及对应所需要的网络协议栈。
3. 互联网##当然，互联网本身也是因素之一。还必须感谢通信技术的全球标准化--物理层，连接层，网络层，传输层以及更高层--一旦连接成功设备就一定能和通过网络和其它设备通信。
很简单?####技术方面就这样了?加上linux，wifi和以太网口，我就有了物联网设备了。呃，是，可也不是。
标准的架构还在酝酿中设备间的通信协议####多数我们特别喜欢用的应用层协议--比如http--是为机器，人或者不受限制的服务器间的通信设计以及优化的。尽管物联网里有一点点人和机器的通信，但在物联网里，设备联网最大的价值产生于机器或者传感器与服务器或者是服务本身的通信。举个例子，如下图所示的一个仓储系统。温湿度传感器会把信息发送给加热器或者空调系统去调节整个屋子的温湿度。当进货的时候，仓储机器人确保需要冷冻的物品被送到专用的位置，而空气调节装置也可以做出相应的调节。整个过程完全不需要人参与。
不同的设计目的###而在物联网里，在硬件的尺寸大小，电池续航，如何部署，形态和功能都非常多，这就使得IOT系统平台需要考虑的细节非常琐碎。以很多系统都有的温度传感器为例。传感器需要在一颗纽扣电池上运行5年之久。永久的连着wifi并且能时刻响应httpGET会在几分钟内就用光电池。那么能否休眠几分钟再唤醒并通过POST的方式把信息推送给需要的设备上呢？即使是最高效的wifi设备也需要至少60ms去连接到wifi上。在世界上很多的设备，时间就是金钱。发送一个HTTP request事实上是会产生很多底层的通信行为，比如建立TCP连接然后才能发送数据包，这就使得wifi和wifi post不能很好的满足需求。而我们挚爱的RESTful接口也很难解决这个问题。
发明更新的协议和标准###解决方案是开始去搜索工作在在包交换一层的底层协议，因为有更精简，发送功率的通信方式。一些组织正在致力于制定一些标准不仅仅是为了处理如何让数据从产生这边发送到需要数据的那边，可能如何发现和提供设备，以及更为重要的是，如何交互。在互联网的人机交互里，所有的网页浏览器都能访问网页，只要服务器端支持HTTP并返回HTML。我们需要相同的设备。某个生产厂商的设备需要能支持发送温度到另一个厂商的温控系统上。
如何互通（译者：原文是一大碗字母汤，意思是各家都发明了很多轮子导致）###尽管各家厂商已经在互通性上做了很多的工作，但是，目前看来各自私有的标准还是太多，不同的厂家都有自己的出发点。在消费电子领域，Allseen联盟（由像高通，微软，LG，SONY驱动建立起来的）一直在推动这件事情。Google的Trend和苹果智能家居也在做着同样的事情。ECLIPSE也为了IOT的标准，一直在做开源的工作。
Mesh 网络###很多的接入设备因为一些合理的理由没有使用以太网或是wifi作为底层物理层通信，都使得当前的状态有些复杂。以上面提及的温度传感器为例。wifi是一个不太合适的选择，因为它并不是一个低功耗的传输方式。wifi通常是部署在星状和中心级联形状的网络，这些网络里都有一个中心节点，所有的设备都可以通过广播频段连接到这个节点上。必须使用规定的频段才能连到接入节点，这就意味着接入和广播设备都必须相对的高功耗。同时，功耗还不仅仅是唯一的劣势。一个稳定工作了数月的wifi连接有可能突然变得不稳定了，有可能仅仅是隔壁的开始使用一个老的微波炉（真事。译者注：呃，确实）。如果你的手机连接不稳定，移动6英寸就有可能可以突然的改善它。而这对于一个固定设备就显得有些奢侈。
物联网还处于一个混沌的状态，最好的方式就是不要被宣传蒙蔽了###常用的解决方案就是去部署“MESH”网络，所有接入设备都可以和它的相邻节点通信，消息是通过跳转（译者：路由技术）从一个节点到另一个。这就允许一个节点出错或是连接不上时，有别的路径可以使用。这种拓扑可以极大的减少单个设备的功耗。典型的例子就是一个或者多个“网关”设备接入到网络中。通过这个思路实现的标准包括Zigbee和Zwave。目前已经完成的协议是蓝牙mesh（译者注：目前商用的还不多）和6LowPan。谷歌也正在推动出品一系列协议，被称为Thread，目标是应用到智能家居和6LowPan以及其它已存协议。
消息通信###目前多数的联网设备都会需要云端通信，或者允许智能手机从远端去控制。有时通过一个本地的忘关，有时是从设备直连。很多系统已经发行HTTP事实上是一个很差的机制，可能“推送”机制会更合适一些。备选方案是去使用包括MQTT。CoAP（底层使用UDP）也正在引起注意。CoAP集合了一些低开销的RESTful接口的功能以及观察者模式（译者：这点对于开发者很重要）。但是，对于分散式网络，可能最让人感兴趣的已经开始部署的消息机制可能是TeleHash。
故障定位###最后，IOT架构里如何做故障排查是一个很容易被忽略的方面。我们认为能否有很多的工具去调试和定位应用以及接入网络的PC，智能手机，平板电脑和服务器。能被使用的工具的范围和构建IOT网络实现涉及到的厂商数量必须是选型时的一个重要考虑因素。
总结#是否所有的宣传都名副其实？其实并不重要。
正如我之前总结的，这么多物联网技术有相同之处也有不同之处。操作物联网的关键之处是必须要理解你的架构，方案和业务里的相似和不同之处。
这是否意味着任何人都可以执行IOT方案？
选择和备选都不是很清晰。焦点应该是清晰的明白你的目的和你的平台的需求。但是，很多的技术选择都是由你所选择的设备厂商所推动的。当调研多个方案的时候，一个关键的考虑因素是系统架构是不是可以很快的进行问题定位，并且安全，私密和第三方依赖库是如何管理的。我们处在一个令人兴奋的年代。联网设备会变得更智能，更自发的，需要的互通标准和落地细节都即将到来。
/2 
