docs: add integrated deployment planb doc and docx
This commit is contained in:
parent
09b8a8e3d9
commit
c85550ffde
@ -0,0 +1,653 @@
|
||||
---
|
||||
doc_id: TC-08-INTEGRATED-DEPLOYMENT
|
||||
doc_role: supplemental_document
|
||||
authority: secondary
|
||||
scope: 方案二整体部署
|
||||
source_of_truth: false
|
||||
last_reviewed: 2026-03-26
|
||||
retrieval_priority: P1
|
||||
---
|
||||
|
||||
# 福建水务营收系统整体部署方案说明书
|
||||
|
||||
## 文档信息
|
||||
| 项目信息 | 详情 |
|
||||
|---------|------|
|
||||
| **项目名称** | 福建水务营收系统 |
|
||||
| **文档类型** | 技术专题说明 |
|
||||
| **方案定位** | 已采纳 PostgreSQL 16 方案二作为数据库部署方案后的整体部署方案 |
|
||||
| **文档版本** | v1.0 |
|
||||
| **编写日期** | 2026-03-26 |
|
||||
| **文档状态** | ✅ 正式建议稿 |
|
||||
|
||||
## 目录
|
||||
|
||||
1. 编制目的
|
||||
2. 方案前提
|
||||
3. 整体部署原则
|
||||
4. 软件拓扑图
|
||||
5. 主机部署图
|
||||
6. 数据库访问链路图
|
||||
7. 备份恢复链路图
|
||||
8. 网络拓扑图
|
||||
9. 主机角色与部署内容
|
||||
10. 资源配置建议
|
||||
11. 资源审批汇总表
|
||||
12. 基础软件与版本清单
|
||||
13. 部署方式说明
|
||||
14. 网络需求
|
||||
15. 网络开通清单
|
||||
16. 访问控制与端口建议
|
||||
17. 实施步骤
|
||||
18. 验收标准
|
||||
19. 部署结论
|
||||
|
||||
## 编制目的
|
||||
|
||||
本文档用于在已采纳 PostgreSQL 16 方案二作为数据库部署方案的前提下，形成覆盖前端、后端、中间件、静态存储及数据库的一体化整体部署方案，作为甲方进行主机、网络、存储与基础软件资源审批的依据。
|
||||
|
||||
## 方案前提
|
||||
|
||||
本方案以以下前提为基础：
|
||||
|
||||
1. 数据库部署方案已采纳 `docs/design/03_Technical_Design/07_PostgreSQL16_DR_Resource_Application.md` 中的方案二，即“同城双可用区主备容灾方案”。
|
||||
2. 前端继续采用 `Nginx + Vue3` 的静态部署模式。
|
||||
3. 对外访问经甲方或第三方管理的公网入口进行薄转发，不纳入本方案主机资源范围。
|
||||
4. 内网 `Nginx` 单独部署，负责将开放 API 端点负载到两台业务应用节点。
|
||||
5. 两台业务应用节点内均部署 `Spring Boot Gateway`，作为微服务集群统一接入入口，并同时承载业务服务。
|
||||
6. 中间件集中部署在 1 台主机上。
|
||||
7. 数据库控制组件与中间件部署在同一台主机上。
|
||||
8. `MinIO` 作为静态存储与对象存储统一入口，与中间件同机部署。
|
||||
9. 一期口径下，原“数据与中间件节点”和“文件存储节点”合并为 1 台综合节点。
|
||||
10. 银行文件交换采用独立 `SFTP/FTP` 文件交换服务器，作为银行送盘、回盘、对账文件交换专用前置机。
|
||||
11. 当前已知可用于本方案的业务与基础设施主机资源如下：
|
||||
- 内网 Nginx 入口节点：8 核 CPU / 16 GB 内存 / 300 GB 存储，共 1 台
|
||||
- 业务应用节点（主）：32 核 CPU / 64 GB 内存 / 300 GB 存储，共 2 台
|
||||
- 数据、中间件与文件存储综合节点：16 核 CPU / 32 GB 内存 / 2300 GB 存储，共 1 台
|
||||
- 银行文件交换服务器：2 核 CPU / 8 GB 内存 / 200 GB 存储，共 1 台
|
||||
- 另行配置 PostgreSQL 主库与热备库各 1 台
|
||||
|
||||
## 整体部署原则
|
||||
|
||||
整体部署遵循以下原则：
|
||||
|
||||
1. 前后端逻辑分层部署，避免数据库节点与业务节点混部。
|
||||
2. 中间件集中部署，降低主机数量和运维复杂度。
|
||||
3. 数据库主备分离部署，避免与中间件、应用节点混部。
|
||||
4. 数据库控制组件集中部署，通过统一代理地址屏蔽主备切换细节。
|
||||
5. 网络按公网接入区、内网接入区、应用区、中间件与文件存储区、银行文件交换区、数据区分层隔离。
|
||||
6. 在现有主机数量约束下，优先复用现有业务应用节点、内网入口节点及综合节点资源。
|
||||
|
||||
## 软件拓扑图
|
||||
|
||||
**图 4-1 访问与应用软件拓扑图**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef source fill:#ecfeff,stroke:#0891b2,stroke-width:1.2px,color:#083344;
|
||||
classDef access fill:#fff7ed,stroke:#ea580c,stroke-width:1.4px,color:#7c2d12;
|
||||
classDef app fill:#eff6ff,stroke:#2563eb,stroke-width:1.4px,color:#1e3a8a;
|
||||
|
||||
U1[PC 端用户]:::source
|
||||
U2[移动端用户]:::source
|
||||
U3[第三方系统]:::source
|
||||
G1[公网入口薄转发]:::access
|
||||
G2[内网 Nginx]:::access
|
||||
|
||||
subgraph APP1[业务应用节点 1]
|
||||
direction TB
|
||||
A1G[Spring Boot Gateway]:::app
|
||||
A1B[业务服务]:::app
|
||||
end
|
||||
|
||||
subgraph APP2[业务应用节点 2]
|
||||
direction TB
|
||||
A2G[Spring Boot Gateway]:::app
|
||||
A2B[业务服务]:::app
|
||||
end
|
||||
|
||||
U1 -->|内网访问| G2
|
||||
U2 -->|HTTPS 443| G1
|
||||
U3 -->|接口访问| G1
|
||||
G1 -->|开放 API 转发| G2
|
||||
G2 -->|负载到节点 1| A1G
|
||||
G2 -->|负载到节点 2| A2G
|
||||
A1G --> A1B
|
||||
A2G --> A2B
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. PC 端用户通过内网直接访问内网 Nginx。
|
||||
2. 移动端用户和第三方系统先经公网入口薄转发，再由公网入口转发到内网 Nginx。
|
||||
3. 内网 Nginx 将开放 API 端点负载到两台业务应用节点。
|
||||
4. 两台业务应用节点内均部署 Spring Boot Gateway，作为微服务集群统一接入入口。
|
||||
5. 每台业务应用节点内的 Gateway 再向本节点业务服务转发请求。
|
||||
|
||||
**图 4-2 综合服务软件拓扑图**
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
classDef app fill:#eff6ff,stroke:#2563eb,stroke-width:1.4px,color:#1e3a8a;
|
||||
classDef service fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.4px,color:#4c1d95;
|
||||
|
||||
A1[业务应用节点 1<br/>Gateway + Biz]:::app
|
||||
A2[业务应用节点 2<br/>Gateway + Biz]:::app
|
||||
|
||||
subgraph M[综合节点]
|
||||
direction TB
|
||||
M2[Redis / Nacos / MinIO]:::service
|
||||
M3[HAProxy / PgBouncer / Patroni]:::service
|
||||
end
|
||||
|
||||
A1 -->|缓存 配置 文件访问| M2
|
||||
A2 -->|缓存 配置 文件访问| M2
|
||||
A1 -->|数据库代理访问| M3
|
||||
A2 -->|数据库代理访问| M3
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. 综合节点承接缓存、配置、对象存储及数据库控制组件。
|
||||
2. 两台业务应用节点统一访问综合节点，不直接连接数据库。
|
||||
|
||||
**图 4-3 数据与备份软件拓扑图**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef service fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.4px,color:#4c1d95;
|
||||
classDef data fill:#ecfdf5,stroke:#059669,stroke-width:1.4px,color:#064e3b;
|
||||
classDef backup fill:#fffbeb,stroke:#d97706,stroke-width:1.4px,color:#78350f;
|
||||
classDef bank fill:#fef2f2,stroke:#dc2626,stroke-width:1.4px,color:#7f1d1d;
|
||||
|
||||
M2[MinIO / 附件文件]:::service
|
||||
M3[HAProxy / PgBouncer / Patroni]:::service
|
||||
F1[SFTP / FTP 文件交换服务器]:::bank
|
||||
D1[(PostgreSQL 主库)]:::data
|
||||
D2[(PostgreSQL 热备)]:::data
|
||||
B1[备份归档存储]:::backup
|
||||
|
||||
M3 -->|数据库访问| D1
|
||||
M3 -->|状态感知| D2
|
||||
D1 -->|同步复制| D2
|
||||
D1 -->|基础备份 WAL 归档| B1
|
||||
D2 -->|备份副本| B1
|
||||
M2 -->|对象存储归档| B1
|
||||
F1 -->|银行文件归档| B1
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. 数据库控制组件经由主库提供数据库访问能力。
|
||||
2. 主库与热备之间通过同步复制保持一致性。
|
||||
3. 银行文件交换服务器承接送盘、回盘、对账文件交换能力。
|
||||
4. MinIO 与银行文件交换服务器分别将各自数据归档到备份归档存储。
|
||||
|
||||
## 主机部署图
|
||||
|
||||
**图 4-4 主机部署总览图**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef gateway fill:#fff7ed,stroke:#ea580c,stroke-width:1.2px,color:#7c2d12;
|
||||
classDef app fill:#eff6ff,stroke:#2563eb,stroke-width:1.2px,color:#1e3a8a;
|
||||
classDef middle fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.2px,color:#4c1d95;
|
||||
classDef data fill:#ecfdf5,stroke:#059669,stroke-width:1.2px,color:#064e3b;
|
||||
|
||||
GW[内网 Nginx 入口节点]:::gateway
|
||||
APP1[业务应用节点 1<br/>内含 Gateway]:::app
|
||||
APP2[业务应用节点 2<br/>内含 Gateway]:::app
|
||||
MID[综合节点]:::middle
|
||||
FTP[SFTP / FTP 文件交换服务器]:::middle
|
||||
DB1[(数据库主库服务器)]:::data
|
||||
DB2[(数据库热备服务器)]:::data
|
||||
|
||||
GW --> APP1
|
||||
GW --> APP2
|
||||
APP1 --> MID
|
||||
APP2 --> MID
|
||||
APP1 --> FTP
|
||||
APP2 --> FTP
|
||||
MID --> DB1
|
||||
MID --> DB2
|
||||
DB1 --> DB2
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. 内网 Nginx 入口节点作为我方统一接入入口，承接 API 转发与内部负载均衡能力。
|
||||
2. 业务应用节点 1 和业务应用节点 2 组成应用主机集群，节点内同时部署 Spring Boot Gateway 与核心业务服务。
|
||||
3. 综合节点集中承载 Redis、Nacos、MinIO、HAProxy、PgBouncer、Patroni，并同时访问数据库主库与热备服务器。
|
||||
4. 独立的 SFTP/FTP 文件交换服务器承接银行送盘、回盘、对账文件交换，并由业务应用节点直接访问。
|
||||
5. 数据库主库服务器与数据库热备服务器独立部署，满足数据库高可用要求。
|
||||
|
||||
主机部署细化说明：
|
||||
|
||||
1. 内网 Nginx 入口节点部署 `Nginx`，负责开放 API 转发和内部负载均衡。
|
||||
2. 两台业务应用节点分别部署 `Spring Boot Gateway` 与业务服务实例。
|
||||
3. 综合节点部署 `Redis`、`Nacos`、`MinIO`、`HAProxy`、`PgBouncer`、`Patroni`，并负责访问数据库主库与热备服务器。
|
||||
4. SFTP/FTP 文件交换服务器部署银行文件交换服务及送盘、回盘、对账目录，由业务应用节点直接访问。
|
||||
5. 数据库主库服务器部署 PostgreSQL 主库实例，数据库热备服务器部署 PostgreSQL 热备实例。
|
||||
|
||||
## 数据库访问链路图
|
||||
|
||||
**图 4-5 数据库访问链路图**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A1[业务应用节点 1]
|
||||
A2[业务应用节点 2]
|
||||
P[PgBouncer]
|
||||
H[HAProxy]
|
||||
M[(主库)]
|
||||
S[(热备)]
|
||||
T[Patroni]
|
||||
|
||||
A1 -->|统一代理地址| P
|
||||
A2 -->|统一代理地址| P
|
||||
P -->|连接池复用| H
|
||||
H -->|写流量| M
|
||||
H -.热备探测 / 状态访问.-> S
|
||||
M -->|同步复制| S
|
||||
T -.主备状态管理.-> H
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. 业务应用不直接连接数据库主机。
|
||||
2. PgBouncer 负责连接池。
|
||||
3. HAProxy 负责数据库入口代理。
|
||||
4. Patroni 负责主备状态管理与切换控制。
|
||||
5. 综合节点侧的数据库控制组件会同时访问主库和热备，用于探测、控制和切换。
|
||||
|
||||
## 备份恢复链路图
|
||||
|
||||
**图 4-6 备份恢复链路图**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DB1[(PostgreSQL 主库)] --> BK[备份归档存储]
|
||||
DB2[(PostgreSQL 热备)] --> BK
|
||||
MID[综合节点 / MinIO] --> BK
|
||||
BK --> REC[恢复与演练入口]
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. 主库和热备均向备份归档存储输出备份数据。
|
||||
2. 综合节点中的 MinIO 文件数据也纳入备份范围。
|
||||
3. 备份归档存储作为数据库恢复与文件恢复的统一入口。
|
||||
|
||||
## 网络拓扑图
|
||||
|
||||
**图 4-7 网络拓扑图**
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
classDef user fill:#ecfeff,stroke:#0891b2,stroke-width:1.2px,color:#083344;
|
||||
classDef access fill:#fff7ed,stroke:#ea580c,stroke-width:1.2px,color:#7c2d12;
|
||||
classDef app fill:#eff6ff,stroke:#2563eb,stroke-width:1.2px,color:#1e3a8a;
|
||||
classDef ext fill:#fef3c7,stroke:#d97706,stroke-width:1.2px,color:#78350f;
|
||||
classDef middle fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.2px,color:#4c1d95;
|
||||
classDef data fill:#ecfdf5,stroke:#059669,stroke-width:1.2px,color:#064e3b;
|
||||
classDef backup fill:#fdf2f8,stroke:#db2777,stroke-width:1.2px,color:#831843;
|
||||
|
||||
subgraph U[访问来源]
|
||||
direction LR
|
||||
PC[PC 端用户]
|
||||
M[移动端用户]
|
||||
T[第三方系统]
|
||||
end
|
||||
|
||||
subgraph A[接入层]
|
||||
direction TB
|
||||
PGW[公网入口薄转发]
|
||||
IGW[内网 Nginx]
|
||||
end
|
||||
|
||||
subgraph B[应用层]
|
||||
direction LR
|
||||
APP1[业务应用节点 1<br/>Spring Boot Gateway]
|
||||
APP2[业务应用节点 2<br/>Spring Boot Gateway]
|
||||
end
|
||||
|
||||
subgraph E[外部交换区]
|
||||
direction TB
|
||||
FX[SFTP/FTP 文件交换服务器]
|
||||
end
|
||||
|
||||
subgraph C[综合服务层]
|
||||
direction TB
|
||||
MID[综合节点]
|
||||
end
|
||||
|
||||
subgraph D[数据层]
|
||||
direction LR
|
||||
DBM[(PostgreSQL 主库)]
|
||||
DBS[(PostgreSQL 热备)]
|
||||
end
|
||||
|
||||
subgraph BK[备份归档层]
|
||||
direction TB
|
||||
STORE[备份归档存储]
|
||||
end
|
||||
|
||||
PC -->|内网访问| IGW
|
||||
M -->|公网 HTTPS| PGW
|
||||
T -->|公网 HTTPS/接口| PGW
|
||||
PGW -->|转发| IGW
|
||||
|
||||
IGW -->|负载均衡| APP1
|
||||
IGW -->|负载均衡| APP2
|
||||
|
||||
APP1 -->|文件交换| FX
|
||||
APP2 -->|文件交换| FX
|
||||
|
||||
APP1 -->|业务访问| MID
|
||||
APP2 -->|业务访问| MID
|
||||
|
||||
MID -->|数据库访问| DBM
|
||||
MID -->|状态感知/只读访问| DBS
|
||||
DBM -->|主备同步| DBS
|
||||
|
||||
DBM -->|备份/WAL 归档| STORE
|
||||
DBS -->|备份副本| STORE
|
||||
MID -->|文件归档| STORE
|
||||
|
||||
class PC,M,T user;
|
||||
class PGW,IGW access;
|
||||
class APP1,APP2 app;
|
||||
class FX ext;
|
||||
class MID middle;
|
||||
class DBM,DBS data;
|
||||
class STORE backup;
|
||||
```
|
||||
|
||||
图说明：
|
||||
|
||||
1. PC 端用户通过内网直接访问内网 Nginx，移动端用户和第三方系统通过公网入口薄转发，再转发至内网 Nginx。
|
||||
2. 内网 Nginx 统一负载到两台业务应用节点，两台节点内部均部署 Spring Boot Gateway。
|
||||
3. 业务应用节点一方面直接访问 SFTP/FTP 文件交换服务器，另一方面访问综合节点获取缓存、配置、文件和数据库代理能力。
|
||||
4. 综合节点访问 PostgreSQL 主库与热备，数据库主备及综合节点均接入备份归档存储。
|
||||
|
||||
## 主机角色与部署内容
|
||||
|
||||
| 层级 | 主机角色 | 数量 | 主要部署内容 | 说明 |
|
||||
|---|---|---:|---|---|
|
||||
| 接入层 | 内网 Nginx 入口节点 | 1 台 | Nginx、API 转发、内部负载均衡 | 作为我方统一内网接入入口，承接开放 API 转发 |
|
||||
| 应用层 | 业务应用节点（主） | 2 台 | Spring Boot Gateway、Spring Boot 业务服务 | 承载微服务集群接入与表务、抄表、收费、账务、发票、报表等核心应用服务 |
|
||||
| 综合支撑层 | 数据、中间件与文件存储综合节点 | 1 台 | Redis、Nacos、MinIO、HAProxy、PgBouncer、Patroni | 中间件、数据库控制与文件存储同机部署 |
|
||||
| 银行交换层 | SFTP/FTP 文件交换服务器 | 1 台 | SFTP/FTP 服务、送盘目录、回盘目录、对账目录、归档目录 | 作为银行文件交换专用前置机 |
|
||||
| 数据库层 | PostgreSQL 主库服务器 | 1 台 | PostgreSQL 16 Primary | 部署在可用区 A |
|
||||
| 数据库层 | PostgreSQL 热备服务器 | 1 台 | PostgreSQL 16 Standby | 部署在可用区 B |
|
||||
| 备份层 | 备份归档存储 | 1 套 | 基础备份、WAL 归档、恢复副本 | 独立备份空间 |
|
||||
|
||||
## 资源配置建议
|
||||
|
||||
| 主机角色 | 数量 | 建议配置 | 备注 |
|
||||
|---|---:|---|---|
|
||||
| 内网 Nginx 入口节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 300 GB 存储 | 承载内网 Nginx、API 转发和内部负载均衡 |
|
||||
| 业务应用节点（主） | 2 台 | 32 核 CPU / 64 GB 内存 / 300 GB 存储 | 承载 Spring Boot Gateway 及表务、抄表、收费、账务、发票、报表等核心应用服务 |
|
||||
| 数据、中间件与文件存储综合节点 | 1 台 | 16 核 CPU / 32 GB 内存 / 2300 GB 存储 | 承载缓存、配置治理、数据库控制、图片、附件等非结构化数据 |
|
||||
| SFTP/FTP 文件交换服务器 | 1 台 | 2 核 CPU / 8 GB 内存 / 200 GB 存储 | 承载银行送盘、回盘、对账、归档文件交换，建议独立部署 |
|
||||
| PostgreSQL 主库服务器 | 1 台 | 24 核 CPU / 48 GB 内存 / 1 TB NVMe SSD | 生产写入节点，不计入上述已知 4 类业务主机 |
|
||||
| PostgreSQL 热备服务器 | 1 台 | 24 核 CPU / 48 GB 内存 / 1 TB NVMe SSD | 正式切换接管节点，不计入上述已知 4 类业务主机 |
|
||||
| 备份归档存储 | 1 套 | 可用空间 4 TB 至 6 TB | 存放全量备份与 WAL 归档 |
|
||||
|
||||
### 银行文件交换服务器容量估算
|
||||
|
||||
按 20 万用户、5 年保留期估算，银行文件交换服务器主要承载代扣、托收、对账等批次文件，不承载全量业务明细数据库。
|
||||
|
||||
估算依据如下：
|
||||
|
||||
1. 银行代扣、托收、对账文件以批次文件为主，不是每位用户每天形成独立文件。
|
||||
2. 按“仅覆盖银行代扣/托收用户，且按月批次送盘/回盘一次”的业务节奏估算，单个批次文件大小通常在 `10 MB ~ 40 MB` 量级。
|
||||
3. 按每月送盘、回盘、对账共 `3` 类核心文件估算，月文件量约为：
|
||||
- `30 MB ~ 120 MB / 月`
|
||||
4. 按 1 年估算，原始批次文件总量约为：
|
||||
- `0.36 GB ~ 1.44 GB / 年`
|
||||
5. 考虑归档副本、异常重传、中间文件和运行日志，按 `10 ~ 15` 倍放大后，5 年总量通常约为：
|
||||
- `20 GB ~ 110 GB`
|
||||
|
||||
因此，按最节约的一期规划，银行文件交换服务器可按 `2 核 CPU / 8 GB 内存 / 200 GB 存储` 配置满足送盘、回盘、对账文件交换与 5 年留存需要；如后续银行通道数量增加、并发文件交换增加或保留策略扩大，再扩容至 `4 核 / 8 GB / 500 GB` 即可。建议设置 `70%` 容量预警，并预留扩容机制。
|
||||
|
||||
## 资源审批汇总表
|
||||
|
||||
以下汇总表用于甲方进行主机、存储、网络及基础软件部署范围审批。
|
||||
|
||||
| 序号 | 资源名称 | 数量 | 规格 | 部署内容 | 用途说明 | 建议口径 |
|
||||
|---|---:|---:|---|---|---|---|
|
||||
| 1 | 内网 Nginx 入口节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 300 GB 存储 | Nginx、API 转发、内部负载均衡 | 我方统一内网接入入口 | 可利旧优先 |
|
||||
| 2 | 业务应用节点（主） | 2 台 | 32 核 CPU / 64 GB 内存 / 300 GB 存储 | Spring Boot Gateway、Spring Boot 核心业务服务 | 承载微服务接入与核心业务服务 | 现有资源纳入正式方案 |
|
||||
| 3 | 数据、中间件与文件存储综合节点 | 1 台 | 16 核 CPU / 32 GB 内存 / 2300 GB 存储 | Redis、Nacos、MinIO、HAProxy、PgBouncer、Patroni | 承载缓存、配置治理、数据库控制、图片、附件、导出文件等能力 | 现有资源纳入正式方案 |
|
||||
| 4 | SFTP/FTP 文件交换服务器 | 1 台 | 2 核 CPU / 8 GB 内存 / 200 GB 存储 | SFTP/FTP 服务、送盘/回盘/对账目录、归档目录 | 承载银行文件交换与目录隔离 | 按最节约一期规划建议新增或单独利旧 |
|
||||
| 5 | PostgreSQL 主库服务器 | 1 台 | 24 核 CPU / 48 GB 内存 / 1 TB NVMe SSD | PostgreSQL 16 Primary | 承载生产写入 | 建议单独配置 |
|
||||
| 6 | PostgreSQL 热备服务器 | 1 台 | 24 核 CPU / 48 GB 内存 / 1 TB NVMe SSD | PostgreSQL 16 Standby | 承载正式切换接管 | 建议单独配置 |
|
||||
| 7 | 备份归档存储 | 1 套 | 可用空间 4 TB 至 6 TB | 基础备份、WAL 归档、恢复副本 | 保障恢复与审计追溯 | 可利旧或新增存储空间 |
|
||||
|
||||
### 审批建议
|
||||
|
||||
1. 业务应用节点、综合节点、内网 Nginx 入口节点可优先按现有资源纳入实施范围。
|
||||
2. SFTP/FTP 文件交换服务器建议单独审批，以满足银行文件交换隔离和安全要求。
|
||||
3. PostgreSQL 主库与热备库建议作为单独审批项，避免与现有业务节点混部。
|
||||
4. 备份归档存储建议作为单独资源项审批，避免后期因备份空间不足影响正式上线。
|
||||
|
||||
## 基础软件与版本清单
|
||||
|
||||
| 类别 | 软件名称 | 建议版本 | 部署位置 | 说明 |
|
||||
|---|---|---|---|---|
|
||||
| 操作系统 | Linux 发行版 | openEuler 20.03+ / CentOS 7.9+ | 全部服务器 | 按甲方基础环境标准选定 |
|
||||
| 运行环境 | JDK | 17 | 业务应用节点 | Spring Boot 运行环境 |
|
||||
| 接入层 | Nginx | 1.20+ | 内网 Nginx 入口节点 | 内网 API 转发、内部负载均衡 |
|
||||
| 网关服务 | Spring Boot Gateway | 3.x | 业务应用节点 | 微服务集群统一接入 |
|
||||
| 业务服务 | Spring Boot | 3.x | 业务应用节点 | 核心业务服务框架 |
|
||||
| 银行文件交换 | SFTP/FTP 服务 | 稳定版 | SFTP/FTP 文件交换服务器 | 银行送盘、回盘、对账文件交换 |
|
||||
| 数据库 | PostgreSQL | 16 | 主库、热备库 | 主备数据库部署 |
|
||||
| 缓存 | Redis | 6.2+ | 综合节点 | 缓存、会话、轻量级消息能力 |
|
||||
| 配置中心 | Nacos | 2.x | 综合节点 | 配置治理与注册管理 |
|
||||
| 对象存储 | MinIO | RELEASE 稳定版 | 综合节点 | 图片、附件、导出文件存储 |
|
||||
| 数据库代理 | HAProxy | 2.x | 综合节点 | 数据库读写入口代理 |
|
||||
| 连接池 | PgBouncer | 1.2x+ | 综合节点 | 统一数据库连接池 |
|
||||
| 高可用控制 | Patroni | 稳定版 | 综合节点 | 主备状态管理与切换 |
|
||||
|
||||
## 部署方式说明
|
||||
|
||||
### 总体部署原则
|
||||
|
||||
本方案的部署方式遵循以下原则：
|
||||
|
||||
1. 入口代理类组件优先采用 `Docker` 部署，并可优先评估 `host` 网络模式。
|
||||
2. 业务应用优先采用 `Docker` 部署，但不建议使用 `host` 网络模式。
|
||||
3. 数据库主备优先采用物理机或虚拟机直接部署，不建议容器化承载 PostgreSQL 主备本体。
|
||||
4. 数据库控制组件如需容器化，应优先选择轻量代理组件容器化，高可用控制组件仍以直接部署为优先。
|
||||
|
||||
### 组件部署方式建议
|
||||
|
||||
| 组件 | 部署节点 | 建议部署方式 | 是否建议 `host` 模式 | 说明 |
|
||||
|---|---|---|---|---|
|
||||
| 内网 Nginx | 内网 Nginx 入口节点 | Docker 部署 | 是，优先建议 | 作为我方统一接入入口，便于端口管理与转发 |
|
||||
| Spring Boot Gateway | 业务应用节点（主） | Docker 部署 | 否 | 作为微服务统一接入入口，建议与业务服务同节点部署 |
|
||||
| Spring Boot 应用 | 业务应用节点（主） | Docker 部署 | 否 | 便于发布、回滚、扩容，保留容器网络隔离 |
|
||||
| SFTP/FTP 服务 | SFTP/FTP 文件交换服务器 | 物理机/虚拟机直接部署 | 否 | 作为银行文件交换专用服务，建议独立部署并做目录隔离 |
|
||||
| Redis | 综合节点 | Docker 部署 | 可选 | 可采用普通容器网络，必要时可评估 `host` |
|
||||
| Nacos | 综合节点 | Docker 部署 | 可选 | 默认容器网络即可，便于配置治理 |
|
||||
| HAProxy | 综合节点 | Docker 部署 | 是，优先建议 | 作为数据库代理入口，适合 `host` 模式 |
|
||||
| PgBouncer | 综合节点 | Docker 部署 | 是，优先建议 | 作为数据库连接池入口，适合 `host` 模式 |
|
||||
| Patroni | 综合节点 | 物理机/虚拟机直接部署 | 否 | 建议与系统服务集成，便于运维与切换控制 |
|
||||
| MinIO | 综合节点 | Docker 部署 | 否 | 更关注数据盘挂载与对象存储目录管理 |
|
||||
| PostgreSQL 主库 | 主库服务器 | 物理机/虚拟机直接部署 | 否 | 核心数据库本体不建议容器化 |
|
||||
| PostgreSQL 热备 | 热备服务器 | 物理机/虚拟机直接部署 | 否 | 高可用数据库本体不建议容器化 |
|
||||
|
||||
### 优先采用 Docker 且可使用 `host` 模式的组件
|
||||
|
||||
结合当前资源结构，建议优先采用 `Docker + host` 模式的组件如下：
|
||||
|
||||
1. `内网 Nginx`
|
||||
2. `HAProxy`
|
||||
3. `PgBouncer`
|
||||
|
||||
采用 `host` 模式的主要原因如下：
|
||||
|
||||
1. 直接监听固定服务端口，减少端口映射复杂度。
|
||||
2. 更便于与主机防火墙、域名、VIP、健康检查配合。
|
||||
3. 对于入口类与代理类组件，运维体验更接近直接部署。
|
||||
|
||||
### 不建议采用 `host` 模式的组件
|
||||
|
||||
以下组件不建议采用 `Docker + host` 模式：
|
||||
|
||||
1. `Spring Boot` 业务应用：应保留容器网络隔离，便于扩容和端口治理。
|
||||
2. `MinIO`：应以存储挂载与数据目录管理为重点，不依赖 `host` 模式。
|
||||
3. `PostgreSQL 主库 / 热备`：数据库本体优先直接部署，不建议容器化。
|
||||
4. `Patroni`：建议直接部署，便于与数据库高可用控制链路协同。
|
||||
|
||||
## 网络需求
|
||||
|
||||
### 1. 网络分区要求
|
||||
|
||||
| 网络分区 | 部署对象 | 访问要求 |
|
||||
|---|---|---|
|
||||
| 公网接入区 | 公网入口薄转发 | 对外提供 HTTPS 访问，不纳入我方主机资源 |
|
||||
| 应用区 | 业务应用节点 | 仅允许内网接入区与运维区访问 |
|
||||
| 中间件与文件存储区 | Redis、Nacos、MinIO、数据库控制组件 | 仅允许业务应用节点与运维区访问 |
|
||||
| 银行文件交换区 | SFTP/FTP 文件交换服务器 | 仅允许业务应用节点、银行专线或授权外联链路访问 |
|
||||
| 数据区 | PostgreSQL 主库、热备库、备份存储 | 严格限制，仅允许中间件控制主机和运维区访问 |
|
||||
|
||||
### 2. 带宽与时延要求
|
||||
|
||||
| 网络链路 | 建议要求 | 说明 |
|
||||
|---|---|---|
|
||||
| 公网入口薄转发到内网 Nginx | 千兆网络 | 满足公网入口转发 |
|
||||
| 内网 Nginx 到业务应用 | 千兆网络 | 满足开放 API 转发与网关接入 |
|
||||
| 业务应用到综合节点 | 千兆网络 | 满足缓存、配置治理、文件访问与数据库代理访问 |
|
||||
| 业务应用到 SFTP/FTP 服务器 | 千兆网络 | 满足送盘、回盘、对账文件交换 |
|
||||
| 银行链路到 SFTP/FTP 服务器 | 千兆网络或专线 | 满足银行文件交换与目录投递 |
|
||||
| 综合节点到数据库 | 千兆网络以上 | 满足数据库代理与健康检查 |
|
||||
| 主备复制链路 | 不低于 10 Gbps | 支撑同步复制 |
|
||||
| 同城主备时延 | 建议低于 2 ms | 支撑稳定同步复制 |
|
||||
| 数据库到备份存储 | 千兆网络以上 | 满足基础备份与 WAL 归档传输 |
|
||||
| 综合节点到备份存储 | 千兆网络以上 | 满足文件数据备份与归档传输 |
|
||||
|
||||
### 3. 网络开通要求
|
||||
|
||||
| 类别 | 开通要求 | 说明 |
|
||||
|---|---|---|
|
||||
| 对外访问 | 开通 443 端口 | 提供统一 HTTPS 入口 |
|
||||
| 公网入口薄转发访问内网 Nginx | 开通公网入口到内网 Nginx 的转发端口 | 仅授权链路访问 |
|
||||
| 内网 Nginx 访问应用 | 开通内网 Nginx 到业务应用的 API / 网关端口 | 仅内网访问 |
|
||||
| 应用访问综合节点 | 开通 Redis、Nacos、MinIO、PgBouncer 相关端口 | 仅应用区访问 |
|
||||
| 业务应用访问 SFTP/FTP 服务器 | 开通 SFTP/FTP 相关端口 | 用于银行文件送盘、回盘、对账交换 |
|
||||
| 银行链路访问 SFTP/FTP 服务器 | 开通 FTP/SFTP 服务端口 | 仅银行授权链路访问 |
|
||||
| 综合节点访问数据库 | 开通 PostgreSQL 5432 及健康检查相关端口 | 仅综合节点访问 |
|
||||
| 运维访问 | 开通运维区到各层必要管理端口 | 用于巡检、发布、恢复、切换 |
|
||||
|
||||
## 网络开通清单
|
||||
|
||||
| 源区域/源主机 | 目标区域/目标主机 | 协议/端口 | 用途 | 开通要求 |
|
||||
|---|---|---|---|---|
|
||||
| 外部用户 | 公网入口薄转发 | HTTPS/443 | 页面访问、接口入口 | 对外开放 |
|
||||
| 公网入口薄转发 | 内网 Nginx 入口节点 | HTTP/HTTPS/转发端口 | 公网访问转入内网入口 | 授权链路放通 |
|
||||
| 内网 Nginx 入口节点 | 业务应用节点（主） | HTTP/HTTPS/网关端口 | 内网 API 转发与微服务接入 | 内网放通 |
|
||||
| 业务应用节点（主） | 综合节点 | TCP/6379 | Redis 访问 | 内网放通 |
|
||||
| 业务应用节点（主） | 综合节点 | TCP/8848 | Nacos 访问 | 内网放通 |
|
||||
| 业务应用节点（主） | 综合节点 | TCP/6432 | PgBouncer 访问 | 内网放通 |
|
||||
| 业务应用节点（主） | 综合节点 | TCP/9000,9001 | MinIO 文件访问 | 内网放通 |
|
||||
| 业务应用节点（主） | SFTP/FTP 文件交换服务器 | TCP/21 或 22 | 银行送盘、回盘、对账文件交换 | 内网放通 |
|
||||
| 银行专线或授权外联链路 | SFTP/FTP 文件交换服务器 | TCP/21 或 22 | 银行文件目录投递与回收 | 仅授权链路放通 |
|
||||
| 综合节点 | PostgreSQL 主库服务器 | TCP/5432 | 数据库代理与控制访问 | 内网放通 |
|
||||
| 综合节点 | PostgreSQL 热备服务器 | TCP/5432 | 数据库代理、状态探测与控制访问 | 内网放通 |
|
||||
| PostgreSQL 主库服务器 | PostgreSQL 热备服务器 | TCP/5432 | 主备同步复制 | 高带宽、低时延专用链路 |
|
||||
| PostgreSQL 主库/热备库 | 备份归档存储 | TCP/存储协议端口 | 基础备份与 WAL 归档 | 内网放通 |
|
||||
| 综合节点 | 备份归档存储 | TCP/存储协议端口 | 文件归档与备份 | 内网放通 |
|
||||
| 运维管理终端 | 各节点 | SSH/22 及必要管理端口 | 运维、巡检、发布、恢复 | 仅运维区放通 |
|
||||
|
||||
## 访问控制与端口建议
|
||||
|
||||
| 服务 | 典型端口 | 访问范围 |
|
||||
|---|---|---|
|
||||
| Nginx/HTTPS | 443 | 对外开放 |
|
||||
| Spring Boot Gateway / 业务应用端口 | 项目自定义端口 | 仅内网 Nginx 与内网调用 |
|
||||
| Redis | 6379 | 仅业务应用与运维可访问 |
|
||||
| Nacos | 8848 | 仅业务应用与运维可访问 |
|
||||
| MinIO | 9000/9001 | 仅业务应用与运维可访问 |
|
||||
| SFTP/FTP 服务 | 21 或 22 | 仅业务应用节点、运维和银行授权链路可访问 |
|
||||
| PgBouncer | 6432 | 仅业务应用可访问 |
|
||||
| HAProxy | 5000 或项目定义端口 | 仅 PgBouncer 与运维可访问 |
|
||||
| PostgreSQL | 5432 | 仅数据库控制主机与运维可访问 |
|
||||
|
||||
## 实施步骤
|
||||
|
||||
### 1. 基础资源准备
|
||||
|
||||
1. 确认内网 Nginx 入口节点、业务应用节点、综合节点是否为利旧资源。
|
||||
2. 完成 SFTP/FTP 文件交换服务器、PostgreSQL 主库服务器、热备服务器及备份归档存储审批。
|
||||
3. 完成各网络分区、IP、域名、SSL 证书、路由及防火墙策略准备。
|
||||
|
||||
### 2. 基础软件安装
|
||||
|
||||
1. 安装操作系统并完成安全基线加固。
|
||||
2. 在业务应用节点安装 JDK、部署业务运行环境。
|
||||
3. 在内网 Nginx 入口节点安装 Nginx。
|
||||
4. 在综合节点安装 Redis、Nacos、HAProxy、PgBouncer、Patroni、MinIO。
|
||||
5. 在 SFTP/FTP 文件交换服务器安装 SFTP/FTP 服务并配置目录结构。
|
||||
6. 在数据库主备节点安装 PostgreSQL 16。
|
||||
|
||||
### 3. 数据库主备部署
|
||||
|
||||
1. 初始化 PostgreSQL 主库。
|
||||
2. 初始化 PostgreSQL 热备库并建立同步复制。
|
||||
3. 配置 Patroni、HAProxy、PgBouncer 联动。
|
||||
4. 配置基础备份与 WAL 归档。
|
||||
5. 配置业务应用节点到 SFTP/FTP 文件交换服务器的文件交换目录映射。
|
||||
|
||||
### 4. 应用与存储部署
|
||||
|
||||
1. 在业务应用节点部署 Spring Boot Gateway 和业务应用服务。
|
||||
2. 在内网 Nginx 入口节点配置 API 转发和内部负载均衡规则。
|
||||
3. 在综合节点初始化 MinIO 存储桶和访问策略。
|
||||
4. 在 SFTP/FTP 文件交换服务器配置送盘、回盘、对账、归档目录。
|
||||
5. 配置业务应用到 Redis、Nacos、PgBouncer、MinIO 的连接参数。
|
||||
|
||||
### 5. 联调与演练
|
||||
|
||||
1. 完成前后端联调。
|
||||
2. 完成中间件访问验证。
|
||||
3. 完成数据库主备同步验证。
|
||||
4. 完成文件上传、下载、归档验证。
|
||||
5. 完成主备切换演练与回切演练。
|
||||
|
||||
### 6. 上线准备与正式投产
|
||||
|
||||
1. 完成上线前巡检与问题清零。
|
||||
2. 确认监控、日志、备份、告警正常。
|
||||
3. 完成上线窗口审批。
|
||||
4. 按上线顺序切换生产流量。
|
||||
|
||||
## 验收标准
|
||||
|
||||
| 验收项 | 验收标准 | 说明 |
|
||||
|---|---|---|
|
||||
| 对外访问 | 用户可通过统一域名正常访问系统 | 公网入口薄转发与内网 Nginx 链路正常 |
|
||||
| 业务应用可用性 | 表务、抄表、收费、账务、发票、报表等核心服务正常 | 业务主流程可执行 |
|
||||
| Redis 可用性 | 缓存读写正常 | 中间件能力正常 |
|
||||
| Nacos 可用性 | 配置下发正常 | 配置治理能力正常 |
|
||||
| MinIO 可用性 | 图片、附件上传下载正常 | 文件存储能力正常 |
|
||||
| SFTP/FTP 文件交换 | 送盘、回盘、对账目录读写正常 | 银行文件交换能力正常 |
|
||||
| 数据库连接能力 | 业务应用可通过 PgBouncer 正常连接数据库 | 代理接入正常 |
|
||||
| PostgreSQL 主备同步 | 主备复制正常，无严重延迟 | 高可用基础正常 |
|
||||
| 数据库切换演练 | 主备切换成功，业务恢复正常 | 高可用能力可验证 |
|
||||
| 备份归档 | 基础备份与 WAL 归档正常 | 恢复能力可验证 |
|
||||
| 运维监控 | 关键节点监控、日志、告警正常 | 运维可观测性正常 |
|
||||
|
||||
## 部署结论
|
||||
|
||||
在已采纳 PostgreSQL 16 方案二作为数据库部署方案的前提下，建议福建水务营收系统采用“前后端分层部署 + 中间件集中部署 + 数据库主备分离部署”的整体部署模式。
|
||||
|
||||
本方案的最终结论如下：
|
||||
|
||||
1. 公网入口薄转发不纳入我方主机资源；我方实际部署的统一接入入口为内网 Nginx 入口节点。
|
||||
2. 2 台业务应用节点作为核心业务集群，节点内同时部署 Spring Boot Gateway 和业务服务，承接微服务统一接入与核心业务处理。
|
||||
3. 综合节点集中承载 Redis、Nacos、MinIO 及数据库控制组件，进一步压缩一期主机数量并降低部署复杂度。
|
||||
4. 新增 1 台 SFTP/FTP 文件交换服务器，作为银行送盘、回盘、对账文件交换专用前置机。
|
||||
5. PostgreSQL 16 采用同城双可用区 1 主 1 热备部署，满足高可用要求。
|
||||
6. 网络采用公网接入区、内网接入区、应用区、中间件与文件存储区、银行文件交换区、数据区分层隔离模式，以满足安全性、可维护性和资源审批要求。
|
||||
BIN
output/08_Integrated_Deployment_Design_PlanB_含图表.docx
Normal file
BIN
output/08_Integrated_Deployment_Design_PlanB_含图表.docx
Normal file
Binary file not shown.
Loading…
x
Reference in New Issue
Block a user