fujian_water_biz_doc/water_biz_deployment_design.md

18 KiB
Raw Blame History

福建水务营收系统部署运维设计

一、部署架构设计

1. 总体部署架构

福建水务营收系统采用分层部署架构,确保系统的高可用性、可扩展性和安全性。系统部署架构如下图所示:

graph TD
    subgraph 接入层
        LB1[负载均衡器-主]
        LB2[负载均衡器-备]
    end
    
    subgraph Web应用层
        WEB1[Web服务器1]
        WEB2[Web服务器2]
        WEB3[Web服务器3]
    end
    
    subgraph 应用服务层
        APP1[应用服务器1]
        APP2[应用服务器2]
        APP3[应用服务器3]
    end
    
    subgraph 数据存储层
        subgraph MySQL集群
            MasterDB[(主数据库)]
            SlaveDB1[(从数据库1)]
            SlaveDB2[(从数据库2)]
        end
        
        subgraph Redis集群
            RedisMaster[(Redis主节点)]
            RedisSlave1[(Redis从节点1)]
            RedisSlave2[(Redis从节点2)]
        end
        
        subgraph 文件存储
            MinIO1[MinIO节点1]
            MinIO2[MinIO节点2]
        end
    end
    
    LB1 --> WEB1
    LB1 --> WEB2
    LB1 --> WEB3
    LB2 --> WEB1
    LB2 --> WEB2
    LB2 --> WEB3
    
    WEB1 --> APP1
    WEB1 --> APP2
    WEB1 --> APP3
    WEB2 --> APP1
    WEB2 --> APP2
    WEB2 --> APP3
    WEB3 --> APP1
    WEB3 --> APP2
    WEB3 --> APP3
    
    APP1 --> MasterDB
    APP1 --> SlaveDB1
    APP1 --> SlaveDB2
    APP1 --> RedisMaster
    APP1 --> RedisSlave1
    APP1 --> RedisSlave2
    APP1 --> MinIO1
    APP1 --> MinIO2
    
    APP2 --> MasterDB
    APP2 --> SlaveDB1
    APP2 --> SlaveDB2
    APP2 --> RedisMaster
    APP2 --> RedisSlave1
    APP2 --> RedisSlave2
    APP2 --> MinIO1
    APP2 --> MinIO2
    
    APP3 --> MasterDB
    APP3 --> SlaveDB1
    APP3 --> SlaveDB2
    APP3 --> RedisMaster
    APP3 --> RedisSlave1
    APP3 --> RedisSlave2
    APP3 --> MinIO1
    APP3 --> MinIO2
    
    MasterDB --> SlaveDB1
    MasterDB --> SlaveDB2
    RedisMaster --> RedisSlave1
    RedisMaster --> RedisSlave2

2. 物理部署方案

2.1 硬件配置要求

服务器类型 数量 CPU 内存 存储 网络 用途
负载均衡服务器 2 8核 16GB 200GB SSD 双千兆网卡 负载均衡、反向代理
Web服务器 3 16核 32GB 200GB SSD 千兆网卡 部署前端应用
应用服务器 3 16核 64GB 500GB SSD 千兆网卡 部署后端应用
数据库服务器 3 32核 128GB 2TB SSD RAID10 千兆网卡 部署MySQL数据库
缓存服务器 3 16核 64GB 500GB SSD 千兆网卡 部署Redis缓存
存储服务器 2 16核 32GB 10TB RAID5 千兆网卡 文件存储
监控服务器 1 8核 16GB 500GB SSD 千兆网卡 运行监控系统
备份服务器 1 8核 16GB 20TB RAID6 千兆网卡 数据备份

2.2 网络拓扑

graph TD
    Internet((互联网)) --> FW[防火墙]
    FW --> DMZ{DMZ区域}
    DMZ --> LB[负载均衡器]
    LB --> Web{Web服务区}
    Web --> App{应用服务区}
    App --> DB{数据库区}
    App --> Cache{缓存区}
    App --> Storage{存储区}

2.3 安全区域划分

  • 互联网区域: 外部用户访问区域
  • DMZ区域: 部署负载均衡器和反向代理服务器
  • Web服务区: 部署Web服务器
  • 应用服务区: 部署应用服务器
  • 数据库区: 部署数据库服务器
  • 缓存区: 部署缓存服务器
  • 存储区: 部署文件存储服务器

二、软件部署方案

1. 软件环境配置

1.1 操作系统配置

  • 操作系统: CentOS 8.x / Ubuntu 20.04 LTS
  • 内核参数优化:
    net.ipv4.tcp_max_syn_backlog = 8192
    net.core.somaxconn = 4096
    net.ipv4.tcp_fin_timeout = 30
    net.ipv4.tcp_keepalive_time = 1200
    vm.swappiness = 10
    

1.2 Web服务器配置

  • 软件: Nginx 1.20+
  • 配置要点:
    • 启用HTTP/2协议
    • 启用GZIP压缩
    • 配置SSL证书
    • 配置反向代理
    • 静态资源缓存策略

1.3 应用服务器配置

  • 软件: JDK 11+, Spring Boot 2.7.x
  • 配置要点:
    • JVM参数优化: -Xms4g -Xmx4g -XX:+UseG1GC
    • 应用配置参数化
    • 配置健康检查接口
    • 配置日志输出级别

1.4 数据库服务器配置

  • 软件: MySQL 8.0+
  • 配置要点:
    • 主从复制配置
    • 缓冲池优化
    • 慢查询日志配置
    • 备份策略配置

1.5 缓存服务器配置

  • 软件: Redis 6.0+
  • 配置要点:
    • 持久化配置
    • 内存管理策略
    • 主从复制配置
    • 密码认证

2. 部署流程

2.1 准备阶段

  1. 服务器初始化

    • 操作系统安装与配置
    • 网络配置
    • 安全配置防火墙、SELinux等
  2. 基础软件安装

    • 安装JDK
    • 安装Nginx
    • 安装MySQL
    • 安装Redis
    • 安装MinIO

2.2 应用部署阶段

  1. 前端部署

    • 构建前端项目
    • 将构建产物部署到Web服务器
    • 配置Nginx虚拟主机
  2. 后端部署

    • 构建后端项目
    • 配置数据库连接
    • 配置Redis连接
    • 配置MinIO连接
    • 部署JAR包到应用服务器
  3. 数据库初始化

    • 创建数据库
    • 导入初始数据
    • 配置数据库账户权限

2.3 验证阶段

  1. 功能验证

    • 用户登录验证
    • 核心业务流程验证
    • 外部系统接口验证
  2. 性能验证

    • 并发性能测试
    • 响应时间测试
    • 数据库性能测试

三、容器化部署方案

1. Docker容器配置

1.1 容器镜像设计

  • 前端镜像: 基于Nginx包含前端静态资源
  • 后端镜像: 基于OpenJDK包含后端JAR包
  • 数据库镜像: 基于MySQL官方镜像
  • 缓存镜像: 基于Redis官方镜像

1.2 容器编排设计

使用Docker Compose进行容器编排示例配置文件:

version: '3'

services:
  nginx:
    image: nginx:1.20
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf:/etc/nginx/conf.d
      - ./nginx/ssl:/etc/nginx/ssl
      - ./nginx/html:/usr/share/nginx/html
    networks:
      - frontend-network
    depends_on:
      - backend

  backend:
    image: water-biz-backend:1.0
    environment:
      - SPRING_PROFILES_ACTIVE=prod
      - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/water_biz
      - SPRING_REDIS_HOST=redis
    volumes:
      - ./logs:/app/logs
    networks:
      - frontend-network
      - backend-network
    depends_on:
      - mysql
      - redis

  mysql:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secret
      - MYSQL_DATABASE=water_biz
      - MYSQL_USER=water_biz
      - MYSQL_PASSWORD=water_biz_pwd
    volumes:
      - mysql-data:/var/lib/mysql
      - ./mysql/init:/docker-entrypoint-initdb.d
    networks:
      - backend-network

  redis:
    image: redis:6.0
    command: redis-server --requirepass redis_pwd
    volumes:
      - redis-data:/data
    networks:
      - backend-network

networks:
  frontend-network:
  backend-network:

volumes:
  mysql-data:
  redis-data:

2. Kubernetes部署方案

2.1 K8s部署架构

graph TD
    subgraph Kubernetes集群
        Ingress[Ingress控制器]
        
        subgraph 前端命名空间
            FrontSVC[前端服务]
            FrontPod1[前端Pod1]
            FrontPod2[前端Pod2]
            FrontPod3[前端Pod3]
        end
        
        subgraph 后端命名空间
            BackSVC[后端服务]
            BackPod1[后端Pod1]
            BackPod2[后端Pod2]
            BackPod3[后端Pod3]
        end
        
        subgraph 数据库命名空间
            MySQLSVC[MySQL服务]
            MySQLSTS[MySQL StatefulSet]
            MySQLPod1[MySQL主节点]
            MySQLPod2[MySQL从节点1]
            MySQLPod3[MySQL从节点2]
        end
        
        subgraph 缓存命名空间
            RedisSVC[Redis服务]
            RedisSTS[Redis StatefulSet]
            RedisPod1[Redis主节点]
            RedisPod2[Redis从节点1]
            RedisPod3[Redis从节点2]
        end
    end
    
    Ingress --> FrontSVC
    FrontSVC --> FrontPod1
    FrontSVC --> FrontPod2
    FrontSVC --> FrontPod3
    
    FrontPod1 --> BackSVC
    FrontPod2 --> BackSVC
    FrontPod3 --> BackSVC
    
    BackSVC --> BackPod1
    BackSVC --> BackPod2
    BackSVC --> BackPod3
    
    BackPod1 --> MySQLSVC
    BackPod1 --> RedisSVC
    BackPod2 --> MySQLSVC
    BackPod2 --> RedisSVC
    BackPod3 --> MySQLSVC
    BackPod3 --> RedisSVC
    
    MySQLSVC --> MySQLSTS
    MySQLSTS --> MySQLPod1
    MySQLSTS --> MySQLPod2
    MySQLSTS --> MySQLPod3
    
    RedisSVC --> RedisSTS
    RedisSTS --> RedisPod1
    RedisSTS --> RedisPod2
    RedisSTS --> RedisPod3

2.2 K8s资源配置示例

前端Deployment配置:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: water-biz-frontend
  namespace: water-biz-frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: water-biz-frontend
  template:
    metadata:
      labels:
        app: water-biz-frontend
    spec:
      containers:
      - name: water-biz-frontend
        image: water-biz-frontend:1.0
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "256Mi"
            cpu: "200m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10

后端Deployment配置:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: water-biz-backend
  namespace: water-biz-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: water-biz-backend
  template:
    metadata:
      labels:
        app: water-biz-backend
    spec:
      containers:
      - name: water-biz-backend
        image: water-biz-backend:1.0
        ports:
        - containerPort: 8080
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: "prod"
        - name: SPRING_DATASOURCE_URL
          valueFrom:
            configMapKeyRef:
              name: water-biz-config
              key: database.url
        resources:
          requests:
            memory: "1Gi"
            cpu: "500m"
          limits:
            memory: "2Gi"
            cpu: "1000m"
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 15

四、系统运维方案

1. 监控方案

1.1 监控架构

graph TD
    App[应用服务] --> Prometheus[Prometheus]
    DB[数据库] --> Prometheus
    OS[操作系统] --> Prometheus
    Net[网络设备] --> Prometheus
    
    Prometheus --> Grafana[Grafana]
    Prometheus --> AlertManager[告警管理器]
    
    AlertManager --> Email[邮件通知]
    AlertManager --> SMS[短信通知]
    AlertManager --> WeChat[微信通知]

1.2 监控指标

  • 系统层监控

    • CPU使用率
    • 内存使用率
    • 磁盘I/O
    • 网络流量
    • 进程数
  • 应用层监控

    • JVM指标堆内存、GC情况
    • 线程池状态
    • HTTP请求统计
    • 业务接口响应时间
    • 异常统计
  • 数据库监控

    • 连接数
    • 查询性能
    • 事务状态
    • 锁等待情况
    • 缓存命中率
  • 业务层监控

    • 登录成功/失败次数
    • 抄表数据录入量
    • 水费收缴情况
    • 系统并发用户数
    • 业务处理量

2. 日志管理

2.1 日志采集架构

graph TD
    App[应用服务] -- 日志文件 --> Filebeat[Filebeat]
    Filebeat --> Logstash[Logstash]
    Logstash --> ES[Elasticsearch]
    ES --> Kibana[Kibana]

2.2 日志分类

  • 系统日志: 操作系统、中间件产生的日志
  • 应用日志: 应用运行产生的日志
  • 业务日志: 业务操作产生的日志
  • 安全日志: 安全相关操作产生的日志
  • 审计日志: 需要审计的关键操作日志

2.3 日志保留策略

日志类型 线上保留时间 归档保留时间
系统日志 7天 30天
应用日志 15天 90天
业务日志 30天 1年
安全日志 90天 3年
审计日志 1年 5年

3. 备份恢复策略

3.1 备份策略

  • 数据库备份

    • 全量备份: 每天凌晨进行一次全量备份
    • 增量备份: 每小时进行一次增量备份
    • 实时备份: 开启binlog实时备份
  • 应用备份

    • 配置文件备份: 每次变更时备份
    • 代码版本备份: 使用Git保存代码版本
  • 系统备份

    • 系统镜像备份: 每季度进行一次系统镜像备份
    • 关键配置备份: 每次变更时备份

3.2 恢复策略

  • 数据库恢复

    • 按时间点恢复: 可恢复到任意时间点
    • 备份文件恢复: 使用备份文件进行恢复
    • 模拟演练: 每季度进行一次恢复演练
  • 应用恢复

    • 版本回滚: 可回滚到任意版本
    • 配置恢复: 使用备份配置进行恢复

4. 安全运维

4.1 账号管理

  • 最小权限原则: 账号权限满足工作所需的最小权限
  • 权限分离: 开发、测试、运维账号权限分离
  • 定期审计: 每季度进行一次账号权限审计
  • 账号生命周期: 严格管理账号创建、变更、注销流程

4.2 漏洞管理

  • 定期扫描: 每月进行一次系统漏洞扫描
  • 及时修复: 关键漏洞24小时内修复
  • 补丁管理: 建立补丁管理制度,定期更新系统补丁

4.3 安全审计

  • 操作审计: 记录所有关键操作
  • 登录审计: 记录所有登录行为
  • 异常行为检测: 检测并报警异常操作行为

5. 容量规划

5.1 容量评估指标

  • 用户数: 系统支持的最大并发用户数
  • 数据量: 系统数据增长预测
  • 存储容量: 存储空间增长预测
  • 网络带宽: 网络流量增长预测

5.2 扩容策略

  • 水平扩容: 增加服务器节点数量
  • 垂直扩容: 提升单台服务器配置
  • 分库分表: 对大表进行分库分表
  • 冷热数据分离: 将冷数据迁移到低成本存储

五、持续集成与部署

1. CI/CD流程

graph LR
    Code[代码提交] --> Build[构建]
    Build --> UnitTest[单元测试]
    UnitTest --> CodeScan[代码扫描]
    CodeScan --> Package[打包]
    Package --> Deploy[部署测试环境]
    Deploy --> IntTest[集成测试]
    IntTest --> UAT[用户验收测试]
    UAT --> Prod[生产环境部署]

2. 环境管理

  • 开发环境: 供开发人员开发和单元测试使用
  • 测试环境: 供测试人员进行功能测试
  • 预生产环境: 与生产环境配置相同,用于最终验证
  • 生产环境: 正式运行环境

3. 发布管理

3.1 发布流程

  1. 发布申请: 提交发布申请,说明发布内容
  2. 审批: 相关负责人审批
  3. 预发布: 在预生产环境部署验证
  4. 发布计划: 制定详细的发布计划和回滚计划
  5. 正式发布: 按计划在生产环境发布
  6. 验证: 发布后进行功能验证
  7. 监控: 发布后密切监控系统运行情况

3.2 发布策略

  • 蓝绿发布: 准备两个环境,一个运行旧版本,一个运行新版本,验证后切换流量
  • 金丝雀发布: 先将新版本部署到一小部分服务器,验证无误后逐步扩大范围
  • 灰度发布: 先对一小部分用户开放新版本,验证无误后逐步扩大用户范围

六、灾备方案

1. 灾备架构

graph TD
    subgraph 主数据中心
        PrimaryApp[应用服务器集群]
        PrimaryDB[数据库集群]
        PrimaryStorage[存储集群]
    end
    
    subgraph 灾备数据中心
        DRApp[应用服务器集群]
        DRDB[数据库集群]
        DRStorage[存储集群]
    end
    
    PrimaryDB -- 实时同步 --> DRDB
    PrimaryStorage -- 定期同步 --> DRStorage
    PrimaryApp -- 配置同步 --> DRApp

2. 灾难恢复流程

  1. 灾难发生: 确认主数据中心不可用
  2. 启动灾备: 激活灾备数据中心
  3. DNS切换: 将DNS解析指向灾备中心
  4. 数据验证: 验证数据完整性
  5. 恢复服务: 恢复业务服务
  6. 用户通知: 通知用户服务已恢复
  7. 故障修复: 修复主数据中心故障
  8. 数据同步: 将灾备中心数据同步回主中心
  9. 切回主中心: 将服务切回主数据中心

3. 灾备演练

  • 演练频率: 每半年进行一次灾备演练
  • 演练方式: 模拟主数据中心故障,激活灾备中心
  • 演练评估: 评估恢复时间目标(RTO)和恢复点目标(RPO)达成情况

七、运维工具链

1. 运维工具清单

类别 工具 用途
配置管理 Ansible 自动化配置管理
容器管理 Docker, Kubernetes 容器化部署与编排
持续集成 Jenkins, GitLab CI 自动化构建与部署
监控告警 Prometheus, Grafana, AlertManager 系统监控与告警
日志管理 ELK Stack 日志收集与分析
数据库管理 MySQL Workbench, Redis Desktop Manager 数据库运维管理
网络管理 Netdata, Smokeping 网络监控与故障排查
安全管理 Nessus, OpenVAS 安全漏洞扫描

2. 自动化运维脚本

  • 系统巡检脚本: 定期检查系统状态
  • 数据备份脚本: 自动执行数据备份
  • 日志清理脚本: 自动清理过期日志
  • 性能基线采集脚本: 采集系统性能基线

八、运维管理规范

1. 变更管理规范

  • 变更申请: 所有变更必须提交申请
  • 变更评审: 重要变更必须经过评审
  • 变更窗口: 生产环境变更只能在指定时间窗口进行
  • 变更通知: 提前通知相关人员
  • 变更回滚: 制定详细的回滚方案

2. 事件管理规范

  • 事件分级: 按影响范围和严重程度分级
  • 响应时间: 不同级别事件的响应时间要求
  • 升级流程: 事件升级的条件和流程
  • 通知机制: 事件通知的方式和对象
  • 事后复盘: 重大事件后必须进行复盘

3. 问题管理规范

  • 问题记录: 所有问题必须记录
  • 根因分析: 分析问题根本原因
  • 解决方案: 制定问题解决方案
  • 知识库: 建立问题知识库
  • 经验总结: 定期总结问题处理经验