大兴区政府项目智慧餐厅架构与云资源配置建议

版本日期：2026-06-16

适用范围：大兴区一卡(脸)通智慧平台 / 大兴区政府项目。

本文参照北京城市副中心智慧餐厅最终架构方案编制，并按大兴区政府项目约 10000 人就餐规模对关键配置做适度增强。城市副中心项目按约 1500 人规模配置 9 台云主机和 OSS；大兴区政府项目本轮不增加服务器数量，仍按 9 台云主机规划，通过提升应用、数据库、缓存、生物识别和消息中间件配置来支撑更大服务人数。

1. 方案结论

大兴区政府项目建议采用与城市副中心一致的分区高可用架构：互联网区入口代理、政务外网区业务承载、数据库主备、缓存高可用、对象存储独立、生物识别独立、物联网消息中间件独立。

与城市副中心相比，大兴区政府项目的主要变化是：

• 服务器数量不增加，仍采用 9 台云主机：2 台互联网区应用服务器、2 台政务外网区应用服务器、2 台数据库服务器、1 台 Redis、1 台生物识别服务器、1 台 EMQX。
• 互联网区仍采用双 Nginx，规格从 2C/4G 提升到 4C/8G，入口带宽 300M 起步；如客户云平台允许，可提升到 500M。
• 政务外网区应用服务器仍为 2 台，规格从 16C/32G 提升到 24C/64G，承载在线业务、设备接口、定时任务、导入导出和报表。
• 数据库仍为 1 主 1 备，规格从 16C/32G 提升到 24C/64G，数据盘从 500G 提升到 1000G 起步。
• Redis 仍为 1 台，规格从 4C/8G 提升到 8C/16G，用于会话、热点缓存、接口限流、任务缓冲和分布式锁。
• 生物特征识别服务器仍为 1 台，规格从 8C/16G 提升到 16C/32G，支撑 10000 人人脸库和刷脸消费/核销。
• EMQX 仍为 1 台，规格从 8C/16G 提升到 16C/32G，支撑设备在线、心跳、消息下发和订单结算消息。
• OSS 从 1000G 起步提升到 2000G 起步，用于人脸照片、附件、图片、导入导出、备份和日志留存文件。

推荐云主机数量为 9 台。OSS、负载均衡、WAF、堡垒机、日志审计、数据库审计等云服务不计入云主机数量。

2. 依据文件

• /Users/lqt/work/项目/城市副中心/最终版本/北京城市副中心智慧餐厅技术方案-云资源配置方案20260609.docx
• /Users/lqt/work/项目/城市副中心/最终版本/附件1、机关事务云平台资源申请表20260615.xlsx
• https://zhctpmt.yyangpt.cn/zhctprompt/work/2026-06-04-city-subcenter-tech-solution/city-subcenter-final-architecture-20260615.md
• https://zhctpmt.yyangpt.cn/zhctprompt/work/2026-06-04-city-subcenter-tech-solution/README.md
• /Users/lqt/work/zhct/zhctprompt/work_store/daxing-crypto-assessment-20260611/final-answer.md

3. 规模差异与设计原则

设计原则：

1. 架构分区沿用城市副中心：互联网区只做入口代理，政务外网区承载业务，数据与中间件不暴露到互联网区。
2. 容量扩展不按人数线性堆机器，本轮优先增强高峰敏感组件的配置：应用服务器、数据库、缓存、生物识别、消息中间件和对象存储。
3. 在线交易、批量任务和导入导出先共用政务外网应用服务器，通过任务调度、错峰执行、队列限流和报表导出窗口控制高峰影响；如压测不足，再拆分任务服务器。
4. 设备通讯和移动访问分离，设备端经政务外网负载均衡和 EMQX，移动端和工商银行接口经互联网区负载均衡和 Nginx。
5. 生产库、缓存、对象存储、生物识别、消息中间件均仅允许政务外网区授权服务器访问。

4. 推荐资源清单

云主机数量：

2 台互联网区应用服务器
+ 2 台政务外网区应用服务器
+ 2 台数据库服务器
+ 1 台 Redis 缓存服务器
+ 1 台生物特征识别服务器
+ 1 台物联网消息中间件服务器
= 9 台云主机

5. 部署架构

flowchart LR
  subgraph Access["访问与外部侧"]
    User["就餐人员 / 管理人员
微信小程序 / 公众号H5 / 管理后台"]
    Bank["工商银行业务系统
充值 / 查询 / 对账"]
    Device["现场设备
消费机 / 点餐机 / 称重台 / 一体机"]
  end

  subgraph Internet["互联网区"]
    ILB["互联网区负载均衡
固定IP / 300M起步 / WAF / HTTPS证书"]
    N1["Nginx-1
4C/8G
HTTPS反向代理"]
    N2["Nginx-2
4C/8G
HTTPS反向代理"]
  end

  subgraph Gov["政务外网区"]
    GLB["政务外网负载均衡
固定IP / 300M起步 / 设备入口"]
    APP1["应用服务器-1
24C/64G"]
    APP2["应用服务器-2
24C/64G"]
    BIO["生物识别服务器
16C/32G"]
    MQTT["物联网消息中间件服务器
16C/32G
EMQX"]
  end

  subgraph Data["数据与存储区"]
    DB1["南大通用 GBase 主库
24C/64G / 1TB数据盘"]
    DB2["南大通用 GBase 备库
24C/64G / 1TB数据盘"]
    Redis["Redis缓存
8C/16G"]
    OSS["OSS对象存储
2000G起步"]
  end

  User -->|HTTPS 443| ILB
  Bank -->|业务接口 HTTPS| ILB
  ILB --> N1
  ILB --> N2
  N1 -->|内网反向代理| APP1
  N1 -->|内网反向代理| APP2
  N2 -->|内网反向代理| APP1
  N2 -->|内网反向代理| APP2

  Device -->|设备业务接口| GLB
  GLB --> APP1
  GLB --> APP2

  APP1 --> DB1
  APP2 --> DB1
  DB1 -->|主备同步| DB2

  APP1 --> Redis
  APP2 --> Redis
  APP1 --> OSS
  APP2 --> OSS

  APP1 -->|人脸注册/识别/删除| BIO
  APP2 -->|人脸注册/识别/删除| BIO

  APP1 -->|发布MQTT消息/查询设备状态| MQTT
  APP2 -->|发布MQTT消息/查询设备状态| MQTT
  Device <-->|MQTT 1883 或安全端口| MQTT

6. 业务访问链路

6.1 微信小程序、微信公众号 H5、管理后台链路

微信小程序 / 微信公众号 H5 / 管理后台
  -> 互联网区负载均衡
  -> 互联网区 Nginx-1 / Nginx-2
  -> 政务外网区应用服务器 1-2
  -> 南大通用 GBase / Redis / OSS / 生物识别服务 / EMQX

互联网区服务器只部署 Nginx、HTTPS/国密 SSL 证书和反向代理能力，不承载核心业务数据，不部署数据库、Redis、EMQX 和人脸 SDK。

6.2 工商银行充值链路

工商银行业务系统
  -> 互联网区负载均衡
  -> 互联网区 Nginx-1 / Nginx-2
  -> 政务外网区应用服务器 1-2
  -> 平台业务校验、充值订单处理、支付结果处理、对账/异常处理
  -> 南大通用 GBase 主库

大兴区项目仍按业务接口请求转发处理，不设置平台前置库、工商银行前置库和交换库。

6.3 设备端链路

消费机 / 点餐机 / 称重台 / 一体机
  -> 政务外网负载均衡
  -> 政务外网区应用服务器 1-2
  -> 消费、核销、订单结算和数据落库

设备 MQTT 通讯
  -> EMQX 消息中间件服务器
  <-> 应用服务器发布人员、人脸、卡、排菜、订单结算消息

设备接入建议同时保留 HTTP 接口和 MQTT 消息能力。交易类请求按幂等流水号、设备编号、接口账号、接口密钥、时间戳和签名控制；消息类请求按 Topic、QoS、回执、重试和消息日志控制。

6.4 生物识别链路

政务外网区应用服务器
  -> 生物识别服务器内部 API
  -> 百度人脸离线 SDK 或客户确认的人脸识别服务
  -> 返回识别结果、特征值、注册/删除结果

大兴区项目不做人脸识别登录。人脸能力仅用于刷脸消费、刷脸核销和人员人脸资料维护。

6.5 批量任务与报表链路

政务外网区应用服务器
  -> 定时任务 / 补贴 / 对账 / 批量同步 / 导入导出 / 报表
  -> 南大通用 GBase 主库
  -> OSS 保存导出文件、附件和备份文件

大兴区 10000 人规模下，人员导入、人脸照片批量处理、补贴发放、银行对账、消费明细导出和统计报表需要控制执行窗口。9 台服务器口径下，批量任务先部署在政务外网区应用服务器，通过错峰调度、队列限流、导出文件异步生成和报表缓存降低对就餐高峰的影响。

7. 访问权限策略

8. 安全与合规策略

9. 与城市副中心资源差异

10. 压测后扩容预案

本方案按 9 台云主机作为首期资源申请口径。上线前和试运行期应通过压测和运行监控决定是否扩容，而不是在申请阶段一次性扩大到 18 台。

11. 待确认事项

1. 大兴区实际设备数量、设备类型、设备网段、是否全部支持 MQTT。
2. 就餐高峰分布：早餐、午餐、晚餐的峰值时段和最大同时交易量。
3. 南大通用 GBase 的具体版本、兼容模式、服务端口、主备同步方式和备份策略需要与客户云平台确认。
4. 东方通适配范围：是否使用 TongWeb/TongRDS/TongLINK/Q 等中间件；如要求单独服务器，需要另行调整资源口径。
5. 人脸识别服务是否继续使用百度离线 SDK，授权容量是否覆盖 10000 人；单台 16C/32G 是否能通过刷脸峰值压测。
6. 工商银行接口 QPS、重试、对账频率、白名单、证书和签名验签要求。
7. 日志留存周期：操作日志、交易日志、设备日志、人脸识别日志和审计日志是 90 天、180 天还是 1 年。
8. OSS 是否可用；如果不能使用对象存储，需要改为独立文件服务器或 NAS，并重新测算容量和备份策略。
9. 是否需要同城灾备或异地备份；本方案当前为同机房/同云资源池高可用。
10. 负载均衡、WAF、堡垒机、日志审计、数据库审计、主机安全、漏洞扫描由客户云平台提供还是项目侧申请。

12. 确定性部署口径

• 互联网区服务器只承载 Nginx、HTTPS/国密 SSL 证书和反向代理，不承载业务数据库、Redis、EMQX、人脸 SDK 和核心业务数据。
• 政务外网应用服务器承载在线业务接口、设备接口、管理后台接口、移动端接口、定时任务、导入导出和报表任务。
• 9 台服务器为首期资源口径；批量任务通过错峰、队列限流和导出缓存降低对在线交易的影响，压测不足时再拆分任务服务器。
• 数据库采用主备高可用架构，核心业务数据统一写入主库并同步到备库。
• Redis 首期按单台增强规格部署，用于会话、热点缓存、限流、任务缓冲和分布式锁；压测不足时再升级高可用。
• OSS 对象存储独立承载图片、附件、导入导出文件、备份文件和审计留存文件。
• 生物特征识别服务器独立承载人脸识别能力，仅向政务外网应用服务器提供内网 API。
• EMQX 首期按单台增强规格独立承载设备 MQTT 通讯，向应用服务器和现场设备提供消息通道；设备规模或消息峰值不足时再扩展集群。
• 所有运维访问通过堡垒机统一进入，所有服务器纳入日志审计、主机安全、漏洞扫描、备份恢复和安全巡检范围。