18 KiB
18 KiB
福建水务营收系统部署运维设计
一、部署架构设计
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 - 应用配置参数化
- 配置健康检查接口
- 配置日志输出级别
- JVM参数优化:
1.4 数据库服务器配置
- 软件: MySQL 8.0+
- 配置要点:
- 主从复制配置
- 缓冲池优化
- 慢查询日志配置
- 备份策略配置
1.5 缓存服务器配置
- 软件: Redis 6.0+
- 配置要点:
- 持久化配置
- 内存管理策略
- 主从复制配置
- 密码认证
2. 部署流程
2.1 准备阶段
-
服务器初始化
- 操作系统安装与配置
- 网络配置
- 安全配置(防火墙、SELinux等)
-
基础软件安装
- 安装JDK
- 安装Nginx
- 安装MySQL
- 安装Redis
- 安装MinIO
2.2 应用部署阶段
-
前端部署
- 构建前端项目
- 将构建产物部署到Web服务器
- 配置Nginx虚拟主机
-
后端部署
- 构建后端项目
- 配置数据库连接
- 配置Redis连接
- 配置MinIO连接
- 部署JAR包到应用服务器
-
数据库初始化
- 创建数据库
- 导入初始数据
- 配置数据库账户权限
2.3 验证阶段
-
功能验证
- 用户登录验证
- 核心业务流程验证
- 外部系统接口验证
-
性能验证
- 并发性能测试
- 响应时间测试
- 数据库性能测试
三、容器化部署方案
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 发布流程
- 发布申请: 提交发布申请,说明发布内容
- 审批: 相关负责人审批
- 预发布: 在预生产环境部署验证
- 发布计划: 制定详细的发布计划和回滚计划
- 正式发布: 按计划在生产环境发布
- 验证: 发布后进行功能验证
- 监控: 发布后密切监控系统运行情况
3.2 发布策略
- 蓝绿发布: 准备两个环境,一个运行旧版本,一个运行新版本,验证后切换流量
- 金丝雀发布: 先将新版本部署到一小部分服务器,验证无误后逐步扩大范围
- 灰度发布: 先对一小部分用户开放新版本,验证无误后逐步扩大用户范围
六、灾备方案
1. 灾备架构
graph TD
subgraph 主数据中心
PrimaryApp[应用服务器集群]
PrimaryDB[数据库集群]
PrimaryStorage[存储集群]
end
subgraph 灾备数据中心
DRApp[应用服务器集群]
DRDB[数据库集群]
DRStorage[存储集群]
end
PrimaryDB -- 实时同步 --> DRDB
PrimaryStorage -- 定期同步 --> DRStorage
PrimaryApp -- 配置同步 --> DRApp
2. 灾难恢复流程
- 灾难发生: 确认主数据中心不可用
- 启动灾备: 激活灾备数据中心
- DNS切换: 将DNS解析指向灾备中心
- 数据验证: 验证数据完整性
- 恢复服务: 恢复业务服务
- 用户通知: 通知用户服务已恢复
- 故障修复: 修复主数据中心故障
- 数据同步: 将灾备中心数据同步回主中心
- 切回主中心: 将服务切回主数据中心
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. 问题管理规范
- 问题记录: 所有问题必须记录
- 根因分析: 分析问题根本原因
- 解决方案: 制定问题解决方案
- 知识库: 建立问题知识库
- 经验总结: 定期总结问题处理经验