1. 为什么一个三线城市需要一套旅游资源管理系统先说个我接手这个项目前的实际场景。攀枝花这个地方旅游资源和大多数人的认知不太一样——你以为它只有钢铁和钒钛实际上它是典型的阳光康养目的地冬季平均气温在20℃上下有颛顼龙洞、二滩国家森林公园、攀西大裂谷、迤沙拉民族村落还有大量芒果、枇杷、石榴产业带形成的农业观光资源。问题恰恰出在资源多而散景区、酒店、农家乐、旅行社、餐饮商户各管各的游客到一个地方想吃想住想玩全靠现场打听信息烂在从业者手里根本触达不到有需求的游客。我当时接到的需求就是做一个面向游客和管理方双端的旅游资源管理系统。游客端能查景区、看攻略、订住宿、规划线路管理端能做资源录入、内容审核、订单统计。技术栈给定的是Spring Boot SSM数据库用MySQL前端要求能用Vue就上Vue不能用就服务端渲染。这个组合放到今天来看不算新潮但胜在生态成熟、团队上手快、部署成本低对于地市级文旅信息化项目来说是很务实的选择。这篇文章就把这个系统的设计思路、核心模块实现、开发中真实踩过的坑、以及部署上线的完整链路拆开讲透给正在做同类管理系统的朋友做个参考。整套系统我给它定位是轻量级、可落地、能迭代。轻量级意味着不引入太重的基础设施初期一台2核4G的云服务器就能跑起来可落地意味着每一个功能模块都要对应真实的业务动作不是堆功能给领导看演示能迭代意味着代码分层清楚、接口规范统一后续想加票务系统对接、民宿预订、旅行社分销都能在不推倒重来的前提下扩展。2. 技术选型的取舍逻辑Spring Boot SSM这个组合到底好在哪2.1 为什么不是Spring Cloud也不是JPA很多刚入行的朋友拿到这类项目第一反应是想上Spring Cloud全家桶注册中心、网关、配置中心一套下来听着很唬人。但你要想清楚一个问题一个地市级旅游管理系统高峰期并发可能也就是几百用户量级在十万以内你上微服务纯粹是给自己找麻烦——运维成本上来了排查问题复杂了团队里每个人都要会分布式那一套东西而实际的业务逻辑根本没复杂到需要拆服务。SSMSpring MVC Spring MyBatis在这个场景下是绝对够用的而且有几个实际的好处MyBatis对SQL的控制力强。旅游业务的查询条件变化特别频繁今天要多查一个是否含温泉明天要多筛一个距离市中心多少公里MyBatis的XML里写动态SQL改起来就是加一个if标签的事。JPA在复杂动态查询上要写Specification绕且不说性能调优的时候你要面对的是自动生成的SQL很难精准控制。Spring Boot的自动装配把SSM的配置成本降到了极低。传统SSM要写一大堆XML配置Spring Boot直接通过starter和application.yml搞定新手半天就能搭出可运行的项目骨架。部署运维简单。就是打一个jar包扔到服务器上跑不像微服务那样要管一堆进程、链路追踪、熔断降级一个小团队完全能维护。2.2 版本选择的实证经验Spring Boot我选了2.7.x不用3.x。原因很实在3.0开始强制要求JDK 17而大多数学校和企业服务器上跑的依然是JDK 8虽然也有迁过去的但MyBatis、druid、pagehelper这些配套组件在3.x初期都有兼容坑。2.7是2.x系列的最终版本社区积累足够多踩坑答案一搜就有属于最稳的旧版本。JDK用的8对应Spring Boot 2.7.18MyBatis用的3.5.xMyBatis-Spring-Boot-Starter用的2.3.xDruid连接池用的1.2.x。这一套组合我实测跑了半年没有任何因为版本导致的诡异问题。2.3 数据库选型为什么是MySQL 5.7而不是8.0按道理新项目应该直接上MySQL 8.0但在实际部署环境里遇到了一个很现实的问题服务器上已有的老库是5.7运维团队不想为了一个新系统单独维护两套MySQL版本。而且这个系统的数据量级5.7的InnoDB完全扛得住字符集统一utf8mb4排序规则utf8mb4_general_ci够用。要注意一个坑如果用的是MySQL 5.7连接串里最好显式加上useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8否则容易出现SSL握手失败和时区差8小时的问题。3. 业务模块的领域建模和数据库设计一张表对应一个真实的业务动作3.1 核心业务角色和用例分析我先把系统里的角色捋清楚这是后面所有表设计和接口设计的基础。系统一共有四类角色角色核心诉求关键操作游客快速找到想玩的、想吃的、想住的查看景区、搜索线路、阅读攻略、预订酒店民宿、收藏内容景区运营人员把景区信息推出去管理票务和公告维护景区信息、发布公告、管理票务价格、回复游客评论平台管理员保证内容合规、商户可靠、数据可统计审核景点/攻略/商户入驻、管理所有用户、查看运营数据报表旅行社/酒店商家获取客源、管理自己的产品发布旅游线路、管理房态和订单、查看预订记录基于这四类角色的诉求系统拆成六个核心业务域资源管理景区、餐饮、酒店民宿、内容社区攻略、游记、评论、收藏、交易订单酒店预订、线路报名、用户账号、系统管理菜单权限、操作日志、数据统计。3.2 关键表的字段设计与关联关系我拿出几张核心表讲讲字段设计的思路因为旅游资源的数据是有明显行业特征的不能照搬通用RBAC那套。景区信息表scenic_spot除了常规的景区名称、简介、开放时间我加了三个关键字段latitude和longitude存经纬度。后续做附近推荐功能时用Haversine公式计算距离比用第三方地图API拿行政区域过滤灵活得多。level景区等级5A/4A/3A/未评级。游客筛选时这个字段的优先级很高。cover_image封面图URL。列表页展示用单独存避免查询详情的大文本字段拖慢列表接口响应。旅游线路表travel_route这个表的核心是行程安排这个字段怎么设计。我最终选择用JSON字符串存itinerary内容是[{day:1,title:...,spots:[...]}]。因为行程安排的格式变化极多——有人一天的行程有三个景点有人一个景点玩两天硬拆成关系表非常痛苦。MySQL 5.7对JSON的支持虽然不如8.0完整但存和取都是字符串操作够用。订单表booking_order这个表的设计决定了后续交易功能能不能扩展关键字段order_no业务订单号不用数据库自增ID用yyyyMMddHHmmss6位随机数生成避免订单号泄漏当日订单量。order_type订单类型1酒店2线路3门票用枚举值不用两个表拆开因为后续统计总交易额时要跨类型汇总。status订单状态机待支付、已支付、已取消、已完成、已退款这个字段的变更记录单独存一张order_status_log表方便对账。3.3 数据库设计阶段的三条实战准则第一一张表只干一件事。比如景区公告和景区基础信息必须分开因为公告是高频写入、低频读取带时效性而基础信息是低频变更、高频读取合在一起会让缓存策略很难做。第二冗余字段要谨慎但别极端。比如景区表里冗余一个region_name所属区域名称虽然通过region_id能join出来但在列表页这种高频接口里少一次join就是少一份数据库压力。数据一致性通过管理端的更新操作来保证不是通过数据库约束来保证。第三所有业务表必备四个通用字段create_time、update_time、deleted逻辑删除标志、create_by。尤其逻辑删除这个字段在To B管理系统里几乎是必须的——运营人员手滑删了一条景区数据如果没有逻辑删除物理删掉就真的找不回来了。查询时统一加WHERE deleted 0的过滤条件。4. 核心功能的实现细节从接口设计到具体代码逻辑4.1 基于RBAC的权限模型在Spring Boot里的落地方式权限方面的需求就是不同角色看到不同的菜单操作不同的接口。我用的方案是经典的RBAC模型五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。实现上有三个细节要注意第一菜单表的component字段存前端Vue路由的组件路径perms字段存后端权限标识比如scenic:add、order:audit。登录成功后接口返回当前用户的菜单树和权限标识集合前端根据权限标识控制按钮显隐后端在接口上用PreAuthorize(hasAuthority(scenic:add))做二次校验。第二Spring Security的配置里我必须把/api/auth/login、/api/scenic/list、/api/scenic/detail/{id}这类接口放进permitAll其他接口统一走认证。这里有一个我一开始没注意的坑静态资源的放行。如果你用了自定义拦截器一定要记得放行/static/**、/favicon.ico否则页面样式全部加载不出来。第三超级管理员的权限标识用通配符*:*:*在CustomPermissionEvaluator里判断如果当前用户权限集合包含*:*:*直接返回true。这样你不用给管理员手动分配一千多个权限点只需要在创建管理员角色时给一个特殊标识。4.2 图片上传的两种方案对比和最终选择旅游资源管理系统的图片量是很大的景区封面、景点相册、攻略插图、用户头像一个景区可能上传几十张图。我在开发的时候对比了两种方案。方案一是本地目录存储就是上传到服务器的/data/upload/目录然后通过Nginx将/upload/**路径映射到这个目录。优点是简单直接没有额外的组件依赖缺点是后续如果做多节点部署图片同步会成问题。方案二是MinIO对象存储兼容S3协议社区版免费API简单。我后来在系统迭代时引入了MinIO因为攀枝花这个项目的图片越来越多本地方案在备份和访问速度上开始吃力。MinIO的接入在Spring Boot里就是加一个依赖、写一个配置类的事minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: travel-resources上传时核心逻辑是先判断bucket是否存在不存在就创建然后生成一个带业务标识的objectName如scenic/20240615/xxx.jpg最后把文件流put进去。返回的URL格式为http://域名:9000/travel-resources/scenic/20240615/xxx.jpg。要注意MinIO的访问默认是不带鉴权的公开读这个在开发环境没问题生产环境记得在MinIO侧配置访问策略或者用Nginx反代MinIO并在前面加一层签名URL校验。4.3 攻略内容的全文检索从LIKE查询升级到Elasticsearch攻略模块刚上线时用的是MySQL的LIKE %关键词%查询数据量在几千条的时候没问题但运营了几个月后攻略文章到了三万条搜索攀枝花 冬季 康养这种多关键词组合并且还要按相关性排序的时候LIKE查询明显吃力了——一次搜索耗时500ms以上接口超时率升高。我给这个模块引入了Elasticsearch 7.10用中文分词器IK Analyzer。同步方案很朴素在攻略文章表加一个search_status字段写操作时标记为待同步定时任务每30秒扫描一次待同步的数据通过RestHighLevelClient批量索引到ES。查询时先查ES拿到id列表再用WHERE id IN (...)捞MySQL的完整数据。这个方案能保证搜索功能和大数据量的写入互不影响而且ES挂了也只是搜索功能不可用攻略浏览和下单流程不受影响。有一说一如果你们的攻略数据量在万级以内完全没必要上ES用MySQL的LIKE %keyword%配合LOCATE函数就够了。架构是要匹配业务体量的不是为了简历好看。4.4 酒店民宿的房态日历用位图思想解决库存问题酒店民宿预订这个功能一开始用的是最朴素的方式订单表里存入住日期和离店日期查询某天有没有房就遍历订单表。实现后发现一个严重问题当某家民宿有100个订单时查某一天的可售状态就要扫描这些订单并判断日期区间重叠性能还行但要做未来30天房态日历展示时要对每一天都做一次这样的判断响应时间就上去了。我换了一种方式加了房态库存表room_inventory字段是hotel_id、room_type_id、date、total_count、booked_count。预订成功时对该日期区间的每一天执行UPDATE ... SET booked_count booked_count 1 WHERE date BETWEEN ? AND ? AND booked_count total_count影响行数等于实际可订天数时才算预订成功。这套设计的本质是用空间换时间把算出来有没有房变成了查一下就知道有没有房日历接口的性能瓶颈就从订单表扫描转移到了单表索引查询。这个优化做完之后房态日历接口从平均700ms降到了30ms而且并发下单时的超卖问题也通过booked_count total_count这个条件天然解决了——数据库的行锁会保证同时只有一个事务能成功更新这条记录。4.5 JWT的登录态管理和拦截器的正确用法登录这块用的JWTJSON Web Token相对于Session方案的好处是天然适合前后端分离服务端不需要存登录态。我的实现结构是登录接口核验用户名密码后用io.jsonwebtoken.JJWT生成tokenpayload里放userId和username过期时间设为12小时然后返回给前端前端存在localStorage里。后续每次请求在Authorization请求头里带上Bearer token。拦截器做的三件事很关键解析token、校验签名和过期时间把userId塞到ThreadLocal里方便后续业务代码直接拿当前用户不用每个接口都解析一遍token。更新token的过期时间。这里有个从安全角度出发的设计如果用户操作频繁超过12小时token就失效就会导致用户莫名其妙被踢下线。我加了一个滑动过期的逻辑——当token剩余有效期小于2小时时response头部返回一个新的token前端检测到后自动更新本地存储。统一异常处理token过期、签名异常、请求头缺失这三种情况返回统一的401响应码和错误提示。5. 开发阶段避坑实录四个让我熬夜到凌晨的问题5.1 上传的图片过一会儿就404根因是Target目录这个问题真的很典型。开发环境里图片上传后页面能正常显示但如果重启了Spring Boot应用之前上传的图片全部404。排查思路是这样的第一步先看图片到底存到哪里了。我上传图片时代码写的是FileOutputStream(filePath)而filePath是System.getProperty(user.dir) /upload这种写法。在IDEA里运行项目时user.dir是项目的根目录所以图片存在项目的/upload下。但Spring Boot打包后运行时user.dir是jar包所在的目录图片存到了服务器上的别的位置。这还没完——由于Spring Boot内置Tomcat会把jar包解压到临时目录如果你把图片存在了classpath下的某个目录比如static/upload那每次重启时临时目录都会被清理图片就跟着消失了。根因就是把运行时产生的动态文件放进了类路径classpath或临时目录。正确的做法是把上传目录配置成一个绝对路径比如Linux下的/data/travel/upload然后写一个WebMvcConfigurer把/upload/**这个URL映射到这个外部目录Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/travel/upload/); }这个坑给所有人的教训是凡是运行期产生的文件一律不要放在项目内部路径外部目录才是归宿。5.2 跨域CORS配置失效的完整排查链路前端Vue跑在http://localhost:8080后端Spring Boot跑在http://localhost:9090两者联调时第一个碰到的就是跨域问题。我在后端配置了CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }但奇怪的是配置以后前端依然报跨域错误浏览器控制台显示No Access-Control-Allow-Origin header is present。排查链路是这样的我先用Postman直接请求后端接口发现响应头里其实有Access-Control-Allow-Origin说明CORS配置本身生效了。那问题只能出在拦截器链上。继续查我在项目里还加了一个自定义的登录拦截器它拦下了所有/api/**请求。问题就在这里——如果请求是跨域的预检请求OPTIONS方法它不会带业务参数但我的拦截器把OPTIONS也拦截了没有放行导致响应里缺少CORS头。解决方案是在拦截器的preHandle方法里对HttpMethod.OPTIONS.toString()直接返回trueif (HttpMethod.OPTIONS.toString().equals(request.getMethod())) { return true; }这个坑的通用经验是CORS配置和Spring Security/自定义拦截器同时存在时预检请求的放行优先级最高否则无论CORS配置写得多对都会被挡在拦截器之外。5.3 本地日期时间在JSON序列化后少了8小时前端页面展示订单创建时间时发现显示的时间比数据库里的时间少了8个小时。比如数据库存的是2024-06-15 18:30:00前端显示的是2024-06-15 10:30:00。根因分析数据库连接串里我一开始没配serverTimezoneMySQL驱动默认用的是JVM的时区。服务器JVM时区是Asia/Shanghai理论上应该没问题。真正的问题出在Spring Boot的JSON序列化配置上——我用的Jackson在序列化LocalDateTime时默认格式是yyyy-MM-ddTHH:mm:ss而且不带时区偏移量。前端拿到这个字符串后用JavaScript的new Date()解析默认按浏览器本地时区解析如果这台服务器设置的是UTC时区那就差8小时。我用了一个全局配置来解决Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.simpleDateFormat(yyyy-MM-dd HH:mm:ss); builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; } }统一了后端输出的时间格式后就不依赖前端解析了。这个坑让我养成了一个习惯日期时间字段一律使用LocalDateTime而不是Date且全局统一配置序列化格式不依赖任何默认行为。5.4 列表页超过三秒才出数据的索引调优案例景区列表页刚上线时SQL很简单SELECT * FROM scenic_spot WHERE deleted 0 ORDER BY create_time DESC LIMIT 10数据量到了五万条以后这个查询开始变慢最慢的时候要2.8秒。我通过EXPLAIN看了一眼执行计划发现type是ALL走了全表扫描。这直接说明create_time上没有索引而且deleted 0这个过滤条件让MySQL没法走主键索引。处理方案两件事第一加了一个复合索引(deleted, create_time)因为查询条件是deleted0然后按create_time排序复合索引能让排序直接在索引树上完成避免文件排序filesort。加完索引后这个查询降低到50ms以内。第二列表页的查询必须去掉SELECT *。五万条数据每条记录有30多个字段其中详情描述是大文本列表页根本用不上这些字段。改成只查列表页需要的20个字段IO开销小了一半。6. 项目打包部署与上线运维整体流程和个人经验6.1 Maven多环境配置与打包细节项目从开发到测试再到生产配置文件肯定不能一套走天下。我在application.yml里用spring.profiles.active来区分环境分别维护了application-dev.yml、application-test.yml、application-prod.yml三个文件每个文件里配置各自的数据库连接、Redis地址、文件上传路径。打包用Maven的profile功能mvn clean package -Pprod -DskipTests这里有一个细节经常有人翻车Spring Boot的spring.profiles.active在打包时要用-Dspring.profiles.activeprod传入而不是写死。更推荐的方式是用外部的application-prod.yml放在服务器上和jar包同级的config目录里Spring Boot的加载优先级会自动高于jar包内的配置文件。这样改生产配置不需要重新打包只需要在服务器上改文件再重启。线上紧急修数据库连接串这种事经历过的人就知道这个设计多救命。6.2 Docker部署脚本和容器编排的实践版本我把部署脚本放在项目根目录的deploy/下Dockerfile用的是多阶段构建先Maven构建再打镜像FROM maven:3.8-jdk-8 AS builder COPY . /app WORKDIR /app RUN mvn clean package -Pprod -DskipTests FROM openjdk:8-jre-alpine ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone COPY --frombuilder /app/target/travel-system.jar /app/travel-system.jar EXPOSE 9090 ENTRYPOINT [java, -Xms512m, -Xmx1024m, -jar, /app/travel-system.jar, --spring.profiles.activeprod]docker-compose.yml里一次性编排了四个容器应用、MySQL、Redis、MinIO。MySQL和Redis分别挂了volume做数据持久化应用容器depends_on它们。一个实际运维经验容器里的时区必须单独预设。我用的是openjdk:8-jre-alpine这个基础镜像默认时区是UTC如果不设置TZAsia/Shanghai应用日志的时间和数据库时间会差8小时排查问题的时候会让你怀疑人生。6.3 上线后的Nginx配置和三个必调的参数应用跑起来后我习惯在前面加一层Nginx做反向代理和静态资源缓存。核心配置文件server { listen 80; server_name travel.example.com; # 前端Vue项目 location / { root /data/www/travel-web; try_files $uri $uri/ /index.html; } # 后端API location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 20m; } # 上传的图片走磁盘不走后端 location /upload/ { alias /data/travel/upload/; expires 7d; add_header Cache-Control public; } }这里client_max_body_size 20m特别重要因为攻略编辑器里可能有图片需要上传。Nginx默认的client_max_body_size是1m不设置的话传一张稍微大的图片就直接返回413错误而不会进到你的后端接口排查半天都难以定位问题。6.4 日志和监控一个轻量级的组合方案日志这块我用的Logback按天滚动格式包含%d{yyyy-MM-dd HH:mm:ss.SSS}、%level、%logger{36}、%msg%n。同时用logback-spring.xml区分了开发环境和生产环境的日志级别开发用DEBUG生产用INFO。监控方面没有引入Prometheus那套重家伙而是用Spring Boot Actuator暴露了/actuator/health端口配合阿里云的健康检查探针每分钟探测一次不健康就自动触发容器重启。再加一个简单的Shell脚本定时检查Java进程的CPU和内存占用超过阈值就发钉钉告警。这套方案对于小项目完全够用核心信息是监控要做但匹配体量。7. 系统上线后我复盘得出的三个核心体会第一个体会是做业务系统需求理解比技术实现重要。这个项目里最难的不是Spring Boot和SSM那套技术而是搞清楚攀枝花旅游旺季的游客到底需要什么景区运营人员愿意为什么样的功能买单。我花了大量时间访谈真实的景区工作人员最后发现他们对信息发布是否方便的在意程度远超报表是否炫酷于是把资源管理模块的录入界面优化成了向导式三步就能上架一个新景区这个改动带来的好评远超任何技术亮点。第二个体会是性能优化要在数据量起来之后再做不要提前优化。系统刚上线时攻略表只有几百条数据LIKE查询秒回完全不需要Elasticsearch。等数据量真到了瓶颈再引入既避免了过度设计又能在关键时刻用数据说话说服团队去做技术升级。第三个体会是一个项目里70%的价值来自基础能力比如权限系统的严谨性、操作日志的完整性、异常处理的统一性、接口返回格式的一致性。这些能力不显眼但用户每天在用出问题用户第一个感知到。我给这个项目的所有接口统一了返回格式{code, message, data}配合全局异常处理器前端只需要处理一种响应结构开发联调效率提高了不止一倍。最后分享一个小技巧是我在部署阶段实实在在受益的写一个deploy.sh脚本把Maven打包、备份旧包、停容器、起容器、检查健康状态五步自动化。上线初期频繁发版每次手动操作容易出错脚本化以后发版时间从十五分钟缩短到两分钟。这个脚本我延续用了五六个项目值得每个做部署的人花半小时写好它。