聊聊在应用层面实现内网穿透功能是否可行

前言

最近接手了供方开发的网关项目，交接文档里面有个内网穿透的功能，一下子就吸引的我的目光。实现这个内网穿透的背景是业务部门有些业务是部署在公网，这些公网的业务想访问内网的业务，但因为公网和内网没打通，导致无法访问，为了解决这个问题，供方在网关上做了一个内网穿透功能

应用层如何实现内网穿透

大致的整体流程如图，这里的实现核心就是在外网部署了一个消息中间件，通过这个消息中间件打通内外网数据传输通道，间接打通了内外网访问。当时我看到这个方案时，第一感觉是能设计出这个方案的人，真是人才，但后面细究下去，发现这个方案其实有些问题，后面会说

其次他们这个消息中间件选用了kafka，而非其他消息中间件，是因为kafka有个请求-响应模式的能力，就跟rpc的调用类似，具有将异步转同步的能力。具体实现就是利用spring-kafka提供的ReplyingKafkaTemplate来实现这一能力，其用法可以查看我之前文章
聊聊如何利用kafka实现请求-响应模式

使用消息中间件来做内网穿透存在的问题？

a、 消息中间件自有复杂性

• 消息中间件的可靠性，可用性如何保证
• 重复消费如何解决
• 消息的积压问题

b、 业务侵入性

业务需在订阅到数据后，做幂等性校验，同时业务还需要根据供方提供的规范进行数据响应，对业务开发人员有一定技术要求

那有没有相对优雅一点的方案？

实现核心点，通过在外网部署反向代理，同时打通反向代理与网关之间的专线网络，这么做的好处就是业务层基本上不用改动，其次相比运维中间的复杂度，运维反向代理的复杂度会相对低一点

总结

不管是通过消息队列还是通过反向代理来实现内网穿透，本质上就是多加一层来解决，就是应了一句话，没有什么是加一层中间层不能解决的，如果有，那就再加一层。

其次加反向代理是最容易想到方案，当时供方不可能没想到，主要原因是因为他们有交付压力，其次因为他们是乙方，要申请专线需要通过层层审核，最后外包基本上他们是不会考虑到后续的运维复杂度

有时候我们做方案设计，是需要加入当时业务场景以及资源来做一定的收敛以及权衡

文末我按供方的实现思路，写了一个阉割版、基于kafka实现内网穿透的demo，感兴趣的朋友，可以参考下

demo链接

https://github.com/lyb-geek/springboot-learning/tree/master/springboot-kafka-forward