docs: split plan b deployment guidance from pg16 dr application

docs/design/00_Management/01_Project_Progress.md

@@ -116,7 +116,7 @@
 
 > 说明：本表中的历史记录按当时原始表述保留；当前正式数据库口径统一以“达梦数据库 8.0+”为准。
 
-| 2026-03-24 | PostgreSQL 16 容灾资源申请专题新增 | 1）新增 `docs/design/03_Technical_Design/07_PostgreSQL16_DR_Resource_Application.md`，形成面向甲方的独立资源申请说明；2）明确单中心主备、同城双可用区、同城双中心+异地灾备、主备+PITR 四类容灾形态；3）补充备库作为同步热备、同步温备、异步热备、异步温备、异地灾备时的 CPU、内存、存储资源配比建议；4）补充资源申请清单、网络与存储要求、部署实施说明、切换与恢复要求；5）补充 `Patroni + HAProxy + PgBouncer` 代理接入架构、配置样例与主备切换接入逻辑说明；6）补充计划切换、故障切换、回切、切换前检查表与切换后验证表。 | 用户希望形成独立文档，用于向甲方申请 PostgreSQL 16 容灾资源，并明确多种部署形态、备库资源比例、代理搭建方式、切换方式和部署方式。 | 正面影响，仓库内新增了一份可独立提交、可直接用于资源审批沟通的数据库容灾专题文档；后续可在不改动数据库主文档主口径的前提下，为 PostgreSQL 16 方案提供单独的申请依据、代理建设建议、切换实施细则与实施说明。 |
+| 2026-03-26 | 方案二整体部署方案独立成文 | 1）新增 `docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md`，将已采纳 PostgreSQL 16 方案二后的整体部署方案独立成文；2）结合当前前后端分层部署形态，补齐应用、数据库、中间件、静态存储的一体化部署结构；3）新增软件拓扑图、网络拓扑图、主机角色划分、资源配置建议、网络需求和端口访问建议；4）在 `07_PostgreSQL16_DR_Resource_Application.md` 增加独立文档引用说明，在技术专项目录增加入口。 | 用户明确要求不要仅在 `07` 文档内保留方案二内容，而是需要形成独立文件，并作为已采纳数据库方案后的整体部署方案提交评审。 | 正面影响，数据库资源申请专题与整体部署方案实现职责分离；后续甲方可分别评审“数据库容灾资源申请”和“系统整体部署方案”，减少口径混杂并提升部署审批的可读性。 |
 
 | 2026-03-18 | REV-005 统计模板补齐 | 1）在 `specs/002-rev005-invoice-flow/verification.md` 为 `T055`、`T060`、`T061`、`T062`、`T063` 新增可直接填写的样本记录模板；2）将 SC-001 ~ SC-004 的建议统计口径细化为表格字段与待补说明，避免后续只剩抽象待办；3）保持“模板已补齐但实际统计结果仍待联调/测试环境补录”的真实状态，不虚构样本结果。 | 用户继续推进 REV-005，希望把剩余统计类待办进一步收敛成可执行模板，便于后续直接补录真实样本而不是重新设计统计格式。 | 正面影响，REV-005 当前已具备统一的统计与日志抽样记录模板；后续补 `T055`、`T060 ~ T063` 时可直接按模板填充真实环境数据，减少再次整理验证文档结构的成本。 |
 | 2026-03-18 | REV-005 verify 执行入口补齐 | 1）在 `specs/002-rev005-invoice-flow/verification.md` 补齐 `/business/invoice/apply`、`/query`、`/query/compensate`、`/write-back`、`/customer/query`、`/customer/download`、`/customer/push`、`/invalidate`、`/red-ink` 的最小请求模板；2）继续补齐 `T055`、`T060 ~ T063` 的执行命令草稿与样本采集顺序，明确仅作为测试/联调环境占位模板，真实地址、鉴权信息、业务主键与统计结果均待后续替换和回填；3）同步 `03_Task_Checklist.md`，将 verify 阶段推进到“替换真实环境参数即可执行”的状态。 | 用户继续推进 REV-005，希望不要停留在抽象验证建议，而是把剩余 verify 工作推进到可直接执行、可直接补样本的程度。 | 正面影响，REV-005 当前已具备统一的验证入口、请求模板、命令草稿与采样顺序；后续在测试或联调环境中可直接替换参数发起请求并回填 `T055`、`T060 ~ T063` 的真实结果，减少重复梳理接口和命令的成本。 |

docs/design/00_Management/03_Task_Checklist.md

@@ -147,6 +147,8 @@
   - [x] 已补齐网络、存储、切换与恢复要求 ✅
   - [x] 已补齐 PostgreSQL 代理架构、`HAProxy` / `PgBouncer` 配置样例与应用接入建议 ✅
   - [x] 已补齐计划切换、故障切换、回切、检查表与验证表 ✅
+  - [x] 已将原方案二抽出为整体部署方案，补齐前端、后端、中间件、数据库、静态存储和网络需求 ✅
+  - [x] 已新增独立文档 `08_Integrated_Deployment_Design_PlanB.md`，沉淀已采纳方案二后的整体部署方案 ✅
 
 ### 📋 010-bank-transfer-config 银行文件传输配置能力
 

docs/design/03_Technical_Design/07_PostgreSQL16_DR_Resource_Application.md

@@ -28,14 +28,15 @@ retrieval_priority: P1
 4. 容灾形态说明
 5. 资源配比原则
 6. 推荐部署方案
-7. 甲方审批汇总表
-8. 详细资源申请清单
-9. 网络与存储要求
-10. 数据库代理与连接接入方案
-11. 部署实施说明
-12. 切换与恢复说明
-13. 切换实施细则
-14. 申请结论
+7. 方案二独立整体部署方案
+8. 甲方审批汇总表
+9. 详细资源申请清单
+10. 网络与存储要求
+11. 数据库代理与连接接入方案
+12. 部署实施说明
+13. 切换与恢复说明
+14. 切换实施细则
+15. 申请结论
 
 ## 编制目的
 
@@ -212,6 +213,185 @@ flowchart TD
 
 本项目建议优先向甲方申请方案 B；如甲方同时要求区域级灾难恢复能力，建议直接申请方案 C。
 
+## 方案二独立整体部署方案
+
+> 本节内容已独立沉淀为 `docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md`。如需评审“已采纳方案二后的整体部署方案”，以独立文档为准。
+
+### 方案定位
+
+本方案基于原“方案 B：正式生产推荐方案”进一步展开，作为适配当前福建水务营收系统前后端分层部署形态的独立整体部署方案。
+
+本方案的核心约束如下：
+
+1. 前端服务与后端服务保持分层部署。
+2. 中间件集中部署在 1 台主机上。
+3. 数据库控制组件与中间件部署在同一台主机上。
+4. 数据库采用同城双可用区主备架构。
+5. 静态存储采用 MinIO，并与中间件一并集中部署。
+
+### 适用场景
+
+本方案适用于以下场景：
+
+1. 当前项目已具备前端 Nginx + Vue3、后端 Spring Boot 的分层部署模式。
+2. 甲方希望在控制主机数量的前提下，完成应用层、数据库层、中间件层与静态存储层的整体建设。
+3. 甲方接受“中间件集中部署、数据库双节点容灾、前后端分层部署”的资源结构。
+
+### 整体部署拓扑
+
+```mermaid
+flowchart LR
+    subgraph CLIENT[访问入口]
+        U1[PC端用户]
+        U2[移动端用户]
+        U3[第三方系统]
+    end
+
+    subgraph LB[负载均衡层]
+        LB1[负载均衡/VIP]
+    end
+
+    subgraph FE[前端服务层]
+        FE1[前端服务器 1<br/>Nginx + Vue3]
+        FE2[前端服务器 2<br/>Nginx + Vue3]
+    end
+
+    subgraph BE[后端服务层]
+        BE1[后端服务器 1<br/>Spring Boot]
+        BE2[后端服务器 2<br/>Spring Boot]
+        BE3[后端服务器 3<br/>Spring Boot]
+        BE4[后端服务器 4<br/>Spring Boot]
+    end
+
+    subgraph MW[中间件与数据库控制层]
+        MW1[中间件服务器<br/>Redis + Nacos + MinIO<br/>HAProxy + PgBouncer + Patroni]
+    end
+
+    subgraph DBA[数据库可用区 A]
+        PG1[(PostgreSQL 16 主库)]
+    end
+
+    subgraph DBB[数据库可用区 B]
+        PG2[(PostgreSQL 16 同城热备库)]
+    end
+
+    CLIENT --> LB
+    LB --> FE
+    FE --> BE
+    BE --> MW1
+    MW1 --> PG1
+    MW1 --> PG2
+    PG1 -->|同步复制| PG2
+    PG1 --> BK[备份归档存储]
+    PG2 --> BK
+```
+
+### 主机角色划分
+
+| 层级 | 主机角色 | 数量 | 主要部署内容 | 说明 |
+|---|---|---:|---|---|
+| 负载均衡层 | 负载均衡/VIP | 1 组 | 统一访问入口、SSL 卸载、转发控制 | 对外统一入口 |
+| 前端服务层 | 前端服务器 | 2 台 | Nginx、Vue3 静态页面 | 承担 PC/H5 前端访问 |
+| 后端服务层 | 后端服务器 | 4 台 | Spring Boot 业务服务 | 承担营收、账务、表务、发票、银行等业务 |
+| 中间件层 | 中间件服务器 | 1 台 | Redis、Nacos、MinIO | 中间件集中部署 |
+| 数据库控制层 | 数据库控制服务器 | 与中间件同机 | HAProxy、PgBouncer、Patroni | 不单独新增主机，部署在中间件服务器上 |
+| 数据库层 | 主库服务器 | 1 台 | PostgreSQL 16 Primary | 部署在可用区 A |
+| 数据库层 | 热备服务器 | 1 台 | PostgreSQL 16 Standby | 部署在可用区 B |
+| 备份层 | 备份归档存储 | 1 套 | 基础备份、WAL 归档、恢复副本 | 独立存储空间 |
+
+### 部署说明
+
+#### 1. 前端部署
+
+1. 前端采用 2 台服务器部署 `Nginx + Vue3` 静态资源。
+2. 前端服务器不直接访问数据库，仅通过 HTTP/HTTPS 调用后端服务。
+3. 负载均衡层对前端节点做健康检查和请求分发。
+
+#### 2. 后端部署
+
+1. 后端采用 4 台 Spring Boot 应用服务器集群部署。
+2. 所有后端节点统一连接中间件与数据库控制主机暴露的数据库代理地址。
+3. 后端节点统一访问 Redis、Nacos 和 MinIO，不直接连接数据库主机 IP。
+
+#### 3. 中间件与静态存储部署
+
+1. 中间件统一部署在 1 台主机上。
+2. 中间件主机承载以下组件：
+   - Redis：缓存、会话、轻量级消息能力
+   - Nacos：配置中心、注册治理能力
+   - MinIO：静态文件与附件存储
+3. MinIO 作为本项目静态存储与对象存储统一入口，承接附件、票据文件、导出文件及其他静态资源。
+
+#### 4. 数据库控制组件部署
+
+1. 数据库控制组件不单独新增主机。
+2. `HAProxy`、`PgBouncer`、`Patroni` 与中间件部署在同一台主机。
+3. 后端应用通过该主机上的统一数据库代理地址访问 PostgreSQL 主备集群。
+4. 数据库切换时，由 Patroni 负责主备角色管理，由 HAProxy 完成入口切换，由 PgBouncer 完成连接池接管。
+
+#### 5. 数据库部署
+
+1. PostgreSQL 16 采用 1 主 1 热备模式。
+2. 主库与热备库分别部署在同城不同可用区或不同故障域。
+3. 主备之间采用同步复制，保障核心收费、账务、对账数据的一致性要求。
+4. 主库和热备库同时将基础备份与 WAL 归档写入备份归档存储。
+
+### 资源建议
+
+| 主机角色 | 数量 | 建议配置 | 备注 |
+|---|---:|---|---|
+| 前端服务器 | 2 台 | 8 核 CPU / 16 GB 内存 / 200 GB SSD | 支撑 Nginx 与静态页面发布 |
+| 后端服务器 | 4 台 | 16 核 CPU / 32 GB 内存 / 300 GB SSD | 对齐当前主文档后端服务集群口径 |
+| 中间件与数据库控制服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB SSD | 同机承载 Redis、Nacos、MinIO、HAProxy、PgBouncer、Patroni |
+| PostgreSQL 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 生产写入节点 |
+| PostgreSQL 热备服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 正式切换接管节点 |
+| 备份归档存储 | 1 套 | 可用空间 4 TB 至 6 TB | 存放全量备份与 WAL 归档 |
+
+### 网络需求
+
+#### 1. 网络分区建议
+
+| 网络分区 | 部署对象 | 访问要求 |
+|---|---|---|
+| 接入区 | 负载均衡、前端服务器 | 对外提供 HTTPS 访问 |
+| 应用区 | 后端服务器 | 仅允许接入区与运维区访问 |
+| 中间件区 | Redis、Nacos、MinIO、数据库控制组件 | 仅允许后端服务器与运维区访问 |
+| 数据区 | PostgreSQL 主库、热备库、备份存储 | 严格限制，仅允许中间件控制主机和运维区访问 |
+
+#### 2. 带宽与时延要求
+
+| 网络链路 | 建议要求 | 说明 |
+|---|---|---|
+| 前端到后端 | 千兆网络 | 满足业务访问与接口调用 |
+| 后端到中间件 | 千兆网络 | 满足缓存、配置、文件访问 |
+| 中间件控制主机到数据库 | 千兆网络以上 | 满足数据库代理与健康检查 |
+| 主备复制链路 | 不低于 10 Gbps | 支撑同步复制 |
+| 同城主备时延 | 建议低于 2 ms | 支撑稳定同步复制 |
+| 数据库到备份存储 | 千兆网络以上 | 满足基础备份与 WAL 归档传输 |
+
+#### 3. 端口与访问控制建议
+
+| 服务 | 典型端口 | 访问范围 |
+|---|---|---|
+| Nginx/HTTPS | 443 | 对外开放 |
+| 后端 HTTP/HTTPS | 项目自定义端口 | 仅前端与内网调用 |
+| Redis | 6379 | 仅后端与运维可访问 |
+| Nacos | 8848 | 仅后端与运维可访问 |
+| MinIO | 9000/9001 | 仅后端与运维可访问 |
+| PgBouncer | 6432 | 仅后端可访问 |
+| HAProxy | 5000 或项目定义端口 | 仅 PgBouncer 与运维可访问 |
+| PostgreSQL | 5432 | 仅数据库控制主机与运维可访问 |
+
+### 正式方案结论
+
+结合当前项目前后端部署形态，建议以本方案作为 PostgreSQL 16 正式生产推荐部署方案。其总体特点为：
+
+1. 前端与后端保持现有分层集群部署模式。
+2. 中间件与数据库控制组件集中部署在 1 台主机，控制主机数量。
+3. PostgreSQL 16 采用同城双可用区 1 主 1 热备部署，满足高可用要求。
+4. MinIO 作为静态存储统一入口，与中间件同机部署，便于统一运维。
+5. 网络上采用应用区、中间件区、数据区分层隔离，保障安全性与可维护性。
+
 ## 甲方审批汇总表
 
 以下汇总表用于甲方进行资源审批、预算评估和实施范围确认。建议优先按“方案 B：正式生产推荐方案”审批；如甲方同时要求区域级灾难恢复能力，可按“方案 C：正式生产增强方案”审批。

docs/design/03_Technical_Design/README.md

@@ -16,6 +16,7 @@
 - `02_Table_Specs.md`：单表规格补充（历史映射，非主口径）
 - `06_Sensitive_Data_Encryption.md`：敏感数据加密方案
 - `07_PostgreSQL16_DR_Resource_Application.md`：PostgreSQL 16 容灾与资源申请专题说明
+- `08_Integrated_Deployment_Design_PlanB.md`：采纳 PostgreSQL 16 方案二后的整体部署方案
 
 ## 维护原则