diff --git a/docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md b/docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md
new file mode 100644
index 0000000..45f2cd3
--- /dev/null
+++ b/docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md
@@ -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. 网络采用公网接入区、内网接入区、应用区、中间件与文件存储区、银行文件交换区、数据区分层隔离模式，以满足安全性、可维护性和资源审批要求。
diff --git a/output/08_Integrated_Deployment_Design_PlanB_含图表.docx b/output/08_Integrated_Deployment_Design_PlanB_含图表.docx
new file mode 100644
index 0000000..ffac4ff
Binary files /dev/null and b/output/08_Integrated_Deployment_Design_PlanB_含图表.docx differ