前言
先说一下场景需求：
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。
该方案稳定、部署方便，用户只需要关注自己的业务应用即可，目前了解到，一些物联网关（中电网关）就是通过该方案实现的远程调试、下载、上载功能。
