前言
先说一下场景需求:
1、远程ssh访问设备,但是设备端不具备公网访问能力。
2、物联网采集网关,通过4G连接外网,网关部署在项目现场,我们不知道网关的IP,就算知道,网络链路也不通。对于网关的远程调试和运维都无法进行。
目前的解决方案:
1、通过SD-WAN技术,设备与设备之间打通隧道。
2、通过VPN,本地部署VPN服务器,实现VPN专网。
3、采用阿里云/华为云边缘计算解决方案,设备连接到阿里云/华为云边缘平台,实现远程运维、调试。
现有方案优缺点
1、SD-WAN技术,需要配备SD-WAN软件或硬件,对于企业用户是合适的。但是设备厂商并不合适。
2、采用VPN,如果是运营商VPN,成本昂贵,如果是私有部署VPN,部署相对专业,我没有部署过,不过有一定的专业门槛。
3、使用公有云提供的边缘计算方案,相当于要捆绑公有云,有不小的学习成本。
综上,上述方案的优点简单的说就是方案成熟,稳定,缺点就是要花钱买钱和不少人力。
工程师方案
上面的方案是基于外部力量实现的,对于稍微有些能力的开发者而言,也是有少花钱的解决方案的,简单的说,就是在一台公网服务器上,部署一个自己开发的 隧道转发 应用程序,设备通过 自己开发的应用程序来建立隧道,进而实现转发,流转。这种方案,理论上可行,稍微有点网络基础的人就知道,背后的工作量巨大,光是稳定性这块就很难保证,就更不用提多并发管理了。
MQTT Broker转发方案
上面所有的方案,基本上都是要实现一个中转站,上面提到的工程师方案的难点和缺点是,一般人很难开发出稳定、高可用、并发的中转服务器。那么如果有个 现成的、方便部署、稳定、可靠的中转服务器呢,是否就能解决问题了呢,答案是:yes,有这样的方案。
关于MQTT的通信协议,可以看我之前关于MQTT的系列文章:
《MQTT协议详解及开发教程(一)MQTT协议概述》, 这里就不赘述了。解决方案如下:
我们以MQTT Broker EMQx为例,网关和远程调试工具作为mqtt client, 通过2个topic:up和down
- 配置工具想要发送命令,则publis消息到 down topic, 网关订阅down topic,收到命令,对命令进行解析并执行,然后返回消息,publis消息到up topic,而配置工具订阅up topic,收到返回数据。
这种方案,实现了一种通过Broker搭建隧道,实现数据中转。
优点
可能有些不熟悉MQTT协议的人会觉得,该方案好像也不过如此啊,原理貌似懂,但是干的事儿好像也不少啊,其实不然,这种方案有很多优点:
1、MQTT是物联网领域的通用标准,不管是阿里云物联网、还是华为IOT,还是其他公司的IOT,基本上都是通过MQTT协议,可以说MQTT已经是物联网领域事实上的标准了,标准的优点就是方便,支持多,资料多。
2、MQTT Broker部署非常方便,以EMQx为例,只需要一台服务器,不管是windows还是linux,部署非常方便,几乎不要什么专业知识。
3、MQTT Broker可选择对象多,EMQx、Apoll等等。
4、开源、免费、稳定,除非要求完善、高质量的服务,一般的知名开源Broker都是免费试用的,关键是非常稳定。
其他工作量
有了MQTT Broker的帮助,对于开发者,我们再也不用干数据转发、打通隧道这种专业性强、复杂的活儿了,我们只需要针对我们自己的应用需求,做MQTT消息的解析即可。
小结
经过测试验证,该方案可以实现:
- JSON、ASCII码等字符串转发,所以理论上可以实现 ssh模拟。
- 字节、数值、十六进制数值的转发,所以可以实现远程功能调试,比如Modbus。
- MQTT支持字节流转发,也就是支持文件传输,实现文件的转发,类似于xftp。
该方案稳定、部署方便,用户只需要关注自己的业务应用即可,目前了解到,一些物联网关(中电网关)就是通过该方案实现的远程调试、下载、上载功能。