★ FEATURED ARTICLE 做旅游网系统这事儿我一开始以为就是套个模板把景点、酒店、线路往页面上一铺再挂个下单按钮就行。结果真到动手才发现这个“看着简单”的项目几乎把电商、库存、支付、内容管理那些坑全踩了一遍。今天想把这个项目从头到尾拆一遍包括我怎么理需求的、数据库怎么设计的、订单为什么差点超卖、支付回调和库存扣减最后怎么稳定跑起来以及上线前那些让人头秃的细节问题。如果你正打算做旅游网站、目的地预订、酒店加线路组合这类系统这篇应该能帮你少走几条弯路。说实话旅游网站这个称呼特别笼统。用户进来可能只是想查攻略也可能直接下单买一条“三亚五日游”的线路。我当时接手这个系统需求方给的原始描述只有一张A4纸景点列表、搜索筛选、线路详情、在线下单、后台改价、订单查询。这看起来都是常规功能但真做起来每一块背后都有一堆业务细节。比如景点列表的排序需求方说“热门优先”那热门到底按浏览量、销量还是评分如果上线前不把权重定清楚后期数据一出来你解释不了为什么某个冷门景点排在前面。还有个特别容易被低估的点是价格模型。旅游线路往往不是单纯一个总价它包含成人价、儿童价、单房差到了旺季还要整体上浮。如果只在订单表里存一个总价等后台改价、用户退款、财务对账的时候你会发现根本算不清钱是怎么来的。我最后把价格拆成了“基准价加附加项”的结构订单存下单时刻的价格快照后台改基准价只影响新订单老订单该退多少还是多少。这个改动看上去多建了两张表但实际帮我们省掉了大半个月的对账纠纷。还有一个权限问题。后台不只有超级管理员还应该有运营、财务这些角色。当时图省事把所有后台操作都放在一张权限表里结果运营误操作把一条在售线路直接下架了线上商品空白了半天才发现。我的教训是后台哪怕再简单也要把“查询、编辑、上下架、改价”这几个动作拆开权限校验放在服务端做不能只靠前端隐藏按钮。按钮藏了懂点接口的人照样能调。1. 项目全貌这个系统到底要解决什么问题1.1 初始需求里容易被忽略的隐藏要求我接手项目时需求方脑子里的“旅游网系统”还是那种老式信息展示站觉得只要把景点图片一挂、电话一留就算完事。但实际打开任何一个成熟的旅游网站用户的行为路径基本都是搜索目的地、看线路详情、对比价格、看用户评价、下单支付然后等着确认短信。这条路径背后隐藏着一张完整的业务闭环。你不能只展示不下单也不能只下单不做订单管理更不能做了订单管理却不处理退款和售后。需求方嘴上说的是“做个网站”实际要的是“一套可交易系统”。所以我在需求评审阶段直接把“仅展示”这个选项否掉了所有模块都要围绕交易来做包括商品上下架、库存扣减、支付回调、退款状态流转。另外还有一个隐藏要求是“运营后台的可控性”。需求方说“后台改个价”实际指的是运营人员能自己调整线路价格、酒店价格、库存数量而不需要开发每次改数据库。这就要求后台必须有独立的商品管理、订单管理、数据统计模块。如果后台改价要走代码发布那这个系统基本等于没有后台。1.2 模块边界的划分我把系统划成了四个部分前台门户、会员中心、后台管理、基础公共服务。前台做目的地内容、线路搜索、产品展示和下单入口会员中心承担登录注册、订单列表、退款申请、个人资料维护后台管理负责商品、库存、订单、评价、营销配置的维护基础服务统一处理短信通知、支付回调、图片存储、定时任务和操作日志。这个边界划分的价值在后端接口上体现得特别明显。如果前后台共用一套接口后台改价、上下架的操作日志很难做给外部合作方开放接口也会束手束脚。所以我一直坚持管理端接口统一加/admin前缀使用独立的Token有效期和操作日志中间件会员端接口走/api前缀两类接口的参数校验和异常返回规范也各成一套。这样做最大的好处是后续无论是改需求还是排查问题都能快速定位到链路不会出现改一处牵动整条线的情况。有人会觉得这样太重了小项目没必要。我的看法是项目初期分得越清楚后期越不会因为需求蔓延而重构。就拿最简单的“用户昵称”来说如果前台和后台共用一个修改接口那运营在后台给用户备注信息时就得连着用户昵称一起处理权限边界一下就乱了。2. 技术选型与整体架构为什么这么搭2.1 技术栈的取舍这套系统最终用的是Java加Spring Boot做后端Vue3做前端后台管理页MySQL 8存数据Redis扛缓存和临时库存标记。选这套组合不是因为它最潮而是因为可维护性高、社区资料多、对接第三方生态成熟。旅游业务免不了要接短信、支付、地图、天气这些第三方服务用生态成熟的框架每个接口都有人踩过坑能省掉大量排雷时间。Spring Boot的好处是启动快、内置Tomcat、打包就是一个可执行jar部署特别省事。数据层我用MyBatis-Plus该有的单表增删改查都封装好了复杂联查就自己写XML不需要像早期MyBatis那样写一堆重复代码。前端后台用Vue3加Element Plus组件丰富开发效率高C端页面用服务端渲染配合Vue的轻量交互主要是为了方便搜索引擎收录旅游资讯和线路详情页。这个组合对于预算有限、需要快速上线的团队来说很稳。如果你团队更擅长Node或者Go也不是不行但要注意第三方支付和短信SDK对语言的支持程度有些老牌支付渠道对Java和PHP支持得最好其他语言的SDK维护非常滞后。2.2 数据模型设计的关键旅游网系统的数据模型核心不是用户表也不是订单表而是“产品”。产品往下拆是资源比如景点、酒店、车辆、导游往上聚是线路比如“三亚五日游”。如果直接把一条线路塞进一张表后面做库存和价格联动会特别痛苦要么在代码里疯狂写缓存要么会出现大量冗余字段。我当时设计了几张核心表分别是资源主表、旅游产品表、产品资源关联表、酒店信息表、订单主表和订单明细表。资源主表存的是景点和酒店这类基础资源的通用信息比如名称、城市、地址、经纬度、封面图旅游产品表存的是线路标题、行程天数、出发城市、销售状态、基准价这些聚合信息产品资源关联表负责绑定线路包含哪些资源订单表和明细表落的是用户最终买的东西快照。关联这块有个很关键的设计思路库存不能只放在旅游产品表里因为一个线路包含多个资源用户买的其实是“某一天出发的某一条线路”。比如三亚五日游它包含了第一晚的酒店、第二天的景点门票任何一项资源库存不足线路就卖不了。所以我在库存设计上用的是“产品每日库存”和“资源每日库存”联动下单时同时扣减两者取最小值作为可售判断。价格表我也单独拆了一层。线路基础价、酒店单房差、儿童价、节假日上浮都单独存字段而不是塞进一个JSON里。这样虽然建表多一点但后续后台改价、报表统计都能用SQL直接算不用解析字符串。2.3 接口拆分与权限控制接口设计这块我走的还是前后端分离的路子。前台C端走/api后台管理走/admin两个网关前缀对应的认证逻辑完全不同。C端使用JWT令牌保证登录状态后台管理员则使用独立的管理端令牌且额外做IP白名单和操作日志记录方便追责。权限模型我采用了RBAC的基础形态也就是用户、角色、权限三层。后台里分超级管理员、运营、财务、客服四种角色。运营能操作商品上下架和库存调整财务只能看订单和退款记录客服能处理售后工单但不能改价。每个接口上用Spring Security的注解控制访问比如PreAuthorize(hasAuthority(product:edit))这样权限问题在代码层面就守住了。有人会说小项目搞这么复杂干嘛。我的经验是后台操作一旦涉及钱就一定要留痕。当时上线第二周就出现了一次退款纠纷用户说“我已经申请退款了你们怎么还扣款”财务查了半天最后是靠操作日志发现是客服误操作把退款申请关掉了。如果没有日志和权限隔离这种问题根本说不清楚。3. 核心模块实操从数据库到页面的完整落地3.1 用户、景点、酒店三个基础模块的建设用户模块我重点做了三件事注册登录、第三方认证绑定、用户标签。注册登录没什么新鲜的手机号加验证码为主密码做了加盐哈希不用明文。第三方绑定主要是微信扫码登录方便用户在微信里分享线路给朋友。用户标签这个是从一开始就加的根据用户浏览和下单记录给他打上“亲子”“蜜月”“老年团”这类标签后面做推荐和客服沟通都用得上。景点表的设计除了常规的名称、城市、简介、经纬度我还加了几个业务字段景点等级、建议游玩时长、开放时间、门票参考价。等级和游玩时长是为了做线路编排时快速筛选比如搜索“一日亲子游”系统可以直接按“等级较高、时长3-5小时、适合亲子”去匹配。门票参考价则不参与交易只做展示参考因为实际门票价格浮动的因素太多比如团队票、淡旺季票这些都放资源价目表管。酒店表是和景点并列的另一张重要表。它包含酒店名称、星级、房型、早餐、是否含温泉、距离景区多远这些属性。酒店价格不单独存储因为酒店价格变动太快直接关联到产品资源关联表按日期段维护比如6月1日至6月30日的标间是多少钱、含双早加多少。这样用户在选线路时前端展示的是实时报价而不是一个过期的静态数字。这里有一个实操取巧点酒店和景点的“距离”字段不要存直线距离要存“高德驾车距离”因为用户关心的是通勤。我当时第一版用的经纬度直线距离结果一个景点看着只有两公里实际开车要绕山二十公里被用户投诉误导。3.2 线路组合与库存扣减逻辑线路产品是旅游网站最核心的东西。它不像普通商品有固定SKU而是由多个资源组合而来。比如“青岛崂山二日游”包含第一晚的酒店、第二天的景区门票、一辆大巴、一个导游。我建了产品资源关联表每条产品可以关联多个资源每个资源可以设置使用日期和使用顺序。前端用户选的是“出行日期几成人几儿童”。后端拿到这个组合之后先去查产品在该日期有没有排期再去查关联的每个资源在该日期剩余库存是否充足全部充足才能继续下单。这就是我之前说的“库存联动”任何一个资源没库存整个线路当天就不可售。库存扣减的实现我的第一版用的是“Redis预扣、MySQL落地”的方案。用户提交订单时先锁Redis库存支付超时则自动释放。这样做的效果是并发高的时候不会大量打到数据库。但Redis和MySQL之间的数据一致性老是出问题尤其是宕机之后Redis里的库存和数据库对不上后台显示的库存数和实际可卖数出现偏差。后来我改成了在MySQL层面用“乐观锁加唯一约束”做兜底。下单时更新库存行使用UPDATE product_stock SET stock stock - 1 WHERE id ? AND stock 0这样的原子操作影响行数为0就说明库存不足。这个方案牺牲了一点并发量但对于日均几千订单的旅游网站来说稳定压倒一切。Redis预扣还是保留不过只作为前端秒杀页面的提示加速最终以数据库扣减结果为准。3.3 支付回调与订单状态机订单模块是最容易写着写着就乱掉的部分所以我提前把订单状态机画清楚。订单状态包括待支付、已支付、待出行、已出行、已完成、已取消、退款中、已退款。每个状态间的流转触发条件明确写在代码里比如“待支付”只能通过用户主动取消或超时取消变成“已取消”用户支付成功变成“已支付”退款申请通过之后才能变“退款中”。支付回调这个环节是重点中的重点。用户可能支付成功但页面没跳转可能回调延迟十几秒也可能网络异常导致回调重复推送。所以支付回调处理必须做成幂等的也就是说同样一笔订单的回调通知即使发十次最终结果也要和第一次一致。我这里是先按订单号加支付流水号查重存在就直接返回成功不存在才更新订单状态和扣减库存。当时踩过一个特别典型的坑支付回调更新订单状态后又去扣了一遍库存导致用户明明只买了一条线路库存却被减了两次。后来我在扣库存方法里加了事务型标识把“订单号”记录到扣减表再次扣减时先查这个订单是否已经扣过。这样不管是回调重试还是人工补单都不会把库存减重复。退款流程也值得一提。旅游产品退款不是简单全额退它涉及交通、酒店、门票多个资源的取消费率。我的方案是把退款规则拆到资源一级比如“提前7天退酒店免费提前3天扣20%”线路退款时按资源规则逐步计算最后汇总得到退款金额。这比根据线路总额一刀切精确得多也更能说服用户。4. 上线前踩坑实录这些问题差点让我加班一个月4.1 并发下单导致的超卖系统第一次压测的时候我们模拟80个用户同时购买同一条线路结果库存为1的商品竟然成功卖出了3单超卖问题立刻暴露。原因就是第一版代码先查询库存数量Java代码里判断库存大于0再执行扣减这中间有时间窗口高并发下判断和扣减之间不断插入新请求导致库存被超扣。解决方案就是我前面说的把“判断”和“扣减”合并到一个原子SQL操作里。UPDATE product_stock SET stock stock - 1 WHERE id ? AND stock 0返回1说明扣减成功返回0就返回“库存不足”。另外在数据库层面给订单表加了用户和订单的联合唯一索引防止同一用户同一线路在极端情况下重复下单。这里要提一句如果用了事务一定要把库存扣减放在事务最前面或者单独枷锁别让其他耗时操作拖长库存行的锁时间否则容易造成大量请求堆积等待。4.2 图片资源加载缓慢旅游网站是极度依赖图片内容的线路封面图、景点详情图、酒店实拍图随便一个详情页就是十几张高清图。最初我把图片全部放在应用服务器本地磁盘结果用户一多带宽被打满图片加载慢到能让人直接关掉网站。后来我把图片统一迁移到云存储并在前端用按尺寸裁剪的规则列表页只加载压缩后的缩略图详情页用渐进式加载的大图。这里有两个细节第一是图片必须开启CDN加速全国不同地区访问速度差距很大第二是图片名要带业务标识比如product-123-cover-large.jpg这样排查问题时能快速知道是哪张图拖慢了页面。我还加了一层前端懒加载用户滚动到某个景区图片时才发起请求减少首屏压力。4.3 定位与路线规划偏差我们做的线路详情页里有一个“交通指南”功能会展示从城市中心到景区的驾车路线和预计时间。最初我直接调用第三方地图API把起终点经纬度传过去返回路线。结果发现一个很严重的问题有些景区定位到的是景区后门谷歌返回的路线和当地的导览图完全不匹配。后来我做了人工修正表的方案在后台给每个景区设置“游客中心导航地址”并允许运营手工微调经纬度。前端展示路线时优先使用后台修正过的坐标不用第三方返回的原始坐标。看上去只是多了一个字段但对用户体验的提升是实打实的因为用户打开地图导航的一瞬间看到了正确的位置信任感就建立起来了。4.4 常见问题速查表问题现象可能原因排查方向用户支付成功但订单还是待支付支付回调未正确处理或网络延迟查支付平台回调日志确认订单号和流水号手动触发补单库存显示有货但下单提示无货Redis预扣库存与MySQL不一致核对Redis库存键和数据库表执行库存重建任务后台改价后前台价格没变价格缓存未刷新清理线路详情页的Redis缓存确认缓存key是否带产品ID用户收不到短信验证码短信通道被限流或模板未审核查短信服务商后台发送记录确认签名和模板状态订单列表加载慢订单表和明细表没走索引检查订单号、用户ID、状态字段的索引情况删掉多余索引退款金额算不对退款规则没有按资源级别计算看退款明细表逐项对比交通、酒店、门票的取消费用图片加载慢但接口很快图片路径是原图没有走压缩检查图片上传是否生成多个尺寸CDN刷新是否生效5. 部署与运营的一些心得5.1 服务器的环境与上线方案我把服务器分成了四台两台应用服务器跑Spring Boot实例一台MySQL数据库一台Redis和对象存储代理。应用服务器前面用Nginx做负载均衡同时处理HTTPS证书和静态资源缓存。旅游网站的内容访问峰值有明显的节假日属性比如国庆前一周搜索量暴涨这种场景下应用服务器的水平扩容只需要加节点前提是会话状态已放到Redis里不能存在应用本地内存。上线这一步我坚持用“蓝绿发布”思路。先新起一套环境跑冒烟用例再切一部分流量过来确认稳定后全量切换。旅游系统最怕的就是发布时遇到用户下单订单数据写一半是灾难。所以发布窗口选了凌晨两点之后并且提前在公告里提示系统维护。第一版上线时我没做这个直接在白天重启应用结果正在支付的一笔订单断了用户投诉后我花很久解释和补单吃力不讨好。5.2 数据备份与日志监控数据库每天凌晨做全量备份备份文件跨机房存储。我建议至少保留近7天的备份并且不定期做一次恢复演练。旅游网站的订单数据是命根子真到需要恢复的时候才发现备份文件损坏比没有备份还让人崩溃。我一般会备份后校验文件大小并随机拿某一天的备份到临时实例上恢复验证一遍。监控我接了三层应用日志、数据库慢日志、前端错误上报。应用日志里重点看支付回调、库存扣减、退款计算这三个关键链路每个链路单独打标签比如[PAY-CALLBACK]、[STOCK-DEDUCT]用日志平台按标签搜索排错效率会高很多。数据库慢日志我每周拉一次把超过500ms的SQL捞出来优化。前端错误上报主要看用户下单时浏览器抛出的异常很多问题网络端是发现不了的要靠前端采集才能看到。5.3 后续功能扩展方向这个系统跑顺之后可以继续加的方向很多。最常见的是加一个“攻略社区”让用户发布游记、晒图内容带SEO免费流量会很可观。其次是加会员积分体系下单送积分、积分抵扣现金这是提高复购最直接的手段。还有一个方向是接入更多第三方供应商比如景区直连电子票用户在网站下单后直接收到电子凭证扫码入园减少人工出票环节。我在这个版本里预留了产品扩展位也就是“目的地”表和“攻略”表先建了基础字段后续不需要大改就能接上内容运营。这套设计的收益不一定立刻看得到但半年之后再碰到新需求你会发现当初多花一天建表是值得的。我个人在实际操作中有一个特别深刻的体会旅游网站本质上是一个“资源整合系统”你做得好不好不在于页面多炫而在于用户下单时你给的库存、价格、出发信息到底准不准。凡是涉及准确性的环节宁可多建表、多写点校验也不要图省事。库存联动、价格快照、支付幂等、退款溯源这四个点把住整个系统基本不会出大乱子。最后再分享一个小技巧上线前别只测功能流程一定要拿一个真实存在的旅游目的地从搜索“青岛”开始一路走到支付成功全程录屏存档。这个录屏既能当测试证据也能给需求方验收用还能在下一次改版时做对比。很多看起来不起眼的问题恰恰是在这条完整的路径上才暴露出来的。
阅读完成 · 觉得有帮助？
