jvs-server不适合生产环境高可用，因其单进程、内存索引、无多实例同步、无健康检查端点，无法满足持久化、横向扩展与流量可靠性要求。
为什么 jvs-server 不适合生产环境高可用
jvs-server 是个轻量级私有 Open VSX 服务，启动快、依赖少，但它的设计目标是“能跑”，不是“扛压”。它单进程、无状态存储、不支持多实例注册中心，所有扩展元数据都靠内存索引——进程一挂，整个市场就不可用；横向扩容时，各实例间无法同步索引，客户端轮询会拿到不一致的扩展列表。更关键的是，它默认不带健康检查端点，Kubernetes 的 livenessProbe 无法判断服务是否真在响应 gallery 请求，容易造成流量误导。
Open VSX Registry + PostgreSQL + Nginx 高可用组合
真正可落地的高可用方案，必须拆解为三层：存储层（持久化扩展元数据）、服务层（可水平扩展的 registry 实例）、接入层（负载均衡与缓存）。推荐组合如下：
- 存储层用
PostgreSQL：官方 registry 镜像原生支持，支持扩展版本历史、命名空间权限、发布审计日志，比 SQLite 或文件系统可靠得多 - 服务层部署至少 2 个
open-vsx-registry实例（Docker Compose 或 Kubernetes StatefulSet），共享同一 PG 实例，通过PG_CONNECTION_URL环境变量注入连接串 - 接入层用
Nginx做反向代理，启用upstream健康检查（health_check interval=3 fails=2 passes=2），并缓存/vscode/gallery和/vscode/item的 GET 响应（TTL 60s）以降低后端压力
注意：open-vsx-registry 的 serviceUrl 必须配置为 Nginx 入口域名（如 https://vsx.internal.company.com/vscode/gallery），不能指向某台具体实例 IP，否则客户端缓存会绕过 LB。
VSCode 客户端配置必须加 fallback 机制
即使服务端做了高可用，客户端一次配置错误就会导致整个扩展视图瘫痪。不要只写 extensionsGallery.serviceUrl，务必补全三字段：
"extensionsGallery": {
"serviceUrl": "https://vsx.internal.company.com/vscode/gallery",
"itemUrl": "https://vsx.internal.company.com/vscode/item",
"resourceUrlTemplate": "https://vsx.internal.company.com/vscode/resource/{publisher}/{name}/{version}/{path}"
}
漏掉 itemUrl 会导致点击扩展详情页白屏；漏掉 resourceUrlTemplate 会让安装按钮失效，报错 Unable to fetch extension resource。这些字段在 VSCode 启动时一次性读取，改完必须重启，热重载不生效。
CI/CD 发布流水线中容易忽略的校验点
自动化发布 .vsix 到私有市场时，光调用 ofoxa publish 或 curl -X POST 是不够的。以下三点必须嵌入流水线：
- 校验
.vsix文件签名：运行vsce verify <file.vsix></file.vsix>，确认包内package.json的engines.vscode版本范围与企业统一要求一致（例如"^1.85.0"） - 检查 publisher 名称是否已注册：调用
GET /api/v1/publishers/{publisher}，避免因拼写错误（如myteamvsmy-team）导致发布失败却无提示 - 发布后触发一致性探测：用脚本模拟客户端请求
GET https://vsx.internal.company.com/vscode/gallery?searchText=xxx，验证返回 JSON 中包含新版本号且downloadUrl可 HTTP HEAD 成功
没做这三步，灰度发布时可能发现：扩展在市场里显示了，但开发人员点安装却卡在“正在下载”，实际是 downloadUrl 返回 404 —— 因为 registry 没把资源文件同步到对象存储或本地磁盘路径。
