从零开始搭建物联网系统

　　背景

　　时间：1年前的某日

　　坐标：深圳

　　在一个平常的不能再平常的周末下午，几个小伙伴聚在了一起，一起畅想"万物互联"的物联网未来。小伙伴中有硬件开发者、嵌入式开发者、软件开发者；有互联网公司的全栈工程师、也有核电厂的工控系统维护者、还有路由器厂商的wifi协议开发者。我们发现，世面上没有开源且可商用的物联网平台或系统。这里的可商用，不是搭建几个demo把硬件连上网、app操作两下这么简单！

　　有以下几点都是必须着重考虑的：

　　必须有完备的硬件、嵌入式、云端一体的协议及架构设计

　　能够实现真正的硬件智能化，能够基于数据学习并自主工作

　　必须有很高的性能、稳定性及扩展性

　　必须能够适应成千上万种不同资源的硬件设备，从PC到手机、从计算资源极其有限的单片机到网络带宽极其有限的控制器

　　必须能适应不同的网络场景，包括有线、wifi、3g/4g、gprs等

　　必须有很可靠的安全性

　　需要尽可能降低研发和生产成本

　　在媒体和科技工作者都抱着物联网是未来的观点并翘首观望时，我们决定做点什么，而不是当看客！这个平常的不能再平常的周末下午，也许对我们不太平凡。

　　我们决定启动全套可商用物联网系统的设计和研发，并在不久的将来，全部开源。

　　于是大家利用业余时间，开始了协议设计及系统设计，将项目慢慢启动了起来。几个月后，第一个商用版本的研发成功完成。这期间，好几个小伙伴辞去了工作，全职进行研发。我们在没有融资、没有资源的情况下一路走到现在，其中辛酸就不多言了。谨以此文记录我们在系统设计和研发中的走过的路，以飨同样是物联网爱好者的你。

　　整体设计

　　一个物联网系统涉及硬件、软件、云端、app各个环节，必须从整体进行顶层设计，只倚重某个单一的环节进行设计的系统都不具备良好的适用性和扩展性。我们在设计时为了避免这种情况，使系统能够适应最广泛的物联网场景（甚至包括工业场景），每次的架构设计讨论都是所有团队成员参与。大体的系统架构如下：

　　协议

　　在一个物联网系统中，协议是串通上下层的关键纽带。在物联网系统中，我们将协议分为两大层：通信层和业务层。

　　通信层基本上是传统互联网的网络基础设施，负责将数据在物联网系统节点中的传输

　　业务层分为两层，底层是负责物联网场景下数据交换格式的规范，上层是物联网场景需要具体传输的业务数据规范。

　　通信层互联网基础架构目前已经非常成熟且通用，但是业务层协议目前还是种类繁多。可以确定的一点是，最终能在物联网应用中称霸的协议，一定也像互联网时代的TCP/IP一样是开放的、免费的。目前符合此特性并使用比较多的有XMPP、MQTT、COAP等。关于具体的对比，可以参考我之前的另一篇文章《物联网通信协议介绍》。

　　文中总结如下：

　　互联网中使用较多的HTTP、websocket以及XMPP等协议，在设计时都是根据互联网应用场景设计的，虽然很多厂商把他们应用在物联网系统中，但是必然会水土不服，这些协议的通病就是根本无法适用物联网设备的多样性，无法适用很多物联网设备对低功耗、低成本的需求，难以在极低资源的物联网设备中运用。

　　COAP协议针对资源受限的嵌入式设备设计，但由于很多物联网设备隐藏在局域网内部，COAP设备作为服务器无法被外部设备寻址，在ipv6没有普及之前，coap只能适用于局域网内部（如wifi）通信，这也很大限制了它的适用范围。

　　MQTT在协议设计时就考虑到不同设备的计算性能的差异，所以所有的协议都是采用二进制格式编解码，并且编解码格式都非常易于开发和实现。最小的数据包只有2个字节，对于低功耗低速网络也有很好的适应性。有非常完善的QOS机制，根据业务场景可以选择最多一次、至少一次、刚好一次三种消息送达模式。运行在TCP协议之上，同时支持TLS（TCP+SSL）协议，并且由于所有数据通信都经过云端，安全性得到了较好地保障。

　　我们最终选择基于MQTT来作为业务传输层主要协议。但是MQTT协议本身的设计是针对开放设备，对于可商用的物联网系统不得不保证设备的安全性和完善的授权机制。所以我们在实现MQTT协议时进行了一些定制和限制。

在业务层的上层（business层），目前的物联网系统都是各自针对自己的业务场景设计协议规范。有没有可能根据物联网场景统一业务数据的规范呢？我们认为是可行的，并且也是必要的。如果把通信协议比作声音，光有通信协议，任何人之间还是无法交流。只有统一语言，大家才能顺畅沟通。所以我们抽象出物联网节点中传感器和执行器的业务场景，并设计出含有物