前言
最近接手了供方开发的网关项目,交接文档里面有个内网穿透的功能,一下子就吸引的我的目光。实现这个内网穿透的背景是业务部门有些业务是部署在公网,这些公网的业务想访问内网的业务,但因为公网和内网没打通,导致无法访问,为了解决这个问题,供方在网关上做了一个内网穿透功能
应用层如何实现内网穿透
大致的整体流程如图,这里的实现核心就是在外网部署了一个消息中间件,通过这个消息中间件打通内外网数据传输通道,间接打通了内外网访问。当时我看到这个方案时,第一感觉是能设计出这个方案的人,真是人才,但后面细究下去,发现这个方案其实有些问题,后面会说
其次他们这个消息中间件选用了kafka,而非其他消息中间件,是因为kafka有个请求-响应模式的能力,就跟rpc的调用类似,具有将异步转同步的能力。具体实现就是利用spring-kafka提供的ReplyingKafkaTemplate来实现这一能力,其用法可以查看我之前文章
聊聊如何利用kafka实现请求-响应模式
使用消息中间件来做内网穿透存在的问题?
a、 消息中间件自有复杂性
- 消息中间件的可靠性,可用性如何保证
- 重复消费如何解决
- 消息的积压问题
b、 业务侵入性
业务需在订阅到数据后,做幂等性校验,同时业务还需要根据供方提供的规范进行数据响应,对业务开发人员有一定技术要求
那有没有相对优雅一点的方案?
实现核心点,通过在外网部署反向代理,同时打通反向代理与网关之间的专线网络,这么做的好处就是业务层基本上不用改动,其次相比运维中间的复杂度,运维反向代理的复杂度会相对低一点
总结
不管是通过消息队列还是通过反向代理来实现内网穿透,本质上就是多加一层来解决,就是应了一句话,没有什么是加一层中间层不能解决的,如果有,那就再加一层。
其次加反向代理是最容易想到方案,当时供方不可能没想到,主要原因是因为他们有交付压力,其次因为他们是乙方,要申请专线需要通过层层审核,最后外包基本上他们是不会考虑到后续的运维复杂度
有时候我们做方案设计,是需要加入当时业务场景以及资源来做一定的收敛以及权衡
文末我按供方的实现思路,写了一个阉割版、基于kafka实现内网穿透的demo,感兴趣的朋友,可以参考下
demo链接
https://github.com/lyb-geek/springboot-learning/tree/master/springboot-kafka-forward