Websocket与多个Chrome Docker容器的通信

您的基本设计是正确的,但您遇到的问题是会话粘性。然而,我们应该寻找一种避免“pre”请求的方法,而不是尝试将后续请求重新路由回相应的机器。

最好的方法是让您的Chrome docker image man位于所有http–upgrade–请求的中间。此http操作是所有WebSocket连接在更改协议之前发出的,包括Puppeter库(它只是一个隐藏的WebSocket客户端)。这样做还可以避免预连接调用,因为代理Chrome将在升级时发生,而不是公开应用程序要使用的URL。下面是一个使用 http-proxy 模块:

const http = require('http');
const httpProxy = require('http-proxy');

const proxy = new httpProxy.createProxyServer();

http
  .createServer()
  .on('upgrade', async(req, socket, head) => {
      const browser = await puppeteer.launch();
      const target = browser.wsEndpoint();

      proxyy.ws(req, socket, head, { target })
  })
  .listen(3000);

这种方法还有其他好处:您可以限制并发性,甚至可以注入脚本以便稍后运行。这些需要更多的思考和准备,但总体思路保持不变。这也使得负载平衡变得微不足道,因为不需要使路由变得有粘性。

如果这是您感兴趣的事情,那么在 browserless 回购。它甚至允许并发限制、会话时间限制和 includes a feature-rich IDE . 你可以找到更多 docs on that project here .