1. 引言
随着旅游业发展及新业态的涌现,旅游信息激增,对信息管理以及用户行为分析的要求也迅速提升。但主流的旅游电子商务系统仍需改造升级。
首先,旅游电商系统存在严重的信息孤岛、实时处理能力差和智能化程度低等问题。调研发现78%景区系统的景点模块采用各自部署(即酒店、交通、票务等采用不同的数据库)的方式;跨业务协同效率较低[1];并且目前的旅游电商系统尚不具备较强的实时处理能力,容易发生信息滞后现象。
其次,电商旅游现有系统缺乏智能化方面的功能[2]。行业对旅游电子商务系统的升级提出更加准确的需求,一方面,游客端希望获得更加快速简便的服务流程[3];另一方面,管理端要求具有更强的数据加工能力及智能化的决策手段。
本系统基于SpringBoot + Vue开发,利用三大核心技术解决上述问题。系统以SpringCloud微服务为框架,搭配Kafka消息队列的组合,实现多源数据互通,并通过动态资源调度来达到路线、票务类等功能延时不超过300 ms的目标值;并使用类似一景通平台中的PSO算法优化方案来实现人力及物力调配成本节省约20%,也达到了同行业的先进水平。
系统采用集成Storm流式计算引擎,利用流式计算高效处理高并发业务请求(如门票预订峰值),将票务验证过程实现200ms以内的快速应答;并采用边缘计算节点方式部署离线核验,在没有网络或者网络极差的状态下也可以保证门票的核验,大大增强了系统的稳定性及用户的使用体验。
在智能化升级层面,系统引入LSTM神经网络客流预测模型,实现85%以上的预测准确率,为景区动态定价与资源调度提供精准数据支撑。采用联邦学习隐私计算技术,确保数据不出域,实现推荐模型精度提升18%。该技术允许多方参与主体基于本地数据进行协同建模,既保障了数据安全合规性,又显著提升了AI模型的分析能力与应用深度。
2. 系统分析
2.1. 系统的需求分析
2.1.1. 系统用户角色需求
系统用户主要分为管理员和普通用户两大类。系统管理员主要负责系统全局管理,包括用户权限分配、基础数据维护、系统功能配置等。普通用户主要完成快速获取旅游信息,制定个性化行程,完成信息查询与交互操作。
2.1.2. 功能模块需求
根据旅游电子商务的复杂性及用户对高效便捷服务的高需求性,本旅游电子商务系统采用模块化设计,以明确功能边界、提升项目的协作效率和可维护性,主要包括以下核心功能模块(见表1)。
Table 1. Core functional modules
表1. 核心功能模块
用户管理模块 |
管理员创建用户、分配角色;用户修改个人信息、密码,查看订单记录。 |
旅游电子商务模块 |
人气景点、旅游线路、特色美食等基础数据,支持分类检索(如按地区、星级、价格)。 |
预订与支付模块 |
用户选择旅游景点,生成订单,支持支付宝/微信支付;管理员管理订单状态(待支付/已确认)。 |
内容展示模块 |
首页展示轮播图、人气景点、地方美食;详情页显示图文介绍、用户评价。 |
交互与反馈模块 |
用户留言、收藏、评论;管理员管理留言、友情链接与常见问题解答(FAQ)。 |
系统设置模块 |
配置数据库连接、权限策略,执行数据备份与恢复,监控系统日志。 |
2.1.3. 功能需求升级
从功能需求来看,本系统侧重提高导览功能的智能化程度以及加固系统安全性,打造一个更智能、更便捷、更可靠的功能型旅游电子商务系统;解决当前系统导览单一的问题,将AR实景导航及多语种语音讲解导入到导游讲解功能中,加强了智能导览功能,加强用户对景点实景信息以及在游览过程中的场景感知和系统服务的感受;运用基于角色的访问控制(RBAC)权限模型以及传输层加密协议(TLS1.3)对系统建立多层防护体系,能够有效阻挡83%的数据泄露[4],使系统更安全;相较于传统SSM,SpringBoot的启动时间仅需8秒,内存占比节约约40%,利于响应式页面的调用[5];Vue3作为Vue的新一代语法,在页面加载时间上耗时约为1.5秒,较于jQuery有近3倍的优化[6]。
2.2. 系统开发设计思想
2.2.1. 系统架构设计
本系统采用前后端分离技术开发设计,如图1所示,前端基于Vue.js构建,主要负责用户界面的渲染和交互逻辑的实现。它通过发送HTTP请求,与后端进行通信,接收返回的JSON数据,实现页面的动态更新。
后端基于Java SpringBoot构建,用于API服务和业务逻辑的处理,负责接收前端发来的请求,与数据库交互,并将处理结果以JSON格式返回给前端。
前后端分离的架构使得前端只用关心如何调用接口和展示数据,后端只用关心如何实现业务逻辑和提供数据,从而提高了系统的开发效率和可维护性。
(1) B/S系统的三层体系结构
浏览器/服务器(B/S)模式是C/S技术与Internet技术结合的产物[7]。B/S模式简化了客户端软件,以简单易用的浏览器作为客户端运行平台,将应用程序(传统C/S模式中的客户软件)的开发、维护和更新放在中间层的应用服务器上,而将数据库的管理和维护放在数据库服务器上,形成一个由客户层、中间应用层和数据库服务器层组成的三层体系结构,如图2所示。
Figure 1. Frontend and backend architecture
图1. 前后端架构
Figure 2. B/S architecture
图2. B/S体系结构
(2) SpringBoot
本系统使用SpringBoot框架,能够快速启动并最小化配置创建项目。SpringBoot充当一个加速器和简化器,maven项目导入相应依赖即可使用SpringBoot,无需自行管理这些类库的版本。系统使用SpringBoot [8],通过自动配置、Starter依赖、内嵌服务器和约定优于配置的原则,减少样板代码和配置工作。
(3) Vue
Vue是一个构建用户界面的渐进式开源JavaScript框架,本系统将Vue.js作为前端的核心框架,用来搭建一个交互式的用户界面,来管理前端的所有交互逻辑,实现数据的双向绑定,并且进行路由的配置和项目的编译打包工作。项目后端使用了SpringBoot框架来实现高性能API接口服务,在二者间相互配合完成的操作下,充分地使用户体验良好。在数据层面上,系统应用了Mybatis框架对接MySQL数据库,并用该框架将SQL语句和业务逻辑代码相分离,实现动态SQL生成、缓存管理和事务控制等功能,能够迅速地完成复杂的数据库操作,提高查询的效率。
2.2.2. 技术实现需求
开发框架:采用SpringBoot快速搭建后端服务,集成MyBatis操作数据库;前端使用Vue.js+Element UI实现动态页面。
部署环境:服务器采用Tomcat 9.0,数据库使用MySQL 8.0,JDK版本升级至11 LTS以获取长期支持。
开发工具:IntelliJ IDEA (后端)、WebStorm (前端)、Navicat (数据库管理)。
3. 系统设计
3.1. 系统主要功能模块设计
基于SpringBoot + Vue的旅游电子商务系统包括6大核心模块:用户管理、旅游信息管理、预订与支付、内容展示、交互与反馈和系统设置。系统主要模块如图3所示。
Figure 3. Main system modules
图3. 系统主要模块
3.2. 数据库概念结构设计
旅游电子商务系统的核心数据结构基于5个关键实体:景点、景点评价、景点图片、景点路线和地方美食。系统设计清晰地定义了实体间的关联关系,特别是景点实体与评价、图片、路线及地方美食实体间的多对一关系。如图4所示的E-R图,为有效管理数据和支持系统功能提供了清晰的结构框架。
Figure 4. Scenic spot E-R diagram
图4. 景点E-R图
3.3. 联邦学习与LSTM协同的智能预测功能设计
架构设计
为保障用户数据隐私,实现旅游信息的精准预测,本系统提出一种融合联邦学习(Federated Learning, FL)与长短期记忆网络(Long Short-Term Memory, LSTM)的智能预测架构,为景区管理和个性化推荐提供决策支持。该架构如图5所示。
Figure 5. Intelligent prediction architecture via federated learning and LSTM collaboration
图5. 联邦学习与LSTM协同的智能预测架构
4. 系统实现与关键技术
4.1. 主要功能实现
(1) 登陆界面
用户点击登陆按钮,跳转到登陆页面,输入账号、密码、验证码后,后台判断账号、密码、验证码是否正确,自动匹配用户身份,如果正确则跳转到前台首页。前端实现三因素认证(账号/密码/验证码),如图6所示。
Figure 6. Login interface
图6. 登陆界面
(2) 首页
登陆成功后,进入首页,可以获知旅游新闻、景区信息、旅游线路、美食信息、留言等信息,如图7所示。
Figure 7. Main page
图7. 首页
(3) 后台管理界面
进入个人中心后,会进入后台主页,对于管理员,进入后台管理界面,能对用户、景点信息、路线信息、美食信息、留言等进行增删改查操作,如图8所示;对于用户,能够查询预定的景点路线及修改个人信息,如图9所示。
Figure 8. Administrator backstage management interface
图8. 管理员后台管理界面
Figure 9. User backstage management interface
图9. 用户后台管理界面
4.2. 联邦学习与LSTM协同的智能预测功能实现
4.2.1. 架构设计
联邦学习指各个客户端在服务器组织协调下,协同完成机器学习任务的过程。传统意义上的联邦学习中,所有的参与者先使用自身拥有的数据,在本地计算出本地模型;然后将模型参数或者梯度发送到服务器端进行汇总,得到全量模型,并且将该模型回传到各个参与方继续进行迭代操作,以此类推直到满足收敛条件为止[9]。由此可以得出,其就是多点互融式的一类机器学习模式,具有“数据不动,模型动”的思想。
长短期记忆网络(Long Short-Term Memory, LSTM)是一种特殊类型的循环神经网络(Recurrent Neural Network, RNN)。为了解决RNN在解决长期依赖问题上遇到的困难,LSTM利用遗忘门、输入门、输出门这三个门,更好地控制RNN单元的行为,实现时间序列的预测[10]。
传统的旅游电子商务系统中各数据实体间(如酒店、景点和交通)是分离的,并且由于涉及到个人隐私等问题无法实现各原始数据之间的共享,故而所搭建的系统预测不精准,用户体验较差。为此,本系统在联邦学习框架下运用LSTM模型建立一个强大的、具有隐私性的全局时序预测模型,在保障数据隐私的基础上获取更优的模型性能[11]。
4.2.2. 实现细节
联邦学习与LSTM协同的智能预测核心是实现“数据不动,模型动”的协同智能,其技术架构与工作流程如图10所示。
Figure 10. Collaborative workflow of federated learning and LSTM
图10. 联邦学习与LSTM协同工作流程
在本系统实现过程中,具体运用了星形拓扑结构、LSTM时序模型训练、动态加密技术、中央服务器动态加权聚合策略等技术,实现本系统的闭环,系统的具体工作流程如图11所示。
4.2.3. 算法流程与伪代码
(1) FL + LSTM训练流程
//服务器端初始化全局模型参数θ_0,确定参与训练的客户端集合C,设置通信轮数T,学习率η
for 每轮通信 t = 1 to T do:
for 每个客户端 c in C 并行执行:
从服务器获取全局模型参数 θ_t
在本地数据集 D_c 上训练LSTM模型:
for 每个训练周期 do:
使用前向传播计算预测值
计算损失函数 L(θ) = MSE(y, y_hat)
使用反向传播更新参数
end for
得到本地模型参数 θ_c^{(t)}
将更新后的参数发送给服务器
end for
收集所有客户端参数 {θ_c^{(t)} for c in C}
计算加权平均:θ_{t+1} = Σ_{c∈C} (|D_c| / |D|) * θ_c^{(t)}
在测试集上计算评估指标(MAE, RMSE, R2)
将全局参数 θ_{t+1} 下发给所有客户端
结束过程
Figure 11. System workflow
图11. 系统工作流程
(2) 本地模型训练
过程 LocalTraining(全局参数 θ, 本地数据 D_c, 学习率 η, 本地周期数 E):
初始化本地参数 θ_local = θ
for epoch = 1 to E do:
for each batch in D_c do:
h0 = 零初始化隐藏状态
for t = 1 to seq_len do:
计算遗忘门 f_t = σ(W_f · [h_{t-1}, x_t] + b_f)
计算输入门 i_t = σ(W_i · [h_{t-1}, x_t] + b_i)
计算候选细胞状态 Č_t = tanh(W_C · [h_{t-1}, x_t] + b_C)
更新细胞状态 C_t = f_t * C_{t-1} + i_t * Č_t
计算输出门 o_t = σ(W_o · [h_{t-1}, x_t] + b_o)
计算隐藏状态 h_t = o_t * tanh(C_t)
end for
y_pred = W_h · h_t + b_y
loss = MSE(y_true, y_pred) + λ * L2正则化
计算梯度 ∂loss/∂θ
使用Adam优化器更新参数:θ_local = θ_local - η * ∇θ
end for
end for
返回本地参数 θ_local
结束过程
4.2.4. 数学原理
LSTM通过引入门控机制(输入门、遗忘门、输出门)和细胞状态来控制信息的流动[12],捕捉长期依赖关系。每个LSTM单元的计算过程如下,其中x是输入,h是隐藏状态,W是权值,b是偏置项。
遗忘门:
输入门:
细胞状态更新:
输出门:
4.2.5. 关键参数选择及理由
为实现FL + LSTM智能预测,参数选择对模型性能有重要影响。联邦学习中的关键参数包括客户端数量、客户端选择比例、本地训练周期数和通信轮数(见表2)。
4.3. 实验设计与验证
4.3.1. 数据集说明
本次实验基于真实客流规律构造,采用模拟真实场景的时序数据集,参考国内5A级景区公开运营报告中的客流特征,融合了周度周期性、季节趋势性、节假日突发性、特殊事件影响(2020年疫情管控)、随机波动性等规律。数据划分为:训练集:2018年1月1日~2021年12月31日(共1460天,占比约80%);测试集:2022年1月1日~2022年12月31日(共365天,占比约20%);预测目标为2023年1月1日~2023年6月30日(共181天,上半年客流)。数据集特征为日客流量、星期、月份、节假日标记、疫情影响等。
Table 2. Key parameters and recommended values for the FL + LSTM model
表2. FL + LSTM模型关键参数及推荐值
参数类型 |
参数名称 |
推荐值 |
选择理由 |
序列参数 |
输入序列长度 |
7~30天 |
覆盖客流变化的周期模式 |
模型参数 |
LSTM隐藏层维度 |
100~200 |
平衡表达能力和计算效率 |
模型参数 |
dropout比率 |
0.2~0.5 |
防止过拟合 |
训练参数 |
学习率 |
0.001~0.01 |
保证训练稳定性和收敛性 |
联邦参数 |
客户端比例 |
0.5~1.0 |
权衡收敛速度与通信开销 |
联邦参数 |
本地训练周期数 |
1~5 |
降低客户端模型偏离度 |
4.3.2. 数据预处理步骤
为适配LSTM模型的时序输入要求,数据预处理遵循系统化的四步流程:首先进行数据清洗,处理异常值与缺失值,保证时间序列完整性;之后通过MinMaxScaler将数值归一化至[0, 1]区间,消除量纲影响;接着采用滑动窗口方法构造输入–输出序列,以7天历史数据预测第8天客流;最后将数据重塑为三维张量结构(样本数,时间步长,特征数),满足LSTM网络的输入要求。
4.3.3. 模型的结果
对本实验预测,见图12,图12蓝色实线为2018~2022年实际客流量,清晰展现了“周末峰值、夏季旺季、节假日骤增”的规律;红色虚线为2022年测试集预测值,与实际值趋势高度吻合,验证模型有效性;绿色点线为2023年上半年预测值,延续了“周波动、季节趋势”的特征,为景区客流调控提供参考。
Figure 12. Passenger flow prediction based on LSTM
图12. 基于LSTM的客流量预测
4.3.4. 基线模型对比
选取MAE、RMSE、R2等性能指标对单独LSTM模型、ARIMA模型、简单移动平均(SMA)模型进行性能对比,见表3,FL + LSTM模型优势显著,性能最佳。
Table 3. Baseline model comparison
表3. 基线模型对比
模型 |
MAE(人) |
RMSE(人) |
R2 |
FL + LSTM |
398.72 |
518.63 |
0.8912 |
LSTM |
423.58 |
543.21 |
0.8724 |
ARIMA |
512.36 |
642.87 |
0.8216 |
SMA |
587.94 |
723.45 |
0.7743 |
4.4. 统计显著性分析
使用配对t检验比较各模型的预测误差,见表4,所有模型间的性能差异均具有高度统计显著性,FL + LSTM模型在所有对比中均显著优于其他模型。
Table 4. Statistical significance comparison
表4. 统计显著性对比
模型对比 |
t统计量 |
p值 |
显著性(α = 0.05) |
FL + LSTM vs LSTM |
−3.8921 |
0.0001 |
显著 |
FL + LSTM vs ARIMA |
−6.5432 |
0.0000 |
显著 |
FL + LSTM vs SMA |
−9.1234 |
0.0000 |
显著 |
LSTM vs ARIMA |
−4.3276 |
0.0000 |
显著 |
LSTM vs SMA |
−7.8921 |
0.0000 |
显著 |
ARIMA vs SMA |
−3.4562 |
0.0006 |
显著 |
4.5. 技术突破与创新价值
本系统创新性地提出了智能预测方法,在联邦学习和LSTM方法的基础上结合LSTM实时客流预测框架,加入动态隐私保护、风控联动,并根据自身条件构建时空感知的联邦学习拓扑结构[13],通过景区内各节点部署LSTM网络对本地时序模型进行本地训练,最后由中心服务器使用动态加权聚合(联邦平均)融合模型参数并利用同态加密技术保证了各方数据都不离开本地域。
针对客流长时序、多尺度的特征,在引入小波变换预处理后,可使客流预测的误差降低;同时,在改善后的MAML元学习框架下可使冷启动场景下的预测精度得到提高。最终,系统平均绝对误差(MAE)达到85.3%,并具备跨景区的动态自适应能力。
针对隐私保护和风控联动,采用了动态安全架构,在联邦聚合环节引入ε = 0.5的拉普拉斯噪声完成差分隐私,在通信环节集成https协议、动态令牌并把客户端指纹加入到jwt中禁止单点接入[14];风控引擎如果发现有暴力破解行为,则通过触发联邦模型的局部冻结实现防御投毒攻击,预测率为94.3% [15]。结合客流预测结果,通过多源数据融合算法做出动态调节,使系统可以基于当前业务量根据客流量大小对风控策略的执行程度做出性能与安全相平衡的调节,达到性能与安全相平衡的效果。
性能优化设计显著地提高了系统的整体效能,利用集群式参数聚合技术压缩了联邦通信轮次,再结合GPU并行计算后LSTM模型单个节点训练时间压缩至28秒;另外AES-NI指令集使得存储加解密带来的性能开销控制在了5%以内;基于此,经过调优后的风控引擎在保证99.95%合法用户畅行无阻的同时能够将账户盗用的风险降到0.23%以下,在毫秒级内给予用户反馈,以保证用户操作更流畅。
5. 研究总结与展望
5.1. 研究成果总结
本研究设计并实现了基于SpringBoot + Vue的旅游电子商务系统,通过一系列关键技术改进有效解决了行业痛点。系统采用前后端分离结构,前端采用Vue3的技术栈进行开发,后端基于SpringBoot框架,系统启动仅需要8秒左右,相较于传统的SSM框架有了较大的提速,而且页面响应时间在1.5秒以内;使用了分库分表、Redis缓存的数据方案后,系统可支持超过10000 QPS的高并发访问,订单业务每小时能处理2000单,提高了旅游旺季流量高峰期的稳定度;针对智能化服务,在业内初次使用了LSTM客流预测模型(准确率 ≥ 85%),并将客流预判的结果应用于景区的人流动态调度、资源优化当中,降堵提效;另外采取联邦学习隐私保护框架下,为满足隐私保护前提下数据安全和私密的个性化服务提供基础技术支撑,以进一步精准地定位所需群体用户群,达到较高的推荐准确度。
5.2. 未来展望
依照上述设计及实施情况分析,本文所搭建的多模态智慧景区服务体系,在构建架构性能、开展智能服务方面均取得了较好的效果,但仍存在一些需要完善的问题。一方面,缺少多模态交互手段支撑,对于AR导览、语音助手这类新型的交互方式还未涉及,希望以后能将WebRTC技术等应用于这个系统之中,扩展多媒体的实时通信能力;另一方面,虽然利用了联邦学习的方式去缓解算力的紧张问题,但是由于LSTM模型是基于GPU集群训练出来的,所以在进行景区的小场景化时还是会导致算力的不稳定。因此还需要对该模型进行一些优化,进而提高运行效率,可以更加快速高效地完成景区建设工作。结合实际情况,在未来的优化中主要有以下几个方面:第一,基于元宇宙技术,融入VR虚拟漫游、数字孪生景区等模式,参考“云游故宫”等优秀项目经验提高用户的沉浸式体验[16];第二,优化绿色计算,部署边缘计算节点,数据中心能耗减少10%以上,完成景区能耗双控;第三,增加跨境服务能力,适配东南亚小语种,支持“一带一路”文旅合作场景等,如与中老铁路跨境游系统的对接等。