Web应用场景下支撑大规模多用户使用Wetty的方案咨询

你之前尝试的两套方案存在不可解决的硬伤：

• 多独立端口方案：每个用户对应一个Wetty进程+独立端口，不仅会在万级用户规模下触发端口资源耗尽，还会产生无意义的进程开销，光进程启动、存活检测、生命周期管理的成本就会压垮应用，完全不具备可行性。
• 单端口多base路径方案无法运行的本质原因：Wetty的--base是单进程全局配置参数，尝试给不同用户启动同端口的Wetty进程，系统会直接抛出端口占用错误，多进程根本无法正常启动，自然没法实现分流。

最优架构逻辑 #

彻底摒弃“一个用户对应一个Wetty进程”的思路，采用“少量Wetty常驻实例+上层反向代理分流适配”的架构，仅用个位数的Wetty进程，就能支撑上万级用户的访问需求。

具体落地步骤 #

• 启动统一的Wetty常驻实例
  启动时不要硬编码绑定固定执行脚本，打开原生支持的命令透传能力，配置合理的单实例会话上限，示例启动命令：

  wetty --port=3000 --max-sessions=10000 --command=""
  

  空配置的执行命令参数，会让Wetty自动从对应请求中读取要执行的脚本命令，不需要修改Wetty源码就能适配多用户场景。
• 上层反向代理做用户级请求匹配
  把所有用户的Wetty访问路径统一为固定格式/wetty/{用户专属token}，通过Nginx这类反向代理组件，把不同路径的请求统一转发到同一个Wetty实例，转发时完成两个核心动作：
  • 权限校验：先在代理层校验当前访问的token是否有效，无效请求直接拦截，不透传到Wetty层
  • 参数注入：根据token匹配对应用户的专属telegrambot.py配置（包含bot token、自定义脚本参数），通过请求头注入到转发的Wetty请求里，让每个用户的会话自动执行对应配置的脚本
• 多层会话隔离
  因为所有用户的会话都跑在统一的Wetty实例下，必须做两层资源隔离避免互相影响：
  • 系统级隔离：每个Wetty拉起的用户脚本进程，绑定到独立的低权限Linux系统用户下，通过cgroup配置CPU、内存、磁盘的资源限额，避免单个用户的脚本异常占用全服务器资源
  • 会话级隔离：给每个Wetty会话配置固定的无操作超时回收策略，自动清理长时间不活动的僵尸会话，避免无意义的资源占用
• Django侧集成适配
  后端不需要维护任何独立的Wetty进程，仅需完成两个动作：
  • 给每个用户生成带专属token的Wetty访问链接，渲染到前端的终端入口页面
  • 把用户的专属token、脚本配置数据通过内部API暴露给反向代理层，供代理层完成请求匹配和参数注入

注意：如果单个Wetty实例的性能不足以支撑目标用户规模，可以横向启动少量带不同端口的Wetty实例，在反向代理层做负载均衡即可，全程端口数量仅和Wetty实例数挂钩，不需要给每个用户分配独立端口。

内容的提问来源于stack exchange，提问作者ー PupSoZeyDe ー