# 丹阳公益婚恋服务平台 # V1.0 部署架构、运维监控、备份恢复与升级方案 > **⚠️ 已被取代（2026-09-18 头注）**：本文件为 V1.0 部署运维方案。V1.1 的部署与运维口径以 > `docs/OPS.md`（运维手册）、`infrastructure/`（compose / nginx / scripts，其中 `docker-compose.prod.yml` > 刻意不进版本控制）与 `docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md` 的 **Phase 22（Deployment / Ops）** > 为准。本文件保留原位，仅作为 V1.0 部署架构与历史决策的出处 —— 其中的**端口、主机名、目录结构可能已与现网不符**， > 不得作为实施依据。 > > 交接说明：`AGENTS.md` 的「文档」节未收录本文件；`docs/Phase-01-V11-Recovery-Completion-Report-2026-09-09.md` > 仍援引它作为 Phase 01 的核对对象（属历史记录，保留）。 版本：V1.0 适用范围：微信小程序后端、公益红娘工作台、运营管理后台、PostgreSQL、Redis、对象存储、WebSocket、日志与监控系统 核心目标：低成本、易部署、易维护、可备份、可恢复、可升级、故障可定位、后期可平滑扩容 --- # 第一章 部署设计目标 V1.0部署方案不追求复杂云原生架构。 当前项目更需要： > **少组件、低运维成本、可靠、容易备份、出现问题容易排查。** 因此V1优先： ```text Docker + Docker Compose + Nginx + 后端应用 + PostgreSQL + Redis + 对象存储 ``` 暂不引入： - Kubernetes - Service Mesh - Kafka - Elasticsearch - 分布式数据库 - 多地域复杂集群 - 大型日志平台 - 大型微服务体系 --- # 第二章 V1总体部署架构 推荐： ```text 微信小程序 │ │ HTTPS / WSS ↓ ┌───────────┐ │ Nginx │ └─────┬─────┘ │ ┌───────────┴───────────┐ │ │ ↓ ↓ Backend API Admin Web + WebSocket 静态资源 │ ┌──────┼───────────────┐ │ │ │ ↓ ↓ ↓ PostgreSQL Redis Object Storage │ ↓ Backup System ``` --- # 第三章 部署形态建议 V1优先采用： > **单区域部署。** 如果选择云服务器： 建议中国大陆节点。 核心业务数据： > 优先存储于中国大陆。 这样更适合： - 微信小程序访问 - 国内网络 - 用户隐私 - 后续合规管理 --- # 第四章 初期服务器数量 V1早期推荐： > 1台应用服务器 + 独立数据库/托管数据库。 或者低预算情况下： > 1台应用服务器 + 1台数据库服务器。 不建议： > 所有应用、数据库、备份全放同一个Docker宿主机。 因为宿主机故障后： > 全平台一起失效。 --- # 第五章 推荐初期架构A 低维护优先： ```text 云服务器A ├── Nginx ├── Backend ├── Admin Web └── Redis 云数据库 └── PostgreSQL 对象存储 └── 用户照片/聊天图片/活动图片 ``` 优点： - PostgreSQL少维护 - 云数据库自动备份较方便 - 应用服务器故障不影响数据库持久数据 --- # 第六章 推荐初期架构B 成本优先： ```text 服务器A ├── Nginx ├── Backend ├── Admin Web └── Redis 服务器B └── PostgreSQL ``` 对象存储： > 云对象存储。 适合： > 希望降低托管数据库费用，但有一定服务器维护能力。 --- # 第七章 不推荐架构 不建议： ```text 一台服务器 ├── Backend ├── PostgreSQL ├── Redis ├── 用户图片目录 ├── Backup └── 所有日志 ``` 因为： > 一块磁盘坏掉可能同时丢生产和备份。 --- # 第八章 Docker部署原则 所有核心应用统一： > Docker化。 包括： ```text backend nginx redis（如果自建） admin-web ``` PostgreSQL是否Docker： - 开发/Test可以 - 生产更推荐托管数据库或独立服务器 --- # 第九章 Docker镜像原则 镜像必须： - 可重复构建 - 固定版本 - 不使用latest生产部署 - 保留版本历史 例如： ```text matchmaking-backend:1.0.0 matchmaking-backend:1.0.1 ``` 禁止： ```text matchmaking-backend:latest ``` 作为唯一可追溯版本。 --- # 第十章 Docker Compose V1生产仍可以使用： ```text docker compose ``` 无需Kubernetes。 示例逻辑： ```yaml services: nginx: backend: redis: admin-web: ``` 数据库如果外部托管： > 不放Compose。 --- # 第十一章 推荐项目部署目录 服务器建议： ```text /opt/matchmaking/ ├── compose/ ├── env/ ├── nginx/ ├── scripts/ ├── logs/ ├── backups/ └── releases/ ``` --- # 第十二章 Releases目录 例如： ```text releases/ ├── 1.0.0/ ├── 1.0.1/ └── 1.1.0/ ``` 保留近期稳定版本。 --- # 第十三章 环境划分 正式至少： ```text dev test staging prod ``` --- # 第十四章 Dev环境 用途： > 开发。 允许： - Docker本地数据库 - 模拟实名认证 - 模拟短信 - 测试对象存储 --- # 第十五章 Test环境 用于： - CI - API测试 - 并发测试 - 自动化测试 数据： > 可随时重置。 --- # 第十六章 Staging 必须尽量接近Prod。 包括： - HTTPS - Nginx - Redis - PostgreSQL同主版本 - 对象存储权限策略 - WebSocket - Migration流程 --- # 第十七章 Production 严格： > 禁止使用测试Secret。 禁止： > Debug模式。 禁止： > 暴露数据库公网端口。 --- # 第十八章 配置管理 配置分为： ```text 业务配置 部署配置 Secret ``` --- # 第十九章 业务配置 例如： ```text dailyRecommendationLimit maxProfilePhotos activityEnabled matchmakerEnabled ``` 由： > system_configs 管理。 --- # 第二十章 部署配置 例如： ```text PORT DATABASE_HOST REDIS_HOST OBJECT_STORAGE_ENDPOINT LOG_LEVEL ``` 通过环境变量。 --- # 第二十一章 Secret 例如： ```text DATABASE_PASSWORD JWT_SECRET WECHAT_SECRET REAL_NAME_PROVIDER_SECRET OBJECT_STORAGE_SECRET ``` 禁止写入： - Git - Dockerfile - 前端代码 - README示例真实值 --- # 第二十二章 .env管理 开发： ```text .env.example ``` 只提供键名。 生产： > 实际.env不提交Git。 权限： ```text chmod 600 ``` 或使用云Secret服务。 --- # 第二十三章 Nginx职责 Nginx负责： ```text HTTPS 反向代理 静态后台资源 WebSocket代理 基础安全Header 请求体大小限制 访问日志 ``` --- # 第二十四章 域名结构建议 例如： ```text api.example.com admin.example.com ``` 小程序： ```text api.example.com ``` 后台： ```text admin.example.com ``` --- # 第二十五章 API路径 ```text https://api.example.com/api/v1/ ``` WebSocket： ```text wss://api.example.com/ws ``` --- # 第二十六章 HTTPS 生产必须： > TLS。 HTTP： > 自动301跳HTTPS。 --- # 第二十七章 TLS证书 建议： - 自动续期 - 到期监控 避免： > 证书过期导致微信小程序整体不可访问。 --- # 第二十八章 Nginx上传大小 根据业务配置。 例如： ```text client_max_body_size 12M ``` 与图片上传限制一致。 --- # 第二十九章 WebSocket代理 必须配置： ```text Upgrade Connection ``` 确保长期连接正常。 --- # 第三十章 API超时 普通API： > 不宜设置过长。 例如： ```text proxy_read_timeout 30s ``` 推荐服务也应在合理时间内返回。 不能靠： > 5分钟HTTP超时 掩盖慢SQL。 --- # 第三十一章 WebSocket超时 WebSocket需要单独配置更长连接策略。 配合： > 应用心跳。 --- # 第三十二章 后端实例 V1初期： ```text backend x1 ``` 足够。 架构必须保证后续： ```text backend x2 ``` 容易扩展。 --- # 第三十三章 无状态设计 Backend尽量无状态。 Session： > Redis/数据库。 用户图片： > Object Storage。 不能存在： ```text /app/uploads/user1.jpg ``` 作为正式生产唯一文件。 否则多实例后无法共享。 --- # 第三十四章 后端扩容 当单实例不足： ```text Nginx ├── backend-1 └── backend-2 ``` 即可。 --- # 第三十五章 多实例WebSocket 未来： ```text backend-1 backend-2 ``` 需要： > Redis Pub/Sub或等效机制 进行跨实例实时推送。 V1单实例时可以简化。 --- # 第三十六章 PostgreSQL定位 PostgreSQL是： > 核心业务事实数据源。 保存： - 用户 - 认证状态 - 资料 - Match - Conversation - Message - Activity - Matchmaker - Risk - Audit --- # 第三十七章 PostgreSQL生产原则 必须： - 独立账号 - 强密码 - 禁止公网开放 - 定期备份 - 监控连接数 - 监控磁盘 - 执行Migration管理 --- # 第三十八章 数据库账号建议 至少： ```text app_user migration_user backup_user ``` --- # 第三十九章 app_user 仅拥有： > 应用需要的CRUD。 不要： > SUPERUSER。 --- # 第四十章 migration_user 用于： > 数据库结构升级。 权限较高。 正常应用不使用。 --- # 第四十一章 backup_user 只拥有： > 必要读取/备份权限。 --- # 第四十二章 数据库连接池 必须限制： > 最大连接数。 不能每个API请求开新连接。 连接池大小根据服务器配置和数据库容量设置。 不要盲目设： ```text 500 ``` --- # 第四十三章 慢SQL监控 建议记录： > 超过指定时间的SQL。 例如： ```text > 500ms ``` 作为初始告警参考。 具体阈值可调整。 --- # 第四十四章 数据库关键监控 至少： ```text CPU Memory Disk Connections Slow Queries Locks Replication（若未来启用） Backup Status ``` --- # 第四十五章 数据库磁盘告警 建议： ```text 70% warning 85% critical ``` 数值可根据环境调整。 关键是： > 提前告警。 --- # 第四十六章 Redis定位 Redis只做： - Cache - Session - Rate Limit - WebSocket在线状态 - 临时未读优化 - 分布式锁/短锁（必要） Redis不是核心事实数据源。 --- # 第四十七章 Redis丢失原则 即使Redis全部清空： > 平台核心业务数据不能永久丢失。 最多： - 缓存重建 - 用户重新登录 - 推荐重新计算 - 未读重新统计 --- # 第四十八章 Redis生产安全 必须： - 非公网 - 密码/ACL - 网络隔离 - 最大内存 - 淘汰策略 --- # 第四十九章 Redis持久化 如果Redis用于： > 重要Session 可以开启合理持久化。 但仍不能把： > Match/Message 只放Redis。 --- # 第五十章 对象存储 存： ```text 用户头像 生活照片 聊天图片 活动图片 举报证据 ``` --- # 第五十一章 Bucket划分建议 可以： ```text profile-private chat-private activity-assets risk-evidence-private ``` 或者一个Private Bucket按Prefix隔离。 --- # 第五十二章 对象存储默认Private 必须： ```text Public Access = Off ``` --- # 第五十三章 用户访问图片 流程： ```text 客户端请求 ↓ 业务权限校验 ↓ Backend生成短时Signed URL ↓ 客户端访问对象存储 ``` --- # 第五十四章 Signed URL 有效时间： > 短时。 例如数分钟。 具体按使用体验配置。 --- # 第五十五章 风控证据Bucket 建议更加严格： - 更短Signed URL - 专门权限 - 访问审计 --- # 第五十六章 对象存储生命周期 临时上传： ```text tmp/ ``` 未绑定业务： > 自动清理。 --- # 第五十七章 图片正式文件 按业务类型分类Prefix： ```text profiles/{userId}/ chat/{conversationId}/ activities/{activityId}/ reports/{reportId}/ ``` --- # 第五十八章 日志体系 V1至少分： ```text application.log access.log security.log audit（数据库） ``` --- # 第五十九章 Application Log 记录： - Service异常 - 第三方错误 - 系统异常 - 任务执行结果 --- # 第六十章 Access Log Nginx/API： ```text requestId method path status latency clientIp userAgent ``` --- # 第六十一章 Security Log 例如： ```text 后台登录失败 大量Rate Limit 异常Token 权限越权 可疑上传 ``` --- # 第六十二章 Audit 正式业务审计： > 存数据库。 不能只存在日志文件。 --- # 第六十三章 日志统一RequestId 从Nginx开始： ```text RequestId ``` 贯穿： ```text Nginx → Backend → Service → Error Log ``` 方便故障排查。 --- # 第六十四章 日志格式 推荐结构化JSON。 例如： ```json { "level": "ERROR", "requestId": "req_xxx", "service": "match", "code": "MATCH_CREATE_FAILED" } ``` --- # 第六十五章 禁止日志内容 严禁： ```text 身份证全文 完整手机号 AccessToken RefreshToken 密码 聊天正文 举报完整证据 对象存储Secret ``` --- # 第六十六章 日志保留 具体期限： > 根据数据安全政策确定。 建议： - 普通应用日志短期 - Security Log较长期 - Audit按照审计要求长期管理 不要无差别永久保存所有日志。 --- # 第六十七章 日志轮转 必须： > Log Rotation。 防止日志占满磁盘。 例如： - 按天 - 按大小 - 保留指定天数 - 自动压缩 --- # 第六十八章 监控总体结构 V1建议： ```text 基础设施监控 + 应用监控 + 业务监控 + 安全监控 ``` --- # 第六十九章 基础设施监控 监控： ```text CPU Memory Disk Network Container PostgreSQL Redis ``` --- # 第七十章 应用监控 监控： ```text QPS P95 5xx 4xx 线程/事件循环状态 DB连接池 外部API WebSocket ``` --- # 第七十一章 业务监控 重点： ```text 登录成功率 实名认证失败率 待审核数量 推荐失败 Match创建异常 Message失败 Activity报名失败 Report积压 ``` --- # 第七十二章 安全监控 重点： ```text 后台连续登录失败 大量401/403 Rate Limit异常 敏感数据访问 高风险操作 权限修改 ``` --- # 第七十三章 监控工具原则 V1不要求昂贵商业APM。 可采用： > Prometheus + Grafana 或云厂商原生监控。 如果采用云平台： 优先选择： > 少维护方案。 --- # 第七十四章 是否必须自建Prometheus 不是。 如果云厂商： - 主机监控 - 数据库监控 - 日志告警 已经足够： > V1可先使用云监控。 目标是： > 能发现问题。 不是为了建设监控平台。 --- # 第七十五章 最低必须监控项 上线前必须有： ```text 服务器CPU 服务器内存 服务器磁盘 Backend存活 HTTP 5xx PostgreSQL Redis 数据库备份结果 HTTPS证书到期 ``` --- # 第七十六章 Health Check 建议： ```text /health/live /health/ready ``` --- # 第七十七章 Live 判断： > 应用进程是否活着。 不能把所有第三方都放Live。 否则第三方短信挂了： > 容器被不断重启。 --- # 第七十八章 Ready 判断： > 是否能正常提供核心服务。 可以检查： - PostgreSQL - 必要Redis连接 --- # 第七十九章 第三方健康 实名认证、微信等： > 单独监控。 不要作为应用存活唯一依据。 --- # 第八十章 告警渠道 至少： - 手机 - 企业微信/微信工作群 - 邮件（可选） 关键事故： > 不能只发到没人看的监控页面。 --- # 第八十一章 告警分级 建议： ```text P1 紧急 P2 重要 P3 提醒 ``` --- # 第八十二章 P1告警 例如： ```text 生产API整体不可用 PostgreSQL不可用 磁盘接近满 大量500 权限绕过事件 备份连续失败 ``` --- # 第八十三章 P2告警 例如： ```text 推荐失败率异常 WebSocket连接失败率高 实名认证错误率高 活动报名异常 ``` --- # 第八十四章 P3 例如： - 某异步任务一次失败 - 日志增量异常 - 非核心第三方短暂失败 --- # 第八十五章 告警防噪音 不要： > CPU瞬间80%就每分钟报警。 使用： - 持续时间 - 连续次数 - 恢复通知 避免告警疲劳。 --- # 第八十六章 生产Dashboard 运维Dashboard重点： ```text API availability P95 latency Error Rate DB Health Redis Health Disk WebSocket connections External service status ``` --- # 第八十七章 备份总体原则 必须保证： > **生产数据损坏后可以恢复。** 不是： > “我们每天有一个backup.zip”。 真正要求： ```text 有备份 + 备份可读取 + 备份异地 + 实际恢复验证 ``` --- # 第八十八章 数据库备份 建议： ```text 每日全量备份 + 数据库服务自身时间点恢复能力（如果使用托管数据库） ``` --- # 第八十九章 自建PostgreSQL 至少： > 每日逻辑/物理备份。 更可靠方案： > WAL归档 + 全量备份。 V1具体方案根据部署预算决定。 --- # 第九十章 托管数据库 优先利用： - 自动备份 - 时间点恢复 - 跨可用区备份（如适用） 但仍需： > 验证恢复操作。 --- # 第九十一章 备份保留策略建议 例如： ```text 每日备份：7～14份 每周备份：4～8份 每月备份：若干 ``` 具体期限结合： - 成本 - 合规 - 风险 最终确定。 不是业务硬编码。 --- # 第九十二章 备份不要只在原机器 错误： ```text PostgreSQL 和 backup.sql 都在同一磁盘 ``` 宿主机坏了： > 两个一起没。 --- # 第九十三章 异地/异介质备份 至少： > 备份复制到不同存储位置。 例如： ```text 云数据库 + 对象存储Backup Bucket ``` --- # 第九十四章 备份加密 备份中可能含： > 高敏感数据。 因此： - 存储加密 - 访问控制 - 密钥保护 --- # 第九十五章 Backup Bucket 必须： > Private。 只有备份角色可访问。 --- # 第九十六章 备份账号 不使用： > super admin通用云账号。 使用： > 独立Backup权限。 --- # 第九十七章 Redis备份 Redis数据可重建。 因此Redis备份优先级低于PostgreSQL。 若存Session等： > 可保留合理快照。 但恢复生产最核心的是： > PostgreSQL。 --- # 第九十八章 对象存储备份 用户图片本身也是重要数据。 建议： - Bucket版本控制（如果成本允许） - 生命周期 - 跨存储备份/冗余 至少确保： > 数据库恢复后不会出现所有图片都找不到。 --- # 第九十九章 对象删除策略 业务删除： > 先soft delete/状态标记。 对象存储真正物理删除： > 经过延迟清理任务。 避免用户误操作后立刻不可恢复。 --- # 第一百章 删除延迟 例如： > 7～30天后物理清理。 具体根据数据保留政策确定。 安全举报证据等： > 按独立保留策略处理。 --- # 第一百零一章 数据库恢复目标 建议定义： ```text RPO RTO ``` --- # 第一百零二章 RPO Recovery Point Objective： > 最多能接受丢多久的数据。 V1建议目标： > 尽量控制在小时级或更好。 若使用托管数据库PITR： > 可显著降低RPO。 --- # 第一百零三章 RTO Recovery Time Objective： > 故障后多久恢复服务。 V1建议： > 数小时内恢复核心服务。 不追求金融级秒级容灾。 --- # 第一百零四章 RPO/RTO属于建议目标 最终根据： - 云服务 - 预算 - 活跃用户规模 正式确定。 不要写入代码。 --- # 第一百零五章 恢复演练 至少： > 每季度/半年实际恢复一次测试数据库。 早期可以： > 每次大版本上线前至少一次。 --- # 第一百零六章 恢复测试流程 ```text 下载备份 ↓ 新建隔离数据库 ↓ Restore ↓ 运行Migration校验 ↓ 执行数据一致性检查 ↓ 抽查用户/Match/Message/Activity ↓ 记录结果 ``` --- # 第一百零七章 恢复检查 至少： ```text users count matches count messages count activities count reports count audit logs ``` 并检查外键关系。 --- # 第一百零八章 恢复演练记录 记录： ```text backupTime restoreTime duration result errors operator ``` --- # 第一百零九章 配置备份 不仅数据库。 还需要备份： ```text Nginx配置 Docker Compose Migration脚本 系统公开配置 监控规则 部署脚本 ``` 这些本身应在： > Git版本管理。 --- # 第一百一十章 Secret备份 Secret不能丢。 但不能放普通Git。 应使用： - Secret Manager - 加密离线备份 --- # 第一百一十一章 灾难恢复优先顺序 ```text 1 PostgreSQL 2 Backend 3 Auth 4 核心用户/Match 5 Chat 6 Object Storage 7 Redis Cache 8 Analytics ``` 核心服务优先。 统计可以最后恢复。 --- # 第一百一十二章 Redis全部丢失恢复 流程： ```text 启动新Redis ↓ Session可能失效 ↓ 用户重新登录 ↓ 缓存自然重建 ``` 核心Match不会丢。 --- # 第一百一十三章 应用服务器损坏 如果镜像和配置都在版本库/镜像仓库： ```text 新服务器 ↓ Docker ↓ 部署Compose ↓ 配置Secret ↓ 启动 ↓ Nginx/域名切换 ``` 即可。 --- # 第一百一十四章 应用服务器不能成为“手工艺术品” 禁止： > 开发人员SSH进去改了一堆东西但没有记录。 所有正式变更： > 进入部署脚本、Compose或配置仓库。 --- # 第一百一十五章 Infrastructure Documentation 至少记录： ```text 服务器 域名 证书 数据库 Redis 对象存储 备份位置 监控入口 关键联系人 ``` 但Secret单独管理。 --- # 第一百一十六章 Release流程 建议： ```text 开发完成 ↓ CI ↓ Test ↓ Build Image ↓ Staging ↓ Migration ↓ E2E ↓ RC ↓ Production ↓ Smoke ↓ 监控 ``` --- # 第一百一十七章 Production发布不在服务器编译 禁止： ```text git pull npm install mvn package ``` 直接生产机器现场编译。 应该： ```text CI构建 ↓ 生成镜像 ↓ 生产只拉镜像 ``` --- # 第一百一十八章 镜像仓库 使用： > 国内访问稳定的Container Registry。 保存： ```text 1.0.0 1.0.1 ``` --- # 第一百一十九章 CI输出 每次Release至少生成： ```text backend image admin build migration package release notes ``` --- # 第一百二十章 Version 后端提供： ```text /version ``` 或健康接口返回： ```json { "version": "1.0.0", "commit": "abc123" } ``` 方便确认当前服务器版本。 --- # 第一百二十一章 数据库Migration 必须使用： > 正式Migration工具。 例如具体框架对应： - Flyway - Liquibase - Prisma Migration - TypeORM migration 根据最终技术栈选择。 禁止： > 生产手工改表后不记录。 --- # 第一百二十二章 Migration版本 例如： ```text V001__initial_schema V002__activity_interest V003__add_match_rule_version ``` --- # 第一百二十三章 Migration原则 必须： - 可重复部署环境 - 可审核 - Staging先跑 - 生产前备份 - 记录执行结果 --- # 第一百二十四章 大表Migration 未来数据量大时： 避免： > 一次长时间锁表。 V1早期数据量小问题有限。 但仍建立正确习惯。 --- # 第一百二十五章 向后兼容Migration 推荐： ### 第一步 增加字段。 ### 第二步 新旧代码兼容。 ### 第三步 数据迁移。 ### 第四步 后续版本再清旧字段。 --- # 第一百二十六章 不建议Release中直接DROP重要字段 因为回滚应用后： > 旧版本可能无法运行。 --- # 第一百二十七章 发布策略V1 推荐： > Rolling/短停机发布。 单实例情况下： 可以短暂： > 维护模式。 --- # 第一百二十八章 单实例发布 流程： ```text 开启维护模式（需要时） ↓ 备份 ↓ Migration ↓ 启动新版本 ↓ 健康检查 ↓ Smoke Test ↓ 关闭维护模式 ``` --- # 第一百二十九章 是否必须零停机 V1： > 不必须。 宁愿： > 几分钟明确维护窗口 也不要为了“零停机”引入复杂双活系统。 --- # 第一百三十章 维护页 用户看到： > 系统正在进行短暂维护，请稍后再试。 不要： > 502 Bad Gateway。 --- # 第一百三十一章 后台维护 管理员提前知道： > 维护时间。 避免活动现场突然升级。 --- # 第一百三十二章 发布避开关键活动 正式部署不要安排在： - 大型公益相亲活动签到前 - 活动进行中 - 大规模推广刚开始 优先低峰期。 --- # 第一百三十三章 灰度发布 如果未来多实例： ```text backend-1 old backend-2 new ``` 可先少量流量到new。 V1初期不强制。 --- # 第一百三十四章 Feature Flag灰度 当前更实用： ```text activityEnabled imageChatEnabled matchmakerEnabled ``` 可以单独开关。 --- # 第一百三十五章 新功能上线方式 例如图片聊天： ```text 代码已部署 ↓ Flag=false ↓ 内部测试 ↓ Flag=true ``` 降低风险。 --- # 第一百三十六章 数据结构和Feature Flag 注意： > 数据库Migration必须先完成。 不能Flag一开： > 表还不存在。 --- # 第一百三十七章 Rollback原则 如果上线后出现严重问题： > 应能快速回到上一稳定应用版本。 --- # 第一百三十八章 Rollback前提 数据库Migration必须考虑： > 旧版本是否仍兼容。 --- # 第一百三十九章 应用回滚 例如： ```text 1.0.1有Bug ↓ 切回1.0.0 image ↓ Restart ``` --- # 第一百四十章 数据库回滚 不建议： > 自动Down Migration生产数据库。 更安全： - 应用向后兼容 - 必要时修复Forward Migration 除非明确验证。 --- # 第一百四十一章 为什么数据库回滚更危险 生产已产生新数据。 简单： ```text DROP COLUMN ``` 可能直接丢数据。 因此： > 应用回滚简单，数据库回滚谨慎。 --- # 第一百四十二章 Hotfix流程 严重线上Bug： ```text 建立hotfix branch ↓ 最小修复 ↓ 自动测试 ↓ Staging验证 ↓ 生成1.0.1 ↓ 上线 ``` 不能： > SSH服务器现场改代码。 --- # 第一百四十三章 Release Notes 每个版本： ```text 新增 修复 数据库变更 配置变更 已知问题 回滚注意事项 ``` --- # 第一百四十四章 运维日常SOP 每天： ```text 检查P1告警 检查备份 检查磁盘 查看严重错误 ``` --- # 第一百四十五章 每周 ```text 检查错误趋势 检查慢SQL 检查Redis 检查高风险安全日志 检查后台异常登录 ``` --- # 第一百四十六章 每月 ```text 检查资源容量 检查证书 检查数据库增长 检查对象存储增长 检查备份容量 检查权限和离职账号 ``` --- # 第一百四十七章 每季度 ```text 恢复演练 权限复核 安全补丁 依赖升级评估 灾备检查 ``` --- # 第一百四十八章 容量监控 必须关注： ```text 用户数 照片量 消息量 数据库大小 对象存储大小 Redis内存 日志大小 ``` --- # 第一百四十九章 容量增长预警 例如数据库： > 预计30天后超过磁盘80%。 应该： > 提前扩容。 不是等磁盘100%再处理。 --- # 第一百五十章 对象存储成本 聊天图片和生活照片可能成为主要存储增长。 建议统计： ```text daily upload volume total storage ``` --- # 第一百五十一章 图片压缩 正式上传后： > 后端/图片服务压缩。 减少： - 网络 - 存储 - CDN成本 --- # 第一百五十二章 是否需要CDN V1用户集中丹阳/江苏。 如果对象存储已有加速能力： > 可直接使用。 用户量上升后： > 再评估CDN。 --- # 第一百五十三章 用户头像缓存 Signed URL虽然短时： 前端仍可： > 本地短期缓存。 减少重复下载。 --- # 第一百五十四章 CDN不能破坏隐私 如果使用CDN： > 私有内容仍需要鉴权/签名。 不能因为加CDN： > 变成Public Bucket。 --- # 第一百五十五章 数据库扩容时机 出现： - CPU长期高 - Connection接近上限 - 慢SQL明显 - 磁盘压力 先优化： > SQL和索引。 再升级： > 数据库规格。 --- # 第一百五十六章 不要一有性能问题就分库 V1单PostgreSQL足够。 优先： ```text 索引 查询优化 缓存 分页 资源升级 ``` --- # 第一百五十七章 Redis扩容 主要根据： > 内存。 缓存应设置TTL。 避免： > 永不失效无限增长。 --- # 第一百五十八章 WebSocket容量 监控： ```text 在线连接 连接创建率 断线率 消息推送失败 ``` 达到单实例瓶颈后： > 横向扩Backend。 --- # 第一百五十九章 推荐任务容量 如果实时推荐开始变慢： 第一阶段： > Redis缓存。 第二阶段： > 预计算。 仍无需立即引入推荐大数据平台。 --- # 第一百六十章 Analytics容量 统计变慢： 先使用： > Daily Summary。 不要让Dashboard每次扫描messages全表。 --- # 第一百六十一章 Maintenance Jobs 建议至少： ```text 通知重试 临时文件清理 活动状态更新 推荐缓存清理 审核超时提醒 红娘超时提醒 统计日汇总 风险状态重算 ``` --- # 第一百六十二章 Job执行机制 V1可以： > 后端内置Scheduler。 不需要单独任务平台。 --- # 第一百六十三章 Scheduler多实例问题 未来Backend多实例： 必须避免： > 同一个任务两台都跑。 可采用： - Redis Lock - DB Lock - Scheduler Leader --- # 第一百六十四章 Job必须幂等 例如Daily Analytics： 执行两次： > 结果相同。 --- # 第一百六十五章 Job监控 记录： ```text jobName startedAt finishedAt status error ``` 重要任务失败： > 告警。 --- # 第一百六十六章 临时文件清理Job 清理： - 未绑定上传 - 过期临时文件 不能误删： > 正式Profile/Chat/Risk文件。 --- # 第一百六十七章 Notification Retry 失败： > 重试有限次数。 不能： > 无限重试造成任务堆积。 --- # 第一百六十八章 第三方服务监控 至少： ```text 微信登录 实名认证 对象存储 短信（如启用） ``` --- # 第一百六十九章 第三方错误隔离 实名认证失败： > 不应影响用户查看帮助页。 对象存储失败： > 不应导致整个API死亡。 --- # 第一百七十章 Circuit Breaker V1不一定需要引入复杂框架。 但第三方调用应： - 超时 - 有限重试 - 快速失败 不能一个实名认证API卡30秒拖死线程池。 --- # 第一百七十一章 Third-party Timeout 建议： > 秒级合理超时。 具体根据供应商SLA。 --- # 第一百七十二章 Retry 只对： > 明确可重试错误。 不要实名认证提交失败就无限重试。 避免重复请求和费用。 --- # 第一百七十三章 外部Provider适配层 建议： ```text WechatAdapter IdentityVerificationProvider SmsProvider ObjectStorageProvider ``` 避免Service直接写供应商SDK。 后续更换服务商更容易。 --- # 第一百七十四章 Provider配置 后台不要直接暴露Secret。 使用部署配置。 运营后台最多看到： ```text 实名认证服务：正常 ``` --- # 第一百七十五章 微信小程序发布 小程序前端发布流程： ```text 开发版本 ↓ 体验版 ↓ 业务验收 ↓ 提交审核 ↓ 正式发布 ``` --- # 第一百七十六章 小程序API兼容 由于小程序审核和后端发布时间可能不同： > API必须保持一定向后兼容。 不能后端一升级： > 旧小程序立即全部坏。 --- # 第一百七十七章 API兼容策略 V1： ```text /api/v1 ``` 增加字段： > 兼容。 删除/重命名字段： > 谨慎。 重大破坏： > `/api/v2` --- # 第一百七十八章 小程序最低版本控制 可以在： ```text /app/config ``` 返回： ```text minimumSupportedVersion latestVersion ``` --- # 第一百七十九章 强制升级 微信小程序升级机制不同于APP。 可以提示： > 当前版本过旧，请重新打开小程序获取最新版本。 但不要频繁使用。 --- # 第一百八十章 后台前端升级 Admin Web是静态资源。 发布后： > 刷新获取新版本。 需要注意浏览器缓存。 --- # 第一百八十一章 Static Assets 文件名使用Hash： ```text app.a87f91.js ``` 避免老缓存。 --- # 第一百八十二章 后台版本不一致 前端可以在API发现： ```text CLIENT_VERSION_TOO_OLD ``` 提示刷新。 --- # 第一百八十三章 安全补丁升级 依赖包定期检查： - 后端Framework - Node依赖 - Nginx - PostgreSQL - Redis - Docker --- # 第一百八十四章 不自动升级生产主版本 例如： > 数据库大版本。 必须： ```text 评估 ↓ 测试 ↓ 备份 ↓ Staging ↓ 生产维护窗口 ``` --- # 第一百八十五章 小版本安全补丁 仍应： > 先Test/Staging。 不要生产服务器自动apt upgrade所有软件。 --- # 第一百八十六章 Dependency Lock 必须有： - package-lock - pnpm-lock - Maven/Gradle固定依赖 保证构建可重复。 --- # 第一百八十七章 镜像基础版本 不要长期： ```text node:latest ``` 固定： > 主版本/明确镜像Tag。 --- # 第一百八十八章 容器运行安全 建议： - 非root运行 - 只读文件系统（可行处） - 最小权限 - 不挂Docker Socket - 不把Secret写镜像 --- # 第一百八十九章 防火墙 公网只开放： ```text 80 443 ``` SSH： > 仅管理IP/VPN。 PostgreSQL： > 不公网。 Redis： > 不公网。 --- # 第一百九十章 SSH管理 建议： - SSH Key - 禁止密码登录（条件允许） - 不允许root直接登录 - 管理IP限制 --- # 第一百九十一章 管理员系统和服务器权限分离 后台platform_admin： > 不等于服务器root。 运营人员不需要SSH权限。 --- # 第一百九十二章 云账号权限 采用： > 最小权限。 开发人员： > 不自动拥有生产云账号Owner。 --- # 第一百九十三章 生产变更权限 建议： - 技术负责人 - 指定运维 执行。 重要变更： > 留记录。 --- # 第一百九十四章 域名与证书管理 必须记录： ```text 域名注册商 证书 负责人 到期时间 ``` 域名过期是非常常见但严重的事故。 --- # 第一百九十五章 证书到期告警 建议提前： ```text 30天 15天 7天 ``` 提醒。 --- # 第一百九十六章 数据库密码轮换 人员变化或怀疑泄露： > 立即轮换。 定期轮换频率根据安全政策。 --- # 第一百九十七章 API Secret轮换 Provider Adapter应支持： > 新旧Secret短期切换。 减少停机。 --- # 第一百九十八章 JWT/Token Key轮换 设计： > key version/kid。 未来可以平滑轮换。 V1如果实现简单，也至少保留替换能力。 --- # 第一百九十九章 生产故障分级 建议： ```text SEV1 SEV2 SEV3 ``` --- # 第二百章 SEV1 例如： ```text 全站不可用 数据库损坏 大规模数据泄露 严重权限绕过 Match大量错误生成 ``` --- # 第二百零一章 SEV1处置流程 ```text 发现 ↓ 停止扩大影响 ↓ 必要时维护模式/Feature Flag ↓ 保护数据 ↓ 定位 ↓ 修复/回滚 ↓ 恢复 ↓ 验证 ↓ 事故复盘 ``` --- # 第二百零二章 SEV2 例如： - 聊天不可用 - 推荐不可用 - 活动报名异常 - 实名第三方异常 核心平台部分可用。 --- # 第二百零三章 SEV3 例如： - 某统计延迟 - 非核心通知失败 - 局部后台页面Bug --- # 第二百零四章 故障第一原则 > **先停止错误扩散，再追求恢复功能。** 例如Match逻辑错： > 先关闭Like。 不要继续生成错误关系。 --- # 第二百零五章 数据事故 如果发现数据写错： > 禁止直接批量手改。 先： - 备份 - 确认影响范围 - Dry Run修复脚本 - 执行 - 验证 --- # 第二百零六章 故障Runbook 建议至少建立： ```text API全挂 数据库不可连接 Redis故障 对象存储故障 微信登录异常 实名认证异常 磁盘满 证书过期 Match异常 消息异常 权限事故 ``` --- # 第二百零七章 Runbook格式 每个包含： ```text 症状 检查步骤 临时措施 恢复方法 升级联系人 验证方式 ``` --- # 第二百零八章 数据库故障Runbook 示例： ```text 1 检查数据库状态 2 检查连接数 3 检查磁盘 4 检查慢查询/锁 5 必要时只读/维护 6 恢复或切换 7 核心数据校验 ``` --- # 第二百零九章 Redis故障Runbook ```text 1 判断是否核心业务受影响 2 Restart/替换Redis 3 Session影响评估 4 清缓存 5 用户重新登录 6 检查推荐/未读恢复 ``` --- # 第二百一十章 Object Storage故障 降级： - 文字功能保留 - 暂停图片上传 - 已有图片暂时显示失败占位 不需要： > 全平台维护。 --- # 第二百一十一章 微信服务异常 提示： > 微信服务暂时异常，请稍后重试。 记录Provider错误。 --- # 第二百一十二章 实名服务故障 可以： > 暂停新实名认证。 已有已实名用户： > 正常使用。 --- # 第二百一十三章 风控系统故障 核心权限： - Block - AccountStatus 仍必须工作。 辅助关键词检测异常： > 可降级。 --- # 第二百一十四章 统计系统故障 Analytics失败： > 不影响用户Match/Chat。 Dashboard提示： > 数据暂时无法更新。 --- # 第二百一十五章 事故复盘 SEV1/重要SEV2后必须形成： ```text 发生什么 为什么 影响谁 为什么监控没提前发现 怎么修 怎么防止再次发生 ``` --- # 第二百一十六章 复盘不是追责会议 目标： > 改系统和流程。 例如： “开发操作失误” 不是根因。 应继续问： > 为什么一个人的失误能够直接影响生产？ --- # 第二百一十七章 版本升级节奏 V1稳定后： 建议： ```text Patch 按需 Minor 按业务周期 Major 谨慎 ``` 不要： > 每天生产升级核心结构。 --- # 第二百一十八章 高频小版本 如果团队初期快速迭代： 可以： > 每周固定窗口。 比随时上线更可控。 --- # 第二百一十九章 大型活动冻结期 活动前： > 24～48小时建议冻结高风险大改动。 只允许： > 紧急Hotfix。 --- # 第二百二十章 数据库维护窗口 如需： - 大索引 - 大版本升级 提前通知运营。 --- # 第二百二十一章 生产数据初始化 首次上线必须： ```text Migration ↓ 基础字典 ↓ 系统角色 ↓ 系统权限 ↓ 平台组织 ↓ 首个管理员 ↓ 系统基础配置 ``` --- # 第二百二十二章 Seed原则 只Seed： - 字典 - Role - Permission - 基础配置 不要Seed： > 测试用户到生产。 --- # 第二百二十三章 首个Super Admin 通过： > 安全部署脚本/一次性初始化。 不能默认： ```text 账号和密码由部署环境安全提供，不写入文档 ``` --- # 第二百二十四章 默认密码 如果系统生成临时密码： > 首次登录强制修改。 --- # 第二百二十五章 生产启动后检查 第一次： ```text 健康检查 ↓ Admin登录 ↓ 微信登录 ↓ 测试实名环境检查 ↓ 文件上传 ↓ 推荐 ↓ WebSocket ↓ 数据库备份 ``` --- # 第二百二十六章 监控上线必须早于用户推广 不能： > 用户都来了才开始装监控。 --- # 第二百二十七章 第一场活动前额外检查 ```text Activity API Registration Check-in Admin Login Volunteer Account Mobile Network Manual Check-in Backup Plan ``` --- # 第二百二十八章 运维文档 建议目录： ```text docs/ops/ ├── architecture.md ├── deployment.md ├── environment.md ├── backup-restore.md ├── monitoring.md ├── incident-runbook.md ├── release.md └── disaster-recovery.md ``` --- # 第二百二十九章 部署脚本建议 ```text scripts/ ├── deploy.sh ├── rollback.sh ├── backup-db.sh ├── restore-db.sh ├── health-check.sh └── rebuild-metrics.sh ``` 根据操作系统调整。 --- # 第二百三十章 Deploy Script原则 必须： - `set -e` - 检查镜像 - 检查环境 - 记录版本 - 健康检查 - 失败退出 --- # 第二百三十一章 Rollback Script 必须明确： > 回哪个版本。 例如： ```text ./rollback.sh 1.0.0 ``` 不能： > “回上一版”但系统不知道上一版是谁。 --- # 第二百三十二章 Backup Script 运行后： - 生成备份 - 校验 - 上传异地 - 记录成功 - 失败告警 --- # 第二百三十三章 Restore Script 默认： > 不允许直接恢复覆盖生产。 应要求： ```text target database backup file confirmation ``` 防止误操作。 --- # 第二百三十四章 生产访问最小化 普通开发： > 不需要每天SSH生产。 系统可通过： - 监控 - 日志 - Admin 完成日常工作。 --- # 第二百三十五章 日志查询工具 初期： > Docker logs + 集中日志/云日志 足够。 用户量增加后： 再考虑： > Loki等轻量日志系统。 --- # 第二百三十六章 不建议V1自建ELK 因为： - 内存高 - 运维复杂 - 当前数据规模不需要 --- # 第二百三十七章 Metrics与Logs区分 Metrics： > 看系统是不是出问题。 Logs： > 查为什么出问题。 Audit： > 查谁做了什么。 三者不能混为一体。 --- # 第二百三十八章 生产数据库直接查询 普通运营： > 禁止。 技术人员如必须： - 只读账号 - 受控访问 - 记录操作 --- # 第二百三十九章 生产数据修复 使用： > 专用脚本。 不要： ```text UPDATE users SET ... ``` 直接靠手工SQL长期处理。 --- # 第二百四十章 Schema Ownership 数据库结构修改： > 只能Migration。 Application User： > 无ALTER TABLE权限。 --- # 第二百四十一章 成本控制原则 V1成本重点投入： ```text 稳定服务器 数据库 对象存储 备份 HTTPS ``` 暂时不花重金： - Kubernetes - 大型APM - 数据仓库 - 搜索集群 --- # 第二百四十二章 初期资源建议原则 不要预估成： > 百万用户平台。 按照： > 数千～数万用户可扩展 设计即可。 具体CPU/内存规格应根据最终技术栈和压测结果确定。 --- # 第二百四十三章 一个合理的扩容路径 ```text 阶段1 单Backend + PostgreSQL + Redis 阶段2 Backend x2 + 负载均衡 阶段3 PostgreSQL升级规格 + Redis独立 阶段4 读写压力明显后 再考虑进一步架构调整 ``` --- # 第二百四十四章 不提前分布式 因为V1真正风险不是： > 扛不住百万QPS。 而是： - 权限错 - Match错 - 数据丢 - 活动现场不可用 技术投入应优先解决这些。 --- # 第二百四十五章 运维权限分层 建议： ```text Cloud Admin Deployment Operator Database Admin Read-only Observer ``` 小团队可兼任。 但权限思想保留。 --- # 第二百四十六章 云主账号 不要作为： > 日常登录账号。 启用： - MFA - 强保护 日常使用子账号。 --- # 第二百四十七章 Secret泄露事故 一旦发现： ```text Git中提交Secret ``` 不能只： > 删除Commit里的Secret。 必须： > 立即Rotate。 因为历史可能已经泄露。 --- # 第二百四十八章 数据库备份恢复验收标准 必须证明： ```text 备份文件存在 ↓ 成功恢复新数据库 ↓ Backend能连接 ↓ 核心E2E数据正常 ``` 才算： > Backup可用。 --- # 第二百四十九章 发布验收标准 每次生产上线后： ```text /version正确 /health正确 Login正确 推荐正确 消息正确 Admin正确 监控无异常 ``` --- # 第二百五十章 生产变更记录 每次记录： ```text 版本 时间 执行人 Migration 配置变化 结果 是否回滚 ``` --- # 第二百五十一章 维护公告 如计划停机： 提前： > 在小程序和后台提示。 不需要复杂公告系统。 可以通过： > system notice/config。 --- # 第二百五十二章 用户端降级页面 至少： ```text 维护中 网络异常 服务暂不可用 ``` 不能只显示： > 请求失败 -500。 --- # 第二百五十三章 后台故障页面 管理员看到： > 当前服务暂时不可用，RequestId xxx。 方便反馈技术人员。 --- # 第二百五十四章 第三方依赖降级矩阵 | 服务 | 故障影响 | 降级 | |---|---|---| | 微信登录 | 新登录受影响 | 已登录用户继续 | | 实名服务 | 新实名受影响 | 已实名用户正常 | | 对象存储 | 图片受影响 | 文字业务继续 | | Redis | Cache/Session部分影响 | DB核心业务保留 | | Analytics | 统计页面 | 核心婚恋不受影响 | --- # 第二百五十五章 核心依赖矩阵 PostgreSQL： > 核心依赖。 如果不可用： > 应进入维护模式/保护状态。 --- # 第二百五十六章 数据一致性优先 如果数据库出现异常： 不要为了： > 页面继续“看起来能用” 而允许本地/Redis继续写业务。 --- # 第二百五十七章 上线后容量评估 每月记录： ```text 用户增长 数据库增长 消息增长 对象存储增长 峰值连接 峰值QPS ``` --- # 第二百五十八章 什么时候考虑架构升级 满足以下情况再考虑： ```text 单实例Backend成为明显瓶颈 数据库规格已明显不足 实时连接量增长 统计查询影响主业务 部署频率与团队规模显著增加 ``` --- # 第二百五十九章 不以“感觉用户以后会很多”作为升级依据 必须： > 基于监控数据。 --- # 第二百六十章 V1明确不采用 ```text Kubernetes Kafka RabbitMQ（除非后期确有任务需求） Elasticsearch ClickHouse Neo4j Service Mesh 微服务拆分 多活数据库 复杂DevOps平台 ``` --- # 第二百六十一章 V1推荐的最小可靠技术组合 ```text Nginx + Docker Compose + Backend Modular Monolith + PostgreSQL + Redis + Private Object Storage + 云监控/Prometheus + 数据库自动备份 + Git CI/CD ``` 足够支持V1长期稳定运行。 --- # 第二百六十二章 WorkBuddy实现要求：部署文件 代码仓库必须提供： ```text docker-compose.yml docker-compose.staging.yml .env.example Dockerfile nginx/ scripts/ docs/ops/ ``` --- # 第二百六十三章 WorkBuddy实现要求：健康检查 必须实现： ```text /health/live /health/ready /version ``` --- # 第二百六十四章 WorkBuddy实现要求：Migration 必须在CI和部署流程中： > 自动检测Migration。 禁止： > 应用启动时偷偷自动修改生产结构且不可追踪。 --- # 第二百六十五章 WorkBuddy实现要求：日志 所有后端日志： > 结构化。 包含： ```text requestId level module message ``` --- # 第二百六十六章 WorkBuddy实现要求：Graceful Shutdown Backend收到： > SIGTERM 应： - 停止接新请求 - 完成当前合理请求 - 关闭DB连接 - 关闭Redis - 关闭WebSocket 避免部署时大量异常。 --- # 第二百六十七章 WorkBuddy实现要求：Readiness Migration未完成或数据库不可连接： ```text ready = false ``` --- # 第二百六十八章 WorkBuddy实现要求：Scheduler 所有定时任务： - 有名称 - 有日志 - 幂等 - 可手工补跑 - 失败可告警 --- # 第二百六十九章 WorkBuddy实现要求：对象存储抽象 不要硬编码供应商SDK到业务层。 接口： ```text ObjectStorageService ``` 以后可以切换国内云厂商。 --- # 第二百七十章 WorkBuddy实现要求：Provider抽象 同样： ```text IdentityProvider WechatProvider SmsProvider ``` --- # 第二百七十一章 WorkBuddy实现要求：配置检查 应用启动时检查必要配置。 缺： ```text DATABASE_URL JWT_SECRET ``` 应： > Fail Fast。 不是启动后用户调用才发现。 --- # 第二百七十二章 WorkBuddy实现要求：生产模式 Production启动时： - 禁Debug - 禁Swagger公开访问（或鉴权） - 禁测试接口 - 禁Mock实名 - 禁默认密码 --- # 第二百七十三章 Swagger/OpenAPI 生产是否开放： 建议： > 后台鉴权或仅内网。 不能公开暴露完整管理API文档。 --- # 第二百七十四章 测试接口 例如： ```text /test/create-user /test/mock-match ``` 生产： > 完全不存在或强制禁用。 --- # 第二百七十五章 运维最终验收清单 ```text □ Docker镜像可重复构建 □ Compose可启动 □ Production Secret不进Git □ HTTPS正常 □ WSS正常 □ PostgreSQL非公网 □ Redis非公网 □ Object Storage Private □ Health Check正常 □ RequestId正常 □ 日志脱敏 □ 监控正常 □ 告警正常 □ 数据库备份正常 □ 恢复演练完成 □ Migration流程完成 □ Rollback可执行 □ Feature Flag可用 □ 运维文档齐全 ``` --- # 第二百七十六章 备份最终验收清单 ```text □ 每日数据库备份 □ 备份存储位置独立 □ 备份访问受限 □ 备份加密 □ 备份失败告警 □ 对象存储保护 □ 配置在Git □ Secret有安全备份 □ 实际Restore验证 ``` --- # 第二百七十七章 发布最终验收清单 ```text □ CI通过 □ Test通过 □ Staging通过 □ Migration验证 □ 生产备份 □ 发布版本明确 □ Release Notes □ Smoke Test □ 监控无异常 □ 回滚版本准备 ``` --- # 第二百七十八章 故障恢复最终验收 至少能够处理： ```text 应用服务器损坏 Redis损坏 数据库恢复 对象存储异常 证书异常 微信登录异常 实名服务异常 错误版本上线 ``` --- # 第二百七十九章 V1部署与运维核心原则 必须坚持： > **生产环境必须可以重新搭出来，而不是只有某个人知道怎么维护。** > **数据库是核心事实源，Redis只是加速。** > **用户文件必须进入私有对象存储，不放应用服务器本地。** > **生产部署必须使用固定版本镜像。** > **生产数据库禁止手工随意改表。** > **所有结构变化必须Migration。** > **备份必须真正做过恢复验证。** > **应用升级必须能回滚。** > **重要功能必须能够通过Feature Flag快速关闭。** > **出现严重错误时优先保护数据，而不是强撑服务可用。** > **运维系统应该简单到一个普通技术人员按照文档也能恢复，而不是高度依赖某一个开发者。** --- # 第二百八十章 最终部署架构 V1推荐最终结构： ```text Internet / WeChat │ HTTPS/WSS │ ┌───────┐ │ Nginx │ └───┬───┘ │ Backend Container Modular Monolith │ ┌──────────────────┼──────────────────┐ │ │ │ ↓ ↓ ↓ PostgreSQL Redis Object Storage Core Truth Cache Private Files │ ↓ Automated Backup │ ↓ Independent Storage Monitoring │ ├── Infrastructure ├── Application ├── Business └── Security CI/CD │ ↓ Build Image ↓ Staging ↓ Production ↓ Monitor ↓ Rollback if needed ``` --- # 第二百八十一章 最终结论 丹阳公益婚恋服务平台V1.0不需要一套“看起来很高级”的大型技术基础设施。 真正需要的是： > **任何一个服务器坏了，系统能重新部署。** > **任何一个版本出问题，能够回退。** > **数据库损坏，有备份可以恢复。** > **Redis丢失，不会丢核心业务。** > **对象存储出现问题，不会让数据库关系失真。** > **上线后出现异常，监控能够及时发现。** > **开发人员离开后，其他人仍然可以按文档维护。** 因此V1部署策略可以概括为： > **架构尽量简单，数据保护必须认真；部署可以轻量，备份不能轻量；升级可以快速，回滚必须可靠。**