本文和大家分享的主要是物联网开发中必须关注的一些技术，一起来看看吧，希望对大家有所帮助。
不管是从商业模式导出的业务模型，还是从技术发展的角度看，文本都倾向于将物联网技术构架看作是互联网技术构架的延展。而与这个观念对立的，是传统嵌入式软件开发的视角。
在互联网技术基础上长出来的物联网构架
简单来说，目前的互联网技术构架主流是大前端与后端两个世界：大前端包括 Web 的 JavaScript 技术、Android 和 iOS 技术，着眼于解决用户交互；后端包括数据库、服务构架、运维等，着眼于解决存储、业务逻辑、安全与效率等。当然，现在前后端技术争相更新，比如业务逻辑前置化、微服务构架、JavaScript 全栈化等新的解决方案也开始模糊前后端的差异。而物联网设备端的引入，着实让这些技术有点难以归类，从业务性质上物联网是另外一种前端或是前端的延伸，比如共享单车应用中，自行车端的应用显然是跟人交互的另一个业务场景，也在为后端源源不断地提供着数据，但是自行车又不像网页或者 App完全是在解决可视化 UI 的事情。而且，现在的设备端开发技术跟前端技术太不像了，由于目前设备端的开发技术都还偏底层，一般来说计算资源如处理能力、本地存储都非常有限，反而像后端一样要考虑资源效率。
那么，我们只好为物联网单独命名一个端，不如我们暂时就叫它设备端。
图 1 整体架构图
新后端
MQTT
新后端核心问题在于加入了面向设备的接入服务，实际上在这里，除类似视频对讲或是安防监控的多媒体实时通道外，这个接入服务已经基本事实化为 MQTT。
消息队列遥感传输协议是在 TCP/IP 协议之上使用的，基于发布/订阅的“轻量级”消息协议，目前为 ISO标准（ISO/IEC PRF 20922）。它被设计用于轻量级和低带宽的远程连接，发布/订阅消息传递模式需要消息代理，消息代理负责根据消息的主题向需要的端发布消息。
如果需要连接的设备没有超过 10 万台，使用 8GB 内存的云主机跑 Mosquitto 就可以；如果设备量是几十万台，可以考虑 Mosquitto 做集群负载均衡；如果设备量是大几十万台乃至百万台以上，那你需要专业的团队或专门的投入来维护这件事情，这个细节就不在本文讨论范围了。
OTA
固件组件在线升级是必须要做的事情，MQTT 传大文件不靠谱，所以一般传过去一个带 Token 的 URL，设备端去下载就好，HTTP 或者 HTTPS 都可以。业务比较简单，设备端几十万以内没有什么特别的地方。
数据存储与服务
Mosquitto 作为 MQTT 的引擎，需要后端按照业务逻辑去调用，这里按照业务需求写好后端逻辑即可。在各种后端语言中调用 Mosquitto 都非常简单。
设备端
设备端是物联网领域最五花八门并且正在发展中的地方。其他领域，后端或者前端，经过十几年的发展，已经出现每个细节的主流技术，基本没有碎片化的情况，但是在设备端，开发技术的碎片化是应用发展还不到位的充分表现。举例讲，选用不同的芯片，就要用不同的操作系统，不同的 C 库封装，各家 IDE 也不尽相同，编译工具链更是从芯片原厂给出。开发起来呢，寄存器、内存分配、硬件中断都要深入进去。这就是传统嵌入式开发的现状，也是物联网设备端开发的现状。
到目前为止，真正生产环境中用到的语言就是 C/C++，极个别会在设备端用到 Python，基本没有其他语言。操作系统超过 50 种，主流的也有 10 种以上，其中嵌入式 Linux 份额并不大，各种实时操作系统各具特色，各有一片天地。
简单总结一下相对于物联网开发，传统嵌入式开发的方式主要有以下几个问题：
1. 需要考虑中断、寄存器、内存分配等过于底层的工作；
2. 编译、烧写、观察、借助调试设备进行调试的开发生命周期；
3. 不同 SoC 和系统的差异过大；
4. 缺乏代码复用与开源的习惯；
5. 开发者在开发环境和固件编译上花费的时间过多。
所以我们看到设备端的开发是基于芯片选型完成的。当设备端产品面临一个需求时，现有的流程是判断产品的各项技术参数，从而确定一个芯片，进而使用这个芯片的一整套开发技术。这也是早期嵌入式场景使用的芯片自生技术特性所决定：计算资源（CPU 主频、存储）、外围接口、使用温度、通讯协议等核心参数的不同导致芯片碎片化，芯片碎片化导致嵌入式开发碎片化。
目前这个领域的大趋势是：物联网芯片有望走向趋同，物联网开发环境与技术有望趋同。
物联网芯片
早期由于成本所限，物联网领域使用的芯片总是表现得非常缺资源，很难找到一个各方面（计算资源、外围接口、使用温度、通讯协议等）都比较合适的芯片去适应普遍的场景。随着半导体门槛逐步降低，中国半导体制造业逐步成型，芯片资源开始走向富余，其中的代表芯片是 MTK 的 MT7697、MT7688 和乐鑫的ESP32。
MT7697 主要参数为：ARM Cortex M4 CPU，带浮点单元，最大主频 192Mhz，内存为 256KB SRAM，可配置 4MB 以上的存储空间，芯片内嵌 WiFi 和 BLE 4.2，有足够的外围接口，并能够适应工业级的使用温度。
MT7688 主要参数为：MIPS 580Mhz CPU，内存最大支持 256MB，可配置 16GB 级别的存储空间，芯片内嵌 WiFi，接口除模拟接口之外数字接口丰富，价格在几十元人民币，功耗较高不适于电池长期使用。但是非常有优势的是其提供的 Linux 开发环境，能够让开发者有一种在普通 x86 机器上使用 linux CLI 的体验，Node.js、MySQL、OpenCV、Nginx 等等在阿里云上怎么用，在这个几十块的物联网小模块上也怎么用。稳定性超强，几年不死机也是正常的。
ESP32 的主要参数为：Tensilica LX6 CP，主频 240 MHz，内存为 520KB SRAM，可配置 4MB 以上的存储空间，芯片内嵌 WiFi 和蓝牙以及 BLE，有足够的外围接口，并能够适应工业级的使用温度。
这几颗芯片共同的特征是计算资源和通讯能力以及接口资源相对于传统 MCU 来说有足够的富余，并保持在同样的价位。因此，在这类芯片上，有足够的资源做抽象化的封装和开发框架实施。我们看到除了这几颗芯片原厂提供的传统嵌入式开发包之外，社区和其他厂商已经在这几颗芯片上加快了新开发技术的实现。
开发技术
物联网设备端开发技术目前有两个比较大的发展方向，一是统一化的物联网操作系统，二是统一化的物联网开发框架。他们共同的目的是形成“软件定义物联网”，与传统从芯片选型开始的，着陆于原厂 SDK 中完成应用开发，与需求和产品设计汇合的流程完全相反，希望从需求和产品设计入手，通过公开统一的软件构架完成开发，再根据开发使用到的资源去落地芯片和外围设备。这样做的好处主要在于提高开发效率和形成可以复用的应用代码。
操作系统
虽然市场上存在的设备端操作系统有数十种之多，但是我们看到活跃的，明显向“软件定义物联网”方向发展的有三家：
· Zephyr
Zephyr 是 Linux 基金会于 2016 年 2 月发布的物联网操作系统，背后主要的支持力量来自于 ARM 和Linaro，具有目前嵌入式小型实时操作系统的普遍特征，比如：轻量到 KB 级的最小系统内存占用，支持多种芯片构架：从 ARM Cortex-M、Intel x86、ARC(DSP 内核)、NIOS II（FPGA 软核）到开源的 RISC V 等，跟 Linux 一样的模块化内核组织方式，如图 2 所示。
Zephyr 目前已经升级到 V1.7 版本，逐步向一个可以用到生产环境的系统靠拢了。Zephyr 最大的特色并不在于其完备性而在于其开发理念完全来自于“软件定义物联网”，并且有很好的资源支持，在未来应该会有自己的位置。
Zephyr 物联网操作系统
· RTthread
RTthread 是纯国产的小型操作系统，植根于中国的各种使用场景，10 年来已经确立了自己的地位，在很多行业有自己的一席之地，目前社区非常活跃，核心团队以创业公司的形式推进，非常专注。技术上的特征作为一个成熟的系统，没有什么可以吐槽的地方。Zephyr 有的技术优势 RTT 都有，而且 RTT 在生产环境的装机量较为可观。
· 华为 LiteOS
华为是全球范围内物联网技术的根源厂商之一，LiteOS 是一个华为内部很多产品都在用的系统，目前也以开源的形式在全力推广。LiteOS 最大的优势在于华为很多根源技术将利用 LiteOS 进行输出，目前最大的例子就是即将全面商用的 NB-IoT 技术，设备端的开发包将会用 LiteOS 输出。
以上几个系统一致的特点包括小型化、芯片适应范围广、通信协议适配比较广泛等，他们也都是开源的系统，研发或推动力量比较活跃。有可能在物联网领域里的类似 Linux 地位的主流操作系统会是其中某个，也或许会一直都存在下去但是在技术上越来越趋同。
开发框架
首先解释一下开发框架，开发框架可以小到是一个细节的工具，也可以大到规定开发的全部边界。最典型的例子是 Android，纯粹操作系统意义上，Android 是 Linux 的一个分支，但是从 App 开发角度，除 NDK之外，没有任何与 Linux 打交道的地方，所以也把 Android 叫做操作系统。再广泛地看，Android 除了面向手机应用的开发框架，还准备了 Google play 这样的应用分发渠道，这是开发者生态建设。同理，我们看Node.js 在后端的种种开发模式，也是将所有后端资源都封装到 JavaScript 里，开发时可以随时 npm install各种包来 require，解决了代码复用问题。
因此我的观点是，开发框架以及背后的代码复用和开发者生态才是真正的操作系统。
目前在物联网领域，正在尝试向生产环境演进的开发框架基本都基于 JavaScript，而在小型实时操作系统上使用的 JavaScript runtime 目前也基本集中到了 JerryScript 上。JerryScript 是三星开发和开源的一个小资源占用的引擎，内存需要 64KB，存储需要 200KB 即可，能够实现完整的事件驱动，符合 ECMAScript 5.1。
如同前文所说，开发框架或是操作系统在当下需要包括以代码复用为目的的开发者生态，甚至需要包括应用分发，所以我们看到在 JerryScript 的基础上，有两家做这类工作的团队值得关注：
· WRTnode
WRTnode 是一个北京的开源硬件团队，提供从开发到硬件交付的全流程服务。他们最近开放的node.system 和 noyun.io 即是着眼于实现物联网 JavaScript 的开发框架和开发者生态。在 WRTnode 的实现里，设备端的 JavaScript 开发已经变得像 cloud9.io 一样全案在线开发，为开发者屏蔽了嵌入式开发的繁琐编译烧写工作。
· Ruff
Ruff 是位于上海的创业公司，2015 年开始一直在演进基于物联网设备端 JavaScript 的开发者生态，提供了较为可行的代码复用框架。目前他们已经开始服务商业客户，为物联网应用的快速实现提供了可能。
同时，Zephyr 和华为 LiteOS 也都有各自的 JavaScript runtime 发布计划。
以上我们看到了设备端开发的一些新的发展，目前这些新的设备端开发技术，已经逐步面向交付转移了。有理由相信经过一段时间的发展，面向效率的商业模式驱动下的物联网开发技术将迎来一大波更新，从而导向物联网应用的真正大发展。
来源：CSDN