私有插件市场需负载均衡，因单台 vscode-extension-marketplace-server 在中大型团队下易成瓶颈：并发超200时内存飙升、延迟超3s，触发客户端 network error；其纯内存索引架构不支持水平扩缩，必须前置 Nginx 负载分摊——需禁用 proxy_buffering、定制健康检查、调整 max_fails、透传 Host 头，并统一扩展目录或定时 rsync 同步，DNS 轮询是推荐的高可用方案。
为什么私有插件市场需要负载均衡
单台 vscode-extension-marketplace-server 实例在中大型团队（>50人）下容易成为瓶颈：启动 VSCode 时批量拉取扩展列表、安装插件时并发下载 .vsix、CI/CD 流水线自动安装依赖，都会触发短时高并发请求。实测发现，当并发连接 >200 时，内存占用飙升、响应延迟超 3s，部分客户端会直接报 network error 或卡在 Installing... 状态。这不是代码缺陷，而是纯静态服务的天然限制——它用内存索引全部扩展元数据，不支持水平扩缩容，必须靠前置负载层分摊压力。
用 Nginx 做最简可行的负载均衡配置
别碰 Kubernetes Service 或云厂商 LB——私有市场流量模式简单（全是 HTTP GET，无长连接、无 WebSocket），Nginx 就够用，且兼容性最好。关键点不是“怎么配”，而是“哪些必须配”：
- 必须启用
proxy_buffering off：VSCode 客户端对响应头敏感，Nginx 默认开启缓冲会导致Content-Length被改写，触发客户端校验失败 - 健康检查不能只看 HTTP 200：
vscode-extension-marketplace-server启动后返回 JSON 元信息，但索引未就绪时仍返回 200。需加一层脚本探活，例如curl -s http://localhost:8080 | jq -e '.extensions' > /dev/null - upstream 必须显式配置
max_fails=1 fail_timeout=10s：默认值（max_fails=1, fail_timeout=10s）太激进，单次网络抖动就会踢出节点；调成max_fails=3 fail_timeout=30s更稳 - 所有
location /块必须透传原始 Host 头：proxy_set_header Host $host;，否则多实例共享同一域名时，部分扩展包的 CDN URL 会拼错
多实例部署时的文件同步陷阱
扩展包（.vsix）目录不能靠 NFS 或 SMB 实时挂载——vscode-extension-marketplace-server 启动时扫描一次文件系统并构建内存索引，后续新增 .vsix 不会自动 reload。常见错误是：往 A 实例的 /path/to/extensions 放了新插件，B 实例却查不到。解决路径只有两条：
- 所有实例共用同一块本地磁盘（如 RAID1），且启动命令统一指向该路径（推荐，零额外组件）
- 用
rsync -av --delete定时同步（例如每 2 分钟），配合inotifywait监听新增文件后立即触发同步，再向各实例发SIGHUP（注意：该信号仅重载路由，不重建索引，所以仍需重启进程）
别用 Git 同步——.vsix 是二进制文件，Git diff 和 merge 毫无意义，反而增加冲突风险。
客户端配置不随服务端扩容自动生效
VSCode 只认一个 extensions.gallery.serviceUrl，不会自己做 DNS 轮询或服务发现。你搭了三台 Nginx 做负载均衡，客户端仍只连其中一个 VIP 或域名。这意味着：如果 Nginx 单点故障，整个插件市场就不可用。真实可用的方案只有：
- 用 DNS 轮询 + 短 TTL（如 60s）：把
marketplace.internal解析到三个 Nginx IP，客户端随机选一个，故障时靠 TTL 过期后重试（缺点：故障窗口最长 60s） - 客户端侧硬编码多个 fallback URL（不推荐）：VSCode 不支持配置数组，只能靠外部脚本轮换
settings.json中的extensions.gallery.serviceUrl值，运维成本高
最常被忽略的一点：Nginx 日志里 $upstream_addr 字段显示的是后端实例 IP，但 VSCode 客户端日志里的 getGalleryServiceUrl failed 错误，永远只暴露最外层负载均衡器的地址——排查时得先确认 Nginx 是否真把请求转发到了后端，而不是卡在它自己这层。
