概述说起隧道代理，熟悉的朋友肯定会想到frp，它是一个知名的开源隧道代理。并且这款产品还围绕隧道代理服务构建了自己的生态系统。今天的文章主要是想抛出一个观点，并用一个实验性的开源项目来进行论证。早在几年前，有兴趣的朋友可能已经注意到，一些软件已经开始尝试支持动态更新功能，尤其是在云原生环境下。比如：Nginx的dyups模块，Nginx的Unit服务，Kong的location热更新等。这在容器流行的背景下愈演愈烈。因此，对于frp之类的隧道代理服务，我也想尝试一下热更新模式。所以有了这个实验项目-Menet。这是一个实验项目，实验主要有两个方面：使用Melang语言开发，验证Melang语言的能力和稳定性，支持动态更新配置，实现上下游隧道动态建立和断开等功能。本项目不推荐使用Production环境，本文仅用于演示动态更新效果。要使用Menet，只需要安装Melang脚本解释器，然后执行Menet。$melangmenet.m这里有两个配置需要在启动前给定：管理端口，用来给这个代理服务下发配置的隧道端口，每个服务的隧道监听端口是启动时确定的，rest监听端口或远程连接是在运行过程中动态创建的。在默认示例中，配置文件的内容如下：//conf.mconf=['admin':[//HTTPAPI监听地址'ip':'0.0.0.0','port':'1234'],'tunnel':[//隧道服务器监听地址'ip':'0.0.0.0','port':'4321'],];如果这两个地址有修改需要的话，可以编辑conf.m文件进行修改。服务启动后，会看到终端输出两个监听地址，说明服务就绪。例子下面我们举个例子，假设我们有如下网络结构：|----------------||------------------|服务1|192.168.1.2|隧道1|192.168.1.3|service1---------------->|8080Menet|------------------>|4321Menet|------------->192.168.1.3:80|管理端口：1234||管理端口：1234||---------------||--------------------|简要说明：我们有一个真实的80服务运行在192.168.1.3上，我们希望使用隧道代理从192.168.1.2的8080端口访问这个服务。我们可以使用curl命令发送5个HTTP请求来完成这个结构的部署。我们一一解释：$curl-XPOST-d'{"name":"tunnel1","dest":["192.168.1.3","4321"]}'http://192.168.1.2:1234/tunnel这条命令是发给192.168.1.2的Menet的，目的是让1.2和1.3的4321端口（隧道端口）建立TCP连接，这样一条隧道（tunnel1）就建立好了。注意：这只是一个例子。实际中也可以向1.3发送请求，建立到1.2的隧道端口的TCP。$curl-XPOST-d'{"name":"service1","key":"UHI@&s8sa*S","type":"local","addr":["0.0.0.0","8080"]}'http://192.168.1.2:1234/service这个请求是用来告诉1.2Menet服务建立一个本地8080端口用于监控，并将监控服务命名为service1，隧道使用RC4加密，所以key是加密密钥，类型是local，表示在本地监控。$curl-XPOST-d'{"name":"service1","key":"UHI@&s8sa*S","type":"remote","addr":["192.168.1.3","80"]}'http://192.168.1.3:1234/service这个请求用来告诉1.3的Menet服务，当从隧道接收到service1的数据时，建立到192.168.1.3:80端口的连接并转发。$curl-XPOST-d'{"tunnel":"tunnel1","service":"service1","type":"local"}'http://192.168.1.2:1234/bind这个命令是为了通知1.2对于Menet服务，建立tunnel1和service1的映射关系。该命令是通知1.3Menet服务建立`tunnel1`和`service1`的映射关系。
