昨天同事问我：你桌上堆这么多硬件干嘛？
我说搞物联网后台。
他说：你还自己写后台啊？不是有现成的吗？
挺惊讶的。
没有开源的时候有多痛苦
记得去年接手一个项目，老板说两个月上线。
我看了需求后就懵了——光设备接入层就得写一个月。
如果自己来实现MQTT协议，自己去维护设备影子，从零搭建规则引擎。
后来找到一款商业平台，报价六位数。
老板直接否决。
全开源的出现改变了什么？
设备联网平台，综合管理系统，快速连接工具。
这些都是我今年仔细研究过的项目。
坦率讲，瞅见的头一回，吾猜想起码得钻研七天方能够运转起来。
其结果是，执行- up操作，在不到十分钟的时长内，所有服务均已启动起来了。
连数据库配置都不需要你操心。
那种开箱即用的感觉真的很爽。
：21.6k星的重量级
我瞅了瞅数据，上面存有21.6k这般数量的星标，拥有2k个分支，其社区活跃度极其之高。
支持MQTT、CoAP、HTTP三种标准协议。
很多大型企业的物联网系统都在用。
电信、智慧城市、环境监测，全都是业务量极重的场景。
还有一个很关键的点：它支持多租户。
要是你从事SaaS服务领域，需同时为多家企业供给物联网平台，此物便是刚需里最具刚性的要求。
：如果你想完全掌控
另一个我比较欣赏的项目是。
它在上被描述为”物联网平台框架”。
注意这个词——框架，不是平台。
什么意思？
那种传统的物联网平台，是给予你一整套已然现成的事物，并且你仅能够在它所限定的范围之内去进行操作。
但更像乐高。
你不只是用户，你可以修改它的每一个模块。
身份管理、访问控制、设备配置、数据处理。
所有核心功能都可以调整。
这对于那些项目而言，是非常友好的，这些项目对技术栈有着特殊要求，或者团队实力比较强。
使用Go语言编写，性能很高，资源消耗也很低。
为什么强调全开源？
全开源不只是源码公开这么简单。
前几日，瞅见一篇文章，其讲述的是，有占比74%的代码库，存在着高风险的开源漏洞。
看到这个数字我倒吸了一口凉气。
这就是双刃剑：你能自己改代码，但漏洞也得自己挖、自己补。
你必须搭建自己的安全检查流程。
这不是加个依赖就能解决的事情。
：国内的全响应式方案
要是你对国产项目存有偏好，那么同样是极为不错的一种选择。
全响应式物联网平台，是基于 Boot进行开发的，在Gitee上有着很高的热度。
主打的是”开箱即用、可二次开发”。
特别适合企业级的场景。
它支持对于统一物模型的管理，TCP协议能凭着它统一接入，MQTT协议也能借着它统一接入，UDP协议同样可经由它统一接入，CoAP协议也都可通过它统一接入，要将编程的复杂性给屏蔽掉。
选择哪个？我做了一个对比表
这是我花了一周多时间测试后的结论：
，属于Java技术栈，具备重量级特性，其功能最为齐全，适用于那种有着完整后台管理系统诉求的场景。
，其技术栈为Go，具备轻量性且速度快，适宜云原生架构。
，具备全响应式特性，属于Java范畴，其性能较为突出，适用于高并发的场景之中。
简单点说：
要是你所在的公司从事Java编写工作，不想弄得十分复杂，直接采用会是最为省事的做法。
如果你是Go技术栈，想要完全掌控，选。
假如业务量庞大到超乎想象，并且并发程度特别高，那么的响应式架构兴许会更适宜。
开源生态也有糟心的时候
上周看到高通收购的消息。
社区一片哀嚎，都在担心”已死”。
几天前，团队赶忙发布声明，宣称“四大支柱”原则依旧具备效力。
但谁知道呢？
商业收购之后，谁能保证开源精神不变味？
这让我想到，选择物联网平台也得考虑背后的团队背景。
单单依靠由单一商业公司负责维护的开源项目，要是哪一天公司的战略出现了调整可怎么办呢。
容易被忽视的事情
很多人只看功能清单。
但我更看重三件事：
去瞧瞧社区活跃度，瞅瞅的回复速度怎样，看看PR完成合并是否及时。
文档的质量。真遇到问题的时候，没文档你就等着哭吧。
是否存在现成的硬件驱动库，是否拥有成熟的行业解决方案，关于周边生态。
最后，别太完美主义
令人颇为汗颜地讲，在我首次开展部署操作之时，在数据库连接池这项配置环节，未曾妥善调配好，以至于整个进程持续卡顿了足足三天之久，真可谓状况连连，难堪至极。
后来在官方论坛翻到一个沉底的帖子，发现了原因。
现在想想，其实挺没必要的。
如果你现在正犹豫要用哪个平台，我的建议是动手试试。
选两个目标平台，各花两天时间跑通demo。
哪个顺利用哪个。
哪个文档看得顺眼用哪个。
看再多评测文章也不如自己亲手跑一遍。
全开源物联网的意义，从来不是让你省下买商业软件的钱。
而是让你真正拥有自主权，不再被任何一个厂商绑架。
这也是为什么，过去几个月我一直在折腾这些项目。
累归累，但踏实。
不知道正在看这篇文章的你，在自己的物联网项目里踩过什么坑？
来留言区聊聊呗。
