关于内网穿透的思考

[y4h2]

需求场景

• 我们通过Webhook向发送notification
• 用户的server被隔离在VPC内部
• 需要一个tunnel, 让我们的webhook请求能够顺利到达用户的server

当时的方案

构造了一个WebSocket server， 一端连在我们的server上，websocket client端需要部署在VPC内部。 两端之间用WebSocket连接，把原本的的单向request，变成了一个相当复杂的双向交互式系统。

• 首先VPC内部的websocket client端，需要尝试主动连接我们的websocket server端。（当然这里还需要实现认证， 在部署client的时候需要设置密钥信息）
• client端连上server端之后，就等待server端的消息。server端会维护一个clIent的注册信息，映射client id和connection ID
• server端在需要发送请求的时候，就找到对应的connection发送请求

这里再说说这个方案存在的问题

• 部署（更新）困难：当发现代码有问题，需要更新client端代码时，非常的复杂。首先服务器不受我们团队控制, 每次更新并没有CI/CD可以直接使用， 还要经过CAB之类的approval。而且那套部署流程，我至今都还没有完全掌握（极度传统ops）。
• 代码逻辑复杂：
  • 把原本一个request就能解决的问题，变成了多步处理，这样每一步都会增加出错的概率。
  • 从一个请求变成了维护长连接， golang的websocket本身不够稳定，现有的package都非常偏底层，需要自己实现处理连接超时和重连的问题。整个处理逻辑无比复杂，还不能保证一定正确。
• 代码逻辑复杂带来的直接问题就是维护成本高
• 资源使用率问题，为了保证server端随时能够找到client端，所以必须保持长连接，一旦连接中断，client必须马上重连，但是实际使用中发请求占用的时间比率相当之低，空闲率甚至能高于90%~95%。
• scale问题，因为server端要一直保证长连接，所以server的压力会非常大。

事后的思考

一个从根源上解决问题的方法就是配置防火墙，让我们server的ip能够通过VPC.

其次，可以考虑pub/sub的方案来处理，即客户端subscribe SQS，收到消息后立即发送webhook request

其他方案比如gRPC的streaming也是可行的

心路历程

算是从头到尾参与的一个烂项目，项目开展之前没有足够的时间做调研，等到发现架构有问题的时候，leader却已经在高层面前做完了demo, 开始着手实现细节了。等到想要阻止的时候，已经箭在弦上必须要上线了。 还有一些问题是开始没有想到的，比如connection频繁中断，这个在测试之后就暴露了。

NAT穿透的主要原理：由内网主动找外网建立连接，建立连接之后，外网可以向内网发消息

另：通过pub/sub模式可以避开NAT穿透