Bisheng 高可用部署实战4 步把 LLM 平台推上生产环境【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng生产环境里LLM 平台最怕两件事单点故障让全站离线数据丢失让知识库一夜清零。Bisheng 的高可用方案围绕API 多实例 存储层持久化 健康检查自愈三条线展开靠 Docker Compose 多副本编排即可落地。本实战按规划 → 部署 → 调优 → 排障顺序走一遍完整流程。 部署前规划先定规格再动手高可用不是把容器多起几个而是先想清楚资源、网络和持久化三件事。资源规格单机 3 节点起步参考项目最低配置推荐配置说明CPU4 vCPU18 vCPUAPI 至少 2 核Worker 至少 4 核内存16 GB48 GB知识库解析与向量写入是内存大户磁盘100 GB SSD500 GB NVMe存 MySQL 数据、Milvus 向量、MinIO 对象节点数1不推荐3API 至少 2 实例存储层跨节点网络拓扑要求3 台服务器互通内网Nginx 统一对外暴露 80/443其余端口走内网前端容器只开放 3001MySQL/Redis/Milvus 一律不映射公网端口节点间延迟 2ms跨机房部署需评估 MySQL 主从延迟数据持久化策略所有有状态服务MySQL、Redis、Milvus、MinIO、ES的数据目录必须挂到宿主机独立磁盘DOCKER_VOLUME_DIRECTORY环境变量统一指定数据根目录避免数据散落在容器层备份策略在部署当天就要定MySQL 每日全量、Redis AOF、MinIO 多副本缺一不可规划清楚了才谈得上部署。 从零到集群四步完成高可用上线第 1 步拉取部署代码git clone https://gitcode.com/GitHub_Trending/bi/bisheng cd bisheng/docker拉下的是完整编排模板核心是 docker-compose-ft.yml 同目录的主 compose 文件里面定义了 MySQL、Redis、Milvus、ES、MinIO、后端 API、Worker、前端共 9 个容器。第 2 步改配置替换生产参数编辑 config.yaml重点改三处# 1. 数据库密码Fernet 加密串改密码需同步改 MYSQL_ROOT_PASSWORD database_url: mysqlpymysql://root:加密后的密码mysql:3306/bisheng?charsetutf8mb4 # 2. Redis 指向生产实例支持 cluster/sentinel 两种模式 redis_url: redis://redis:6379/1 # 3. Celery broker 单独指定 db避免和缓存混用 celery_redis_url: redis://redis:6379/2这一步在把演示配置换成生产参数。成功标志文件无语法错误且 compose 里的BS_MINIO_ENDPOINT、BS_MILVUS_CONNECTION_ARGS等环境变量与实际网络一致。第 3 步启动多实例cd docker docker compose -p bisheng up -d # 扩容 API 与 Worker 多副本 docker compose -p bisheng up -d --scale backend3 --scale backend_worker2第一条命令拉起全部 9 个基础容器并按depends_on顺序等待 MySQL、Redis 健康第二条把 API 扩到 3 副本、Worker 扩到 2 副本实现无状态服务冗余。成功标志docker compose -p bisheng ps中 backend 出现 3 个实例且状态均为 running。第 4 步健康验证# 逐个探活 API 实例 curl -sf http://节点1:7860/health curl -sf http://节点2:7860/health # 查看整体状态与最近日志 docker compose -p bisheng ps docker compose -p bisheng logs --tail50 backend/health端点由 compose 内置健康检查驱动间隔 90s、超时 30s返回 200 即实例可接流量。日志里看到 uvicorn 监听 7860、无 alembic 报错说明数据库迁移和 API 启动都正常。集群跑起来只是及格线真正决定生产稳定性的是下面这组参数。⚙️ 调优 加固 备份五个关键项Worker 内存分配参数deploy.resources.limits.memory: 16Gcompose 中给backend_worker加内存上限为什么这么配Worker 用线程池跑知识库解析默认-c 100线程单个 PDF 解析可吃数百 MB 内存不限内存时 OOM 会连带打挂整个节点预期效果单容器内存封顶异常任务被容器层隔离宿主机不再被拖垮Nginx keepalive 与连接参数worker_processes auto; events { worker_connections 1024; } http { keepalive_timeout 65; }为什么这么配LLM 对话是长连接流式输出keepalive_timeout 65让前后端复用 TCP 连接worker_connections 1024支撑并发 WebSocket预期效果高并发下连接重建开销下降对话首字延迟稳定参考仓库内 docker/nginx/nginx.conf 的默认值按需上调MySQL 主从 每日备份mysqldump -uroot -p bisheng --single-transaction --routines | \ gzip /backup/bisheng_$(date %F).sql.gz # 主从从库开启 relay log 后执行 CHANGE REPLICATION SOURCE再 # docker exec bisheng-mysql sh -c echo SHOW SLAVE STATUS\G | mysql -uroot -p为什么这么配主库故障时从库可接管读流量--single-transaction保证 InnoDB 一致性快照不锁表预期效果RPO 控制在 24 小时内主库切换不丢已备份数据Redis AOF 持久化appendonly yes appendfsync everysec为什么这么配Redis 承担 Celery Broker 和会话存储纯 RDB 崩溃会丢最多一小时的队列任务AOF everysec 把丢失窗口压到 1 秒预期效果重启后待处理任务完整恢复不会出现知识库解析任务消失MinIO 多副本纠删码# 宿主机多盘或多节点起服务节点 {1...4} 为各节点地址 minio server http://node{1...4}:9000/data --api-min-disks 2 --console-address :9001为什么这么配文档原件、向量附属文件都存 MinIO单盘损坏即文件丢失纠删码模式下任意 2 节点存活仍可读写预期效果单节点故障业务无感对象存储 RPO 归零 高频踩坑与快速排障坑 17860 端口被占用现象up -d后 backend 反复重启日志报bind: address already in use定位ss -lntp | grep 7860看占用进程修复docker stop掉旧实例或改 compose 端口映射为17860:7860后重启坑 2Worker 容器 OOM 被杀现象知识库批量导入时 worker 状态退出内存曲线触顶定位docker inspect bisheng-backend-worker --format {{.State.OOMKilled}}返回 true 即实锤修复按上文给 worker 配置memory: 16G上限并重启同时把解析并发降到 50knowledge_file_worker.queue_concurrency坑 3健康检查误判 unhealthy现象容器活着但docker compose ps标 unhealthyNginx 摘流导致间歇 502定位docker inspect bisheng-backend --format {{json .State.Health}}看最后一次探测失败原因修复数据库冷启动慢时把start_period从 30s 调到 60s确认为慢查询则先修 DB 再恢复探测坑 4SSL 证书过期现象浏览器报 NET::ERR_CERT_DATE_INVALIDAPI 调用方证书校验失败定位openssl x509 -enddate -noout -in /etc/nginx/certs/fullchain.pem修复替换新证书后docker exec bisheng-nginx nginx -s reload建议把到期日加进日历告警坑 5compose 文件版本不兼容现象老版本 Docker Compose v1 报Additional properties are not allowed或直接无法解析定位docker compose version低于 2.x 都会出问题修复升级到 Docker Compose v2 插件本文所有docker compose命令均基于 v2 语义✅ 上线后的例行动作把docker compose version、各组件镜像 tag、证书到期日写进巡检清单每季度核对一次版本落后情况。同时把/health探测失败、OOMKilled、磁盘水位接进监控告警故障在用户发现之前先打到值班人手上。【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考