我们之前聊了很多关于应用层的代码优化和数据库调优。但是，当你在负责维护一个承载海量数据、且不能轻易停机的核心业务系统（比如我曾深度参与架构的某省级农村生活监管平台）时，运维层面的稳定性建设才是托底的基石。

当平台汇聚了全省各市县的实时监控数据、海量表单提交以及高频的报表查询时，单机部署的脆弱性便暴露无遗。今天，结合该平台的真实运维迭代史，我们来复盘如何利用 Docker 生态，打造一个高可用、可自愈的后端环境。

一、拒绝“单点故障”：从 Docker-compose 到容灾架构

早期的许多政务或监管平台，往往就是一台高配服务器，里面塞满了 MySQL、Redis 和业务 jar 包。一旦宿主机网卡异常或磁盘打满，全省的数据上报就会直接阻断。

第一阶进化：微服务拆分与容器编排
我们使用 docker-compose.yml 将极其臃肿的单体应用，严格拆分成了 Nginx 网关层、业务逻辑层以及数据持久层，并通过 Docker 的自定义网络（Bridge Network）进行内网隔离。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
version: '3.8'
services:
  gateway-nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./logs/nginx:/var/log/nginx
    depends_on:
      - business-api-node

  business-api-node:
    image: my-platform-backend:v2.4
    deploy:
      replicas: 3 # 关键：强制启动 3 个业务副本扛住高并发
    environment:
      - SPRING_PROFILES_ACTIVE=prod
      - DB_HOST=mysql-master

通过配置 replicas: 3 配合 Nginx 的 upstream 轮询，我们在不修改一行底层代码的情况下，直接实现了业务处理能力的水平扩展，并彻底消灭了应用层的单点故障。

二、被轻视的幽灵：Docker 日志撑爆磁盘

在维护省级平台时，我踩过一个极其惨痛的坑：系统某天凌晨突然报 No space left on device。紧急排查发现，业务本身产生的文件很少，但某个高频调用的 API 容器，其底层的 /var/lib/docker/containers/ 目录下，居然积攒了一个高达 60GB 的 .json.log 文件。

终极解法：强制配置全局日志轮转 (Log Rotation)
绝不能让容器日志无限制野蛮生长。我们必须去宿主机的 /etc/docker/daemon.json 中，从 Docker 守护进程的根源上掐断这个隐患：

1
2
3
4
5
6
7
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "500m",
    "max-file": "3"
  }
}

配置完成后重启 Docker 服务。这保证了任何一个容器最多只保留最近的 3 个 500MB 日志文件，旧日志会被自动丢弃，彻底根治了磁盘被不知不觉吃干抹净的隐患。

三、数据库备份的“三保险”策略

对于监管平台而言，代码没了可以从 GitHub 重新拉，但如果在处理庞大的历史数据时发生误操作，数据丢失就是极其严重的生产事故。
因此，我们利用 Linux crontab 配合 Docker 镜像，编写了极其严苛的备份策略，并且绝不能只将备份保存在本地。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/bin/bash
# 每日凌晨 3 点触发的自动化备份脚本
BACKUP_DIR="/data/mysql_backup"
DATE=$(date +"%Y%m%d_%H%M")
FILE_NAME="rural_platform_db_$DATE.sql"

# 1. 在容器外部直接调用 mysqldump
docker exec mysql-master sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > $BACKUP_DIR/$FILE_NAME

# 2. 压缩以节省宝贵的服务器带宽
tar -zcvf $BACKUP_DIR/$FILE_NAME.tar.gz $BACKUP_DIR/$FILE_NAME

# 3. 通过 rsync 加密传输到异地灾备服务器（极其关键）
rsync -avz -e "ssh -p 2200" $BACKUP_DIR/$FILE_NAME.tar.gz backup_user@remote_backup_server:/archive/

总结

复杂系统的稳定性建设，不是靠什么高深莫测的魔法，而是靠无数个这样琐碎但致命的细节堆砌起来的。对每一次宕机心存敬畏，把每一项预防措施都固化成自动化的脚本，这才是高级技术运维的真正价值所在。