MogFace人脸检测模型WebUI企业级部署高可用架构与运维监控最近和几个做安防、智慧园区项目的朋友聊天他们都在头疼同一个问题好不容易把一个人脸检测模型调教好了一到业务高峰期服务就变得不稳定要么响应慢要么直接挂掉。客户投诉、业务中断运维团队疲于奔命。这让我想起了之前我们团队部署MogFace WebUI服务时踩过的坑。MogFace本身是个很优秀的人脸检测模型精度和速度都不错但直接一个单点服务扔到生产环境风险太大了。今天我就结合我们实际的落地经验聊聊怎么给MogFace WebUI搭建一个能扛住压力、稳定运行的高可用生产级架构。这套方案的核心就是让服务像一支训练有素的军队有冗余、有调度、有监控确保7x24小时在线。1. 为什么企业级部署需要高可用你可能觉得一个WebUI服务能跑起来不就行了但在企业生产环境里这远远不够。想象一下一个智慧门禁系统在上下班高峰期如果人脸识别服务卡顿或宕机会造成人群拥堵一个线上认证服务如果在活动期间崩溃带来的直接就是用户流失和资损。我们之前就遇到过单节点部署的MogFace服务在并发请求稍高时CPU直接打满响应时间从几百毫秒飙升到几十秒最终进程OOM内存溢出崩溃。这就是典型的“单点故障”。高可用架构要解决的就是消除单点让服务具备弹性。简单来说企业级部署的目标有三个业务不中断任何单个服务器、容器甚至机房出现问题服务都能自动切换用户无感知。性能可扩展当用户量增长、请求变多时可以通过增加实例来分摊压力保持响应速度。状态可监控运维人员能实时掌握服务的健康状态、性能指标出了问题能快速定位和告警。接下来我们就围绕这三点一步步构建MogFace的高可用部署方案。2. 核心架构设计与组件选型我们的目标是搭建一个清晰、健壮、易于维护的架构。下面这张图描绘了整体的设计思路[用户] | v [负载均衡器 (Nginx)] --- 流量入口分发请求 | -------------------------------------- | | | v v v [WebUI实例1] [WebUI实例2] [WebUI实例3] --- 无状态服务横向扩展 (Docker) (Docker) (Docker) | | | -------------------------------------- | | v v [主数据库 (PostgreSQL)] [从数据库 (PostgreSQL)] --- 数据持久化主从同步 | | --------------------------------------- | v [监控系统 (Prometheus Grafana)] --- 收集指标可视化展示与告警组件解读与选型理由容器与编排Docker Docker Compose/KubernetesDocker将MogFace WebUI及其依赖Python环境、模型文件、库打包成标准镜像。这保证了环境一致性在任何地方部署的行为都一样。Docker Compose适合中小规模部署或快速原型验证。用一个YAML文件就能定义和运行多容器应用WebUI、数据库、Nginx等管理起来非常方便。Kubernetes (K8s)生产环境的“标准答案”。它能自动化地管理成百上千的容器负责服务的部署、伸缩、自愈和负载均衡。如果你的服务实例很多或者需要更高级的滚动更新、服务发现功能K8s是必选项。本文会以Docker Compose为例讲解核心概念K8s的部署YAML配置思路是相通的。负载均衡Nginx作为流量网关接收所有外部请求然后按照策略如轮询分发给后端的多个WebUI实例。这既实现了负载分担也隐藏了后端实例当某个实例故障时Nginx会自动将流量切到健康的实例上。数据库PostgreSQL with 主从复制MogFace WebUI可能需要记录识别日志、用户信息或任务状态。我们选用PostgreSQL并设置主从复制。主数据库处理所有写操作INSERT, UPDATE, DELETE。从数据库实时同步主库的数据主要用于读操作SELECT。这样读写分离既提升了读性能也从数据层面提供了冗余备份。主库宕机时可以手动或通过工具提升从库为主库更高级的方案可以用Patroni等工具实现自动故障转移。监控告警Prometheus GrafanaPrometheus负责“抓取”和“存储”各类指标数据。它会定期从Nginx、每个WebUI实例、数据库以及服务器节点本身拉取性能数据如QPS、延迟、CPU/内存使用率。Grafana负责“展示”和“告警”。它连接Prometheus将枯燥的数据变成直观的仪表盘。我们可以设置规则当某个指标异常如错误率超过5%时自动通过邮件、钉钉、企业微信等渠道发送告警。3. 分步部署实战理论讲完了我们动手把架构搭起来。这里我们使用Docker Compose来演示所有配置都写在一个docker-compose.yml文件里一目了然。3.1 第一步准备MogFace WebUI的Docker镜像首先我们需要一个包含MogFace模型和WebUI应用的Docker镜像。创建一个Dockerfile# 使用一个轻量级的Python基础镜像 FROM python:3.9-slim # 设置工作目录 WORKDIR /app # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 复制应用代码和模型文件 COPY . . # 下载或复制预训练的MogFace模型文件到指定目录例如 ./models/ # 假设模型文件已存在于构建上下文中 # COPY ./models/mogface_model.pth ./models/ # 暴露WebUI端口假设你的WebUI运行在7860端口类似Gradio EXPOSE 7860 # 启动命令 CMD [python, app.py]你的requirements.txt需要包含MogFace的依赖例如torch,torchvision,gradio,opencv-python等以及你的WebUI应用代码app.py。3.2 第二步编写高可用Docker Compose配置这是核心的docker-compose.yml文件。我们定义了四个服务WebUI、Nginx、PostgreSQL主库、PostgreSQL从库。version: 3.8 services: # 1. MogFace WebUI 应用服务启动3个实例 mogface-webui: build: . image: mogface-webui:latest container_name: mogface-webui # 部署3个副本 deploy: replicas: 3 # 配置健康检查确保只有健康的实例接收流量 healthcheck: test: [CMD, curl, -f, http://localhost:7860/health] # 假设你的应用有健康检查接口 interval: 30s timeout: 10s retries: 3 start_period: 40s # 环境变量例如数据库连接地址指向主库 environment: - DATABASE_URLpostgresql://postgres:passwordpostgres-master:5432/mogface_db # 将容器内的模型缓存目录挂载出来避免每次重启重新下载如果需要 # volumes: # - ./model_cache:/root/.cache networks: - mogface-network # 依赖数据库主库先启动 depends_on: postgres-master: condition: service_healthy # 2. Nginx 负载均衡器 nginx: image: nginx:alpine container_name: nginx-lb ports: - 80:80 # 对外暴露80端口 volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro # 挂载自定义的Nginx配置 networks: - mogface-network depends_on: - mogface-webui # 3. PostgreSQL 主数据库 postgres-master: image: postgres:14-alpine container_name: postgres-master environment: - POSTGRES_DBmogface_db - POSTGRES_USERpostgres - POSTGRES_PASSWORDyour_strong_password_here - POSTGRES_INITDB_ARGS--encodingUTF-8 volumes: - postgres-master-data:/var/lib/postgresql/data - ./init-master.sh:/docker-entrypoint-initdb.d/init-master.sh # 初始化主从复制脚本 networks: - mogface-network healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 10s timeout: 5s retries: 5 # 4. PostgreSQL 从数据库 postgres-replica: image: postgres:14-alpine container_name: postgres-replica environment: - POSTGRES_DBmogface_db - POSTGRES_USERpostgres - POSTGRES_PASSWORDyour_strong_password_here volumes: - postgres-replica-data:/var/lib/postgresql/data - ./init-replica.sh:/docker-entrypoint-initdb.d/init-replica.sh # 初始化从库脚本 networks: - mogface-network depends_on: - postgres-master healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 10s timeout: 5s retries: 5 # 5. 可选Prometheus 监控 prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus-data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 networks: - mogface-network # 6. 可选Grafana 可视化 grafana: image: grafana/grafana-enterprise:latest container_name: grafana environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请修改 volumes: - grafana-data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning ports: - 3000:3000 networks: - mogface-network depends_on: - prometheus networks: mogface-network: driver: bridge volumes: postgres-master-data: postgres-replica-data: prometheus-data: grafana-data:关键点说明deploy: replicas: 3这行命令让Docker Compose启动3个完全相同的mogface-webui容器实例。healthcheck为每个服务定义了健康检查。Nginx只会将流量转发给通过健康检查的WebUI实例。depends_on定义了服务启动顺序确保数据库先就绪WebUI再启动。3.3 第三步配置Nginx负载均衡我们需要一个自定义的nginx.conf文件来配置负载均衡策略。将其放在与docker-compose.yml同级的目录。events { worker_connections 1024; } http { upstream mogface_backend { # 使用Docker Compose的服务名进行内部DNS解析 # 默认轮询策略也可以使用 ip_hash; 进行会话保持 server mogface-webui:7860; # 注意这里写一个地址即可Docker Compose会解析到所有健康的副本 # 但更佳实践是结合健康检查动态更新 upstream这里为简化演示。 # 生产环境建议使用Nginx Plus或结合consul-template动态生成配置。 } server { listen 80; server_name localhost; # 生产环境请替换为你的域名 location / { proxy_pass http://mogface_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 增加超时时间适应模型推理可能较慢的情况 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 300s; # 长推理任务需要更长的读超时 } # 可选添加一个状态页方便查看upstream状态 location /nginx_status { stub_status on; access_log off; allow 172.0.0.0/8; # 仅允许Docker内部网络访问 deny all; } } }3.4 第四步配置PostgreSQL主从复制这需要两个初始化脚本。init-master.sh在主库容器首次运行时执行创建复制用户。#!/bin/bash # init-master.sh set -e psql -v ON_ERROR_STOP1 --username $POSTGRES_USER --dbname $POSTGRES_DB -EOSQL CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD replicator_password; SELECT pg_create_physical_replication_slot(replication_slot); EOSQLinit-replica.sh在从库容器首次运行时执行从主库拉取数据并启动复制。#!/bin/bash # init-replica.sh set -e rm -rf /var/lib/postgresql/data/* pg_basebackup -h postgres-master -D /var/lib/postgresql/data -U replicator -v -P --wal-methodstream -R3.5 第五步启动与验证启动所有服务在包含docker-compose.yml的目录下运行。docker-compose up -d查看服务状态docker-compose ps你应该看到所有服务webui, nginx, postgres-master, postgres-replica等的状态都是Up。验证负载均衡访问http://你的服务器IP请求会被Nginx轮询转发到后端的3个WebUI实例之一。你可以查看不同WebUI容器的日志来验证。docker-compose logs -f mogface-webui验证数据库复制进入主库容器创建一张测试表然后在从库容器中查询应该能看到同步的数据。# 进入主库 docker-compose exec postgres-master psql -U postgres -d mogface_db # 在psql中执行 CREATE TABLE test_ha (id SERIAL PRIMARY KEY, message TEXT); INSERT INTO test_ha (message) VALUES (Hello from Master); # 退出然后进入从库 docker-compose exec postgres-replica psql -U postgres -d mogface_db # 在psql中执行 SELECT * FROM test_ha;4. 集成运维监控让系统状态一目了然服务跑起来只是第一步我们需要知道它跑得“好不好”。这就需要Prometheus和Grafana上场了。4.1 配置Prometheus抓取指标创建prometheus.yml配置文件告诉Prometheus去哪里抓数据。global: scrape_interval: 15s # 每15秒抓取一次 evaluation_interval: 15s scrape_configs: - job_name: mogface-webui static_configs: - targets: [mogface-webui:7860] # 你的WebUI需要暴露/metrics端点 labels: service: face-detection-api - job_name: nginx-exporter # 需要先部署nginx-exporter容器来暴露Nginx指标 static_configs: - targets: [nginx-exporter:9113] labels: service: nginx-lb - job_name: postgres-exporter # 需要先部署postgres-exporter容器来暴露PostgreSQL指标 static_configs: - targets: [postgres-exporter:9187] labels: service: postgres-db - job_name: node-exporter # 监控宿主机资源需要部署node-exporter static_configs: - targets: [node-exporter:9100] labels: service: host-metrics关键点你的MogFace WebUI应用需要集成Prometheus客户端库如Python的prometheus_client在代码中定义和暴露指标如请求次数http_requests_total、请求延迟http_request_duration_seconds、模型推理延迟model_inference_duration_seconds等并提供一个/metrics的HTTP端点。4.2 配置Grafana仪表盘与告警登录Grafana启动后访问http://你的服务器IP:3000用初始账号密码admin/admin123登录。添加数据源在Configuration - Data Sources中添加PrometheusURL填写http://prometheus:9090。导入仪表盘Grafana社区有大量现成的仪表盘模板。你可以搜索并导入针对Nginx、PostgreSQL、Node Exporter的仪表盘。对于自定义的MogFace指标你需要自己创建面板。设置告警规则在Grafana的Alerting模块中可以创建规则。例如规则1当“HTTP 5xx错误率”在5分钟内超过5%时触发警告。规则2当“平均请求延迟”超过1秒时触发警告。规则3当“容器内存使用率”超过90%时触发紧急告警。 告警通知可以配置到邮件、Slack、钉钉、企业微信等渠道。5. 总结与后续优化建议整套方案部署下来你会发现MogFace WebUI服务的韧性大大增强了。三个实例同时挂掉的概率极低数据库有备份任何组件出现问题监控系统都会第一时间通知你。这基本上能满足大多数中小型企业的生产环境需求。实际跑一段时间后你可能会根据业务情况做一些优化。比如把Docker Compose换成Kubernetes它能实现更优雅的滚动更新和自动伸缩HPA。再比如数据库主从切换可以做成自动的用Patroni之类的工具。还有对于模型文件这种大体积的静态数据可以考虑放到对象存储如MinIO或者网络文件系统NFS中让所有WebUI实例共享而不是打包进每个镜像。高可用架构不是一个一劳永逸的静态方案而是一个随着业务发展不断演进的动态过程。核心思想始终不变消除单点、冗余备份、实时监控、快速响应。希望这套基于MogFace的实战方案能为你构建稳定可靠的AI服务提供一条清晰的路径。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
MogFace人脸检测模型WebUI企业级部署：高可用架构与运维监控
MogFace人脸检测模型WebUI企业级部署高可用架构与运维监控最近和几个做安防、智慧园区项目的朋友聊天他们都在头疼同一个问题好不容易把一个人脸检测模型调教好了一到业务高峰期服务就变得不稳定要么响应慢要么直接挂掉。客户投诉、业务中断运维团队疲于奔命。这让我想起了之前我们团队部署MogFace WebUI服务时踩过的坑。MogFace本身是个很优秀的人脸检测模型精度和速度都不错但直接一个单点服务扔到生产环境风险太大了。今天我就结合我们实际的落地经验聊聊怎么给MogFace WebUI搭建一个能扛住压力、稳定运行的高可用生产级架构。这套方案的核心就是让服务像一支训练有素的军队有冗余、有调度、有监控确保7x24小时在线。1. 为什么企业级部署需要高可用你可能觉得一个WebUI服务能跑起来不就行了但在企业生产环境里这远远不够。想象一下一个智慧门禁系统在上下班高峰期如果人脸识别服务卡顿或宕机会造成人群拥堵一个线上认证服务如果在活动期间崩溃带来的直接就是用户流失和资损。我们之前就遇到过单节点部署的MogFace服务在并发请求稍高时CPU直接打满响应时间从几百毫秒飙升到几十秒最终进程OOM内存溢出崩溃。这就是典型的“单点故障”。高可用架构要解决的就是消除单点让服务具备弹性。简单来说企业级部署的目标有三个业务不中断任何单个服务器、容器甚至机房出现问题服务都能自动切换用户无感知。性能可扩展当用户量增长、请求变多时可以通过增加实例来分摊压力保持响应速度。状态可监控运维人员能实时掌握服务的健康状态、性能指标出了问题能快速定位和告警。接下来我们就围绕这三点一步步构建MogFace的高可用部署方案。2. 核心架构设计与组件选型我们的目标是搭建一个清晰、健壮、易于维护的架构。下面这张图描绘了整体的设计思路[用户] | v [负载均衡器 (Nginx)] --- 流量入口分发请求 | -------------------------------------- | | | v v v [WebUI实例1] [WebUI实例2] [WebUI实例3] --- 无状态服务横向扩展 (Docker) (Docker) (Docker) | | | -------------------------------------- | | v v [主数据库 (PostgreSQL)] [从数据库 (PostgreSQL)] --- 数据持久化主从同步 | | --------------------------------------- | v [监控系统 (Prometheus Grafana)] --- 收集指标可视化展示与告警组件解读与选型理由容器与编排Docker Docker Compose/KubernetesDocker将MogFace WebUI及其依赖Python环境、模型文件、库打包成标准镜像。这保证了环境一致性在任何地方部署的行为都一样。Docker Compose适合中小规模部署或快速原型验证。用一个YAML文件就能定义和运行多容器应用WebUI、数据库、Nginx等管理起来非常方便。Kubernetes (K8s)生产环境的“标准答案”。它能自动化地管理成百上千的容器负责服务的部署、伸缩、自愈和负载均衡。如果你的服务实例很多或者需要更高级的滚动更新、服务发现功能K8s是必选项。本文会以Docker Compose为例讲解核心概念K8s的部署YAML配置思路是相通的。负载均衡Nginx作为流量网关接收所有外部请求然后按照策略如轮询分发给后端的多个WebUI实例。这既实现了负载分担也隐藏了后端实例当某个实例故障时Nginx会自动将流量切到健康的实例上。数据库PostgreSQL with 主从复制MogFace WebUI可能需要记录识别日志、用户信息或任务状态。我们选用PostgreSQL并设置主从复制。主数据库处理所有写操作INSERT, UPDATE, DELETE。从数据库实时同步主库的数据主要用于读操作SELECT。这样读写分离既提升了读性能也从数据层面提供了冗余备份。主库宕机时可以手动或通过工具提升从库为主库更高级的方案可以用Patroni等工具实现自动故障转移。监控告警Prometheus GrafanaPrometheus负责“抓取”和“存储”各类指标数据。它会定期从Nginx、每个WebUI实例、数据库以及服务器节点本身拉取性能数据如QPS、延迟、CPU/内存使用率。Grafana负责“展示”和“告警”。它连接Prometheus将枯燥的数据变成直观的仪表盘。我们可以设置规则当某个指标异常如错误率超过5%时自动通过邮件、钉钉、企业微信等渠道发送告警。3. 分步部署实战理论讲完了我们动手把架构搭起来。这里我们使用Docker Compose来演示所有配置都写在一个docker-compose.yml文件里一目了然。3.1 第一步准备MogFace WebUI的Docker镜像首先我们需要一个包含MogFace模型和WebUI应用的Docker镜像。创建一个Dockerfile# 使用一个轻量级的Python基础镜像 FROM python:3.9-slim # 设置工作目录 WORKDIR /app # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 复制应用代码和模型文件 COPY . . # 下载或复制预训练的MogFace模型文件到指定目录例如 ./models/ # 假设模型文件已存在于构建上下文中 # COPY ./models/mogface_model.pth ./models/ # 暴露WebUI端口假设你的WebUI运行在7860端口类似Gradio EXPOSE 7860 # 启动命令 CMD [python, app.py]你的requirements.txt需要包含MogFace的依赖例如torch,torchvision,gradio,opencv-python等以及你的WebUI应用代码app.py。3.2 第二步编写高可用Docker Compose配置这是核心的docker-compose.yml文件。我们定义了四个服务WebUI、Nginx、PostgreSQL主库、PostgreSQL从库。version: 3.8 services: # 1. MogFace WebUI 应用服务启动3个实例 mogface-webui: build: . image: mogface-webui:latest container_name: mogface-webui # 部署3个副本 deploy: replicas: 3 # 配置健康检查确保只有健康的实例接收流量 healthcheck: test: [CMD, curl, -f, http://localhost:7860/health] # 假设你的应用有健康检查接口 interval: 30s timeout: 10s retries: 3 start_period: 40s # 环境变量例如数据库连接地址指向主库 environment: - DATABASE_URLpostgresql://postgres:passwordpostgres-master:5432/mogface_db # 将容器内的模型缓存目录挂载出来避免每次重启重新下载如果需要 # volumes: # - ./model_cache:/root/.cache networks: - mogface-network # 依赖数据库主库先启动 depends_on: postgres-master: condition: service_healthy # 2. Nginx 负载均衡器 nginx: image: nginx:alpine container_name: nginx-lb ports: - 80:80 # 对外暴露80端口 volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro # 挂载自定义的Nginx配置 networks: - mogface-network depends_on: - mogface-webui # 3. PostgreSQL 主数据库 postgres-master: image: postgres:14-alpine container_name: postgres-master environment: - POSTGRES_DBmogface_db - POSTGRES_USERpostgres - POSTGRES_PASSWORDyour_strong_password_here - POSTGRES_INITDB_ARGS--encodingUTF-8 volumes: - postgres-master-data:/var/lib/postgresql/data - ./init-master.sh:/docker-entrypoint-initdb.d/init-master.sh # 初始化主从复制脚本 networks: - mogface-network healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 10s timeout: 5s retries: 5 # 4. PostgreSQL 从数据库 postgres-replica: image: postgres:14-alpine container_name: postgres-replica environment: - POSTGRES_DBmogface_db - POSTGRES_USERpostgres - POSTGRES_PASSWORDyour_strong_password_here volumes: - postgres-replica-data:/var/lib/postgresql/data - ./init-replica.sh:/docker-entrypoint-initdb.d/init-replica.sh # 初始化从库脚本 networks: - mogface-network depends_on: - postgres-master healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 10s timeout: 5s retries: 5 # 5. 可选Prometheus 监控 prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus-data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 networks: - mogface-network # 6. 可选Grafana 可视化 grafana: image: grafana/grafana-enterprise:latest container_name: grafana environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请修改 volumes: - grafana-data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning ports: - 3000:3000 networks: - mogface-network depends_on: - prometheus networks: mogface-network: driver: bridge volumes: postgres-master-data: postgres-replica-data: prometheus-data: grafana-data:关键点说明deploy: replicas: 3这行命令让Docker Compose启动3个完全相同的mogface-webui容器实例。healthcheck为每个服务定义了健康检查。Nginx只会将流量转发给通过健康检查的WebUI实例。depends_on定义了服务启动顺序确保数据库先就绪WebUI再启动。3.3 第三步配置Nginx负载均衡我们需要一个自定义的nginx.conf文件来配置负载均衡策略。将其放在与docker-compose.yml同级的目录。events { worker_connections 1024; } http { upstream mogface_backend { # 使用Docker Compose的服务名进行内部DNS解析 # 默认轮询策略也可以使用 ip_hash; 进行会话保持 server mogface-webui:7860; # 注意这里写一个地址即可Docker Compose会解析到所有健康的副本 # 但更佳实践是结合健康检查动态更新 upstream这里为简化演示。 # 生产环境建议使用Nginx Plus或结合consul-template动态生成配置。 } server { listen 80; server_name localhost; # 生产环境请替换为你的域名 location / { proxy_pass http://mogface_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 增加超时时间适应模型推理可能较慢的情况 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 300s; # 长推理任务需要更长的读超时 } # 可选添加一个状态页方便查看upstream状态 location /nginx_status { stub_status on; access_log off; allow 172.0.0.0/8; # 仅允许Docker内部网络访问 deny all; } } }3.4 第四步配置PostgreSQL主从复制这需要两个初始化脚本。init-master.sh在主库容器首次运行时执行创建复制用户。#!/bin/bash # init-master.sh set -e psql -v ON_ERROR_STOP1 --username $POSTGRES_USER --dbname $POSTGRES_DB -EOSQL CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD replicator_password; SELECT pg_create_physical_replication_slot(replication_slot); EOSQLinit-replica.sh在从库容器首次运行时执行从主库拉取数据并启动复制。#!/bin/bash # init-replica.sh set -e rm -rf /var/lib/postgresql/data/* pg_basebackup -h postgres-master -D /var/lib/postgresql/data -U replicator -v -P --wal-methodstream -R3.5 第五步启动与验证启动所有服务在包含docker-compose.yml的目录下运行。docker-compose up -d查看服务状态docker-compose ps你应该看到所有服务webui, nginx, postgres-master, postgres-replica等的状态都是Up。验证负载均衡访问http://你的服务器IP请求会被Nginx轮询转发到后端的3个WebUI实例之一。你可以查看不同WebUI容器的日志来验证。docker-compose logs -f mogface-webui验证数据库复制进入主库容器创建一张测试表然后在从库容器中查询应该能看到同步的数据。# 进入主库 docker-compose exec postgres-master psql -U postgres -d mogface_db # 在psql中执行 CREATE TABLE test_ha (id SERIAL PRIMARY KEY, message TEXT); INSERT INTO test_ha (message) VALUES (Hello from Master); # 退出然后进入从库 docker-compose exec postgres-replica psql -U postgres -d mogface_db # 在psql中执行 SELECT * FROM test_ha;4. 集成运维监控让系统状态一目了然服务跑起来只是第一步我们需要知道它跑得“好不好”。这就需要Prometheus和Grafana上场了。4.1 配置Prometheus抓取指标创建prometheus.yml配置文件告诉Prometheus去哪里抓数据。global: scrape_interval: 15s # 每15秒抓取一次 evaluation_interval: 15s scrape_configs: - job_name: mogface-webui static_configs: - targets: [mogface-webui:7860] # 你的WebUI需要暴露/metrics端点 labels: service: face-detection-api - job_name: nginx-exporter # 需要先部署nginx-exporter容器来暴露Nginx指标 static_configs: - targets: [nginx-exporter:9113] labels: service: nginx-lb - job_name: postgres-exporter # 需要先部署postgres-exporter容器来暴露PostgreSQL指标 static_configs: - targets: [postgres-exporter:9187] labels: service: postgres-db - job_name: node-exporter # 监控宿主机资源需要部署node-exporter static_configs: - targets: [node-exporter:9100] labels: service: host-metrics关键点你的MogFace WebUI应用需要集成Prometheus客户端库如Python的prometheus_client在代码中定义和暴露指标如请求次数http_requests_total、请求延迟http_request_duration_seconds、模型推理延迟model_inference_duration_seconds等并提供一个/metrics的HTTP端点。4.2 配置Grafana仪表盘与告警登录Grafana启动后访问http://你的服务器IP:3000用初始账号密码admin/admin123登录。添加数据源在Configuration - Data Sources中添加PrometheusURL填写http://prometheus:9090。导入仪表盘Grafana社区有大量现成的仪表盘模板。你可以搜索并导入针对Nginx、PostgreSQL、Node Exporter的仪表盘。对于自定义的MogFace指标你需要自己创建面板。设置告警规则在Grafana的Alerting模块中可以创建规则。例如规则1当“HTTP 5xx错误率”在5分钟内超过5%时触发警告。规则2当“平均请求延迟”超过1秒时触发警告。规则3当“容器内存使用率”超过90%时触发紧急告警。 告警通知可以配置到邮件、Slack、钉钉、企业微信等渠道。5. 总结与后续优化建议整套方案部署下来你会发现MogFace WebUI服务的韧性大大增强了。三个实例同时挂掉的概率极低数据库有备份任何组件出现问题监控系统都会第一时间通知你。这基本上能满足大多数中小型企业的生产环境需求。实际跑一段时间后你可能会根据业务情况做一些优化。比如把Docker Compose换成Kubernetes它能实现更优雅的滚动更新和自动伸缩HPA。再比如数据库主从切换可以做成自动的用Patroni之类的工具。还有对于模型文件这种大体积的静态数据可以考虑放到对象存储如MinIO或者网络文件系统NFS中让所有WebUI实例共享而不是打包进每个镜像。高可用架构不是一个一劳永逸的静态方案而是一个随着业务发展不断演进的动态过程。核心思想始终不变消除单点、冗余备份、实时监控、快速响应。希望这套基于MogFace的实战方案能为你构建稳定可靠的AI服务提供一条清晰的路径。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
