SpringBoot+Vue旅游网站开发全流程实战

1. 项目概述

最近刚完成了一个基于SpringBoot的旅游网站项目，从需求分析到最终部署上线，踩了不少坑也积累了不少经验。这个系统整合了景点信息、酒店预订、美食推荐、游记分享等核心功能模块，采用前后端分离架构，前端使用Vue.js+Element UI，后端基于SpringBoot+MyBatis实现。下面我就从技术选型、核心功能实现、数据库设计、部署优化等方面，详细分享这个项目的开发历程。

提示：这个项目特别适合需要快速开发旅游类系统的开发者参考，包含了从零搭建到生产部署的全流程经验。

2. 技术架构设计

2.1 技术栈选型考量

选择SpringBoot作为后端框架主要基于以下几个实际考量：

1. 快速开发：SpringBoot的自动配置和起步依赖特性，让我们在两周内就搭建起了基础框架。比如通过简单的spring-boot-starter-web依赖就自动配置好了Tomcat和Spring MVC。

2. 微服务友好：考虑到后期可能扩展为微服务架构，SpringBoot天然支持Spring Cloud生态，迁移成本低。我们在配置中预留了服务注册发现的接口。

3. 生产就绪：内置的健康检查、指标监控等功能，大大减少了运维工作量。通过/actuator端点可以实时查看应用状态。

前端选择Vue.js+Element UI组合，主要看中：

• 组件化开发效率高，一个景点卡片组件可以在多个页面复用
• Element UI的表格、表单等组件完美适配后台管理系统需求
• 相比React学习曲线更平缓，团队上手快

2.2 系统架构图

code复制[前端层]
  ├── 用户门户(Vue.js)
  └── 管理后台(Element UI)
  
[网关层]
  └── Spring Cloud Gateway(预留)
  
[服务层]
  ├── 用户服务
  ├── 景点服务 
  ├── 订单服务
  └── 内容服务
  
[数据层]
  ├── MySQL(主业务数据)
  └── Redis(缓存+会话)

虽然当前是单体架构，但代码层面已经做了模块化拆分，为后续微服务化预留了扩展点。

3. 核心功能实现

3.1 景点模块设计

景点模块是系统的核心，采用了经典的三层架构：

Controller层处理前端请求，关键代码示例：

java复制@RestController
@RequestMapping("/attraction")
public class AttractionController {
    
    @Autowired
    private AttractionService attractionService;
    
    @GetMapping("/search")
    public Result<List<AttractionVO>> search(
            @RequestParam String keyword,
            @RequestParam(defaultValue = "1") Integer page,
            @RequestParam(defaultValue = "10") Integer size) {
        return attractionService.search(keyword, page, size);
    }
}

Service层实现业务逻辑，包含：

• 景点信息管理
• 票价计算策略
• 推荐算法实现（基于用户历史行为）

DAO层使用MyBatis-Plus增强：

java复制public interface AttractionMapper extends BaseMapper<Attraction> {
    @Select("SELECT * FROM attraction WHERE status = 1 ORDER BY heat DESC LIMIT #{limit}")
    List<Attraction> selectHotList(@Param("limit") int limit);
}

3.2 购票业务流程

典型的购票流程涉及分布式事务问题，我们采用最终一致性方案：

1. 前端提交订单请求
2. 系统创建预订单（状态为待支付）
3. 调用支付接口
4. 支付成功后修改订单状态
5. 异步更新景点余票

关键点在于使用Redis分布式锁防止超卖：

java复制public boolean createOrder(OrderDTO dto) {
    String lockKey = "attraction:" + dto.getAttractionId();
    try {
        // 获取分布式锁
        boolean locked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
        if (!locked) {
            throw new BusinessException("当前访问人数过多，请稍后再试");
        }
        
        // 检查库存
        Attraction attraction = attractionMapper.selectById(dto.getAttractionId());
        if (attraction.getStock() < dto.getQuantity()) {
            throw new BusinessException("库存不足");
        }
        
        // 扣减库存
        attractionMapper.updateStock(dto.getAttractionId(), dto.getQuantity());
        
        // 创建订单
        Order order = convertToOrder(dto);
        orderMapper.insert(order);
        return true;
    } finally {
        // 释放锁
        redisTemplate.delete(lockKey);
    }
}

4. 数据库设计与优化

4.1 主要表结构设计

景点表(attraction)

sql复制CREATE TABLE `attraction` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(100) NOT NULL COMMENT '景点名称',
  `type_id` int NOT NULL COMMENT '类型ID',
  `location` varchar(255) NOT NULL COMMENT '地理位置',
  `description` text COMMENT '详细描述',
  `price` decimal(10,2) NOT NULL COMMENT '基础价格',
  `stock` int NOT NULL DEFAULT '0' COMMENT '可售票数',
  `heat` int NOT NULL DEFAULT '0' COMMENT '热度',
  `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态(0下架1上架)',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_type` (`type_id`),
  KEY `idx_heat` (`heat`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表(order)

sql复制CREATE TABLE `order` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `user_id` bigint NOT NULL COMMENT '用户ID',
  `attraction_id` bigint NOT NULL COMMENT '景点ID',
  `quantity` int NOT NULL COMMENT '购买数量',
  `total_amount` decimal(10,2) NOT NULL COMMENT '总金额',
  `status` tinyint NOT NULL DEFAULT '0' COMMENT '状态(0待支付1已支付2已取消3已退款)',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user` (`user_id`),
  KEY `idx_attraction` (`attraction_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.2 性能优化实践

1. 读写分离：配置了主从复制，查询操作走从库
2. 缓存策略：
   • 景点详情使用Redis缓存，TTL设置为1小时
   • 热门景点列表缓存30分钟
3. SQL优化：
   • 避免SELECT *，只查询必要字段
   • 复杂查询使用EXPLAIN分析执行计划
   • 为常用查询条件添加合适索引

5. 部署与运维

5.1 生产环境部署

采用Docker Compose部署方案：

yaml复制version: '3'
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./mysql/data:/var/lib/mysql
      - ./mysql/conf:/etc/mysql/conf.d
    ports:
      - "3306:3306"
    
  redis:
    image: redis:6
    ports:
      - "6379:6379"
    volumes:
      - ./redis/data:/data
    
  backend:
    build: ./backend
    ports:
      - "8080:8080"
    depends_on:
      - mysql
      - redis
    environment:
      SPRING_PROFILES_ACTIVE: prod

5.2 监控配置

1. Spring Boot Actuator：暴露健康检查端点
2. Prometheus + Grafana：监控JVM指标、接口QPS
3. ELK：收集和分析日志

6. 踩坑经验分享

1. 分布式Session问题：初期使用Tomcat Session导致多实例间数据不一致，最终改用Redis存储Session。

2. 缓存穿透：针对不存在的景点ID大量查询，我们采用布隆过滤器+空值缓存的组合方案。

3. 支付超时处理：对接第三方支付时，设置合理的超时时间（建议15-30秒），并实现自动查询补偿机制。

4. 图片存储：初期直接存数据库导致性能低下，后来改为对象存储（MinIO）+CDN加速。

重要提示：在开发支付功能时，一定要做好对账系统，我们曾经因为网络问题导致支付状态不同步，造成了资金损失。

7. 系统界面展示

虽然不能直接贴图，但可以描述几个典型界面设计要点：

1. 景点列表页：

   • 采用卡片式布局
   • 支持按距离、热度、价格排序
   • 智能搜索框支持关键词联想

2. 订单详情页：

   • 明确显示订单状态流转
   • 集成地图显示景点位置
   • 倒计时显示支付剩余时间

3. 后台管理系统：

   • 基于Element UI的表格+表单组合
   • 数据看板展示关键指标
   • 支持Excel导入导出

这个项目从零开始到上线历时3个月，期间遇到了各种技术挑战，但最终成功支撑了日均5万的访问量。最大的体会是：旅游系统的核心在于数据的准确性和服务的稳定性，特别是在节假日流量高峰时，完善的监控和弹性扩容机制至关重要。