智慧场馆解决方案系统开发实战：从架构设计到落地指南

智慧场馆的核心并非堆砌硬件，而是通过一套可扩展的软硬一体系统，将场地预订、赛事组织、会员服务与实时音视频能力整合到同一个平台上。本文从技术选型到部署上线，拆解一套真正可落地的智慧场馆解决方案的开发路径。文中涉及的技术栈与模块划分参考了台球赛事报名、约球系统、共享棋牌室及视频直播类项目的通用实现方案，可作为实际开发时的参考基线。

一、系统架构设计：从单体到微服务的务实选择

在智慧场馆系统的架构设计上，并不建议一上来就拆分微服务。多数场馆场景（如台球厅、棋牌室、羽毛球馆）的并发量级在初期处于几百到几千QPS之间，采用模块化单体架构配合缓存与消息队列，是性价比、运维成本的方案。

整体架构可拆分为四层：

• 接入层：Nginx + HTTPS证书，负责反向代理与静态资源缓存；WebSocket用于推送实时状态。
• 应用层：Spring Boot 2.7+ 作为核心框架，按业务域拆包（如 event、booking、live、user），而非拆服务。
• 数据层：MySQL 8.0存储业务数据，Redis 7.x处理热点数据（场地状态、在线人数、登录令牌）。
• 外部服务层：腾讯云TRTC、对象存储COS、短信服务，分别承载直播、赛事图片/视频存储、验证码发送。

// 应用层包结构示例
com.smartvenue
├── controller        // 接口层
├── service           // 业务逻辑
├── mapper            // MyBatis Plus 数据访问
├── entity            // 数据表实体
├── config            // Redis、WebSocket、TRTC配置
└── common            // 统一返回体、异常处理、工具类

对于小型共享场馆（无人棋牌室、茶室），可省去消息队列，直接用Redis发布订阅（Pub/Sub）联动门禁与订单状态；而大型综合体育场馆若有多个子场馆（游泳、篮球、羽毛球）独立计费，则需要引入 RabbitMQ 异步处理订单超时关闭与对账任务。

二、后端核心模块设计：预约、赛事与直播的融合

智慧场馆系统后端典型的三类模块是场地预约、赛事管理和视频直播，三者可以共用同一套用户体系与权限模型。

场地预约模块的状态机是重点。一张场地从“空闲”到“已锁定”（用户下单未支付）再到“已预订”（支付完成），后转为“使用中”或“已完成”。为了避免并发超卖，使用Redis分布式锁控制每个场地的预订操作：

public Boolean createBooking(BookingRequest req) {
    String lockKey = "venue:lock:" + req.getVenueId() + ":" + req.getTimeSlot();
    RLock lock = redissonClient.getLock(lockKey);
    boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS);
    try {
        if (!locked) return false;
        // 校验场地状态、生成订单、扣减库存
        return bookingService.create(req);
    } finally {
        if (lock.isHeldByCurrentThread()) lock.unlock();
    }
}

赛事管理模块可参考台球赛事报名系统的模型：赛事（Event）作为主实体，包含报名时段、赛制类型、参赛人数上限；报名记录（Enrollment）作为从实体，关联用户和赛事。赛事编排算法（如淘汰赛、循环赛）可单独抽成策略类，便于后续扩展不同体育项目。

视频直播模块若复用共享棋牌室和直播APP的技术方案，后台用Spring Boot生成TRTC的临时签名（UserSig），前端拿到签名后直接拉取低延迟流。后台只负责房间管理、录制回放与连麦成员校验，不直接处理音视频数据，从而大幅降低服务器带宽压力。

三、多端用户端方案：UniApp 的跨端适配与性能优化

用户端（C端）统一采用UniApp（Vue 3语法），一套代码同时输出H5、小程序和APP。知识库中多个系统的用户端均采用该方案，实践中需要注意以下三个关键点：

1. 条件编译处理平台差异：小程序不支持DOM操作，H5需要适配。在不同页面处理好支付（支付 vs 支付宝）、订阅消息（小程序）与App推送（极光/个推）的差异。
2. 长列表渲染优化：赛事列表或场地列表中，一次性加载几十条数据即可，超过50条必须分页。下拉刷新时使用onPullDownRefresh生命周期配合防抖，而非监听scroll事件。
3. 音视频组件隔离：直播和连麦功能使用TRTC插件，通过<trtc-room>组件嵌入。在APP端使用原生渲染，在H5端使用WebRTC。注意，UniApp环境下音视频组件需单独构建，不能用普通Vue组件代替。

用户端和管理端的登录入口必须分离。普通用户、师傅/教练端（服务提供方）、管理端是三个不同的角色体系，权限控制落在后端JWT令牌的role字段中。教练端可查看授课排班、接单；管理端拥有全量数据权限。

四、管理后台与运维部署：从开发到上线的后一步

部署环节需避免直接在服务器上手动打Jar包。推荐使用Docker Compose编排所有依赖：

version: "3.8"
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: 你的密码
      MYSQL_DATABASE: smart_venue
    volumes:
      - ./mysql/data:/var/lib/mysql
    ports:
      - "3306:3306"
  redis:
    image: redis:7.0
    ports:
      - "6379:6379"
  backend:
    build: ./backend
    ports:
      - "8080:8080"
    depends_on:
      - mysql
      - redis
  nginx:
    image: nginx:1.24
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./dist:/usr/share/nginx/html
      - ./nginx/conf.d:/etc/nginx/conf.d

开发交付时，必须附带三份文档：技术文档（接口文档、数据库ER图、模块说明）、资料准备文档（申请小程序AppID、TRTC服务开通、域名SSL证书、短信签名）、部署文档（服务器环境要求、Docker安装步骤、初始化脚本执行顺序、Nginx配置示例）。这与知识库中多个系统的交付标准一致，确保接手方能自主运维。

数据库脚本需在部署文档中明确标注执行顺序，例如先建库（create_database.sql）、再建表（schema.sql）、后执行初始化数据（data.sql）。敏感配置（数据库密码、TRTC密钥）通过环境变量注入，不要写死在配置文件里，以免源码泄露后造成安全隐患。

五、FAQ 常见问题解答

问题1：智慧场馆系统必须接入硬件设备吗？
不需要一开始就做硬件对接。初期先用门禁（共享棋牌室/茶室已有成熟方案），后续通过预留的设备控制接口（设备ID + 动作指令）扩展接入智能灯控、门锁和空调，系统不必为此改动架构。

问题2：赛事报名和场地预约能否共用一套登录体系？
可以。用户表设计时增加user_type字段（普通用户、教练、管理员），赛事报名和场地预约都关联同一张用户主表。不要在两张表里各存一份用户信息，否则报名后无法同步到约球系统。

问题3：直播模块是否必须使用TRTC？有没有更轻量的替代方案？
如果直播场景只是单路推流（如场馆监控回放、赛事录播），不需要连麦，使用普通的RTMP推流 + HLS拉流即可，服务器成本更低。但若涉及教练在线指导、赛事多机位切换，低延迟的WebRTC（TRTC）是更好的选择。

问题4：多场馆数据如何隔离？
在 venue 表中增加 merchant_id 字段（租户ID）。所有核心业务表（订单、场地、赛事）都带上该字段。查询时全局拦截器自动拼入merchant_id条件，避免每个Mapper重复写SQL。此方案足够支撑几百个场馆的租户隔离，无需引入独立的Saas中间件。

问题5：源码拿到后如何快速二次开发？
按技术文档找到对应模块的包路径，修改后重新打包镜像即可。若新增数据表，建议先用MyBatis Plus的代码生成器生成基础CRUD代码，再在Service层添加业务校验。避免直接在Controller中写SQL或业务逻辑，会破坏统一异常处理机制。