基于微服务架构和Spring Boot框架的在线电影购票平台设计与实现（源码）-CSDN博客

本文链接：https://blog.csdn.net/newlw/article/details/149504252

资源下载地址：https://download.csdn.net/download/sheziqiong/91434053
资源下载地址：https://download.csdn.net/download/sheziqiong/91434053

影易购在线购票

一、介绍

影易购是模仿猫眼电影

二、软件架构

B/S架构。该项目基于浏览器和服务器的网络架构模式开发，客户端模块采用了前后端分离的开发模式。

三、核心技术

springboot、mysql、redis、rabbitMQ、minio、elasticseach、mybatis、Dubbo、zookeeper

四、安装教程

该项目运行在maven环境下，先下载安装maven
项目中使用了uid-generator生成订单ID，依赖于jdk8；安装uid-generator源码到maven的本地仓库
uid源码介绍：https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
搭建mysql数据库环境，执行" https://gitee.com/xiaobowen-hz/yingyigou-html "提供的"yingyigou-movie.sql"生成数据库和表
项目中使用rabbitMQ作为消息队列；搭建rabbitMQ环境。项目中使用了延时队列来释放过期订单占用的座位，请额外安装延时队列插件
项目中使用elasticseach作为搜索引擎；搭建elasticseach环境
项目中使用redis作为缓存；搭建redis环境
项目中使用minio作为文件服务器；搭建minio环境
项目中使用Nginx作为备用的文件服务器；搭建nginx环境
项目中使用zookeeper作为注册中心；搭建zookeeper环境

五、使用说明

首先，需要完成所有的安装步骤；然后再修改各大模块中后缀为.yml配置文件中的连接参数。
该项目分为五大boot子项目，分别是客户端web服务、后台系统web服务、消费者远程服务、业务层远程服务提供者和es业务远程服务提供者。启动客户端服务前请务必先启动后台管理服务对搜索引擎的环境进行初始化，并提前预热影片的数据到引擎和缓存中；预热需要开启消费者服务后才能完成任务。
模块一: 客户端web服务（客户端），用于客户端的请求处理，使用了前后端分离，请务必保证跨域配置正确
模块二: 后台系统web服务务（管理端），用于后台管理系统的请求处理
模块三: 消费者远程服务（队列消费者），用于监听消息队列的消息
模块四: 业务层远程服务提供者（业务服务），用于提供常规的远程业务服务
模块五: es业务远程服务提供者（搜索中心），用于提供与搜索引擎有关的远程业务服务

六、项目服务介绍

以下模块介绍可能仅对部分业务流程列出说明，更多其他说明或详情介绍请观阅源码注释

1、客户端

1-1 页面介绍和说明

客户端大致包含影片首页、影片详情页、影院选择页、场次选择页、位置选择页、支付页、客户中心等静态页面

首页和影片详情页介绍请参考电影模块
影院选择页主要是根据影片的ID、影院的品牌和影院安排的日程筛选符合要求的影院列表，并将查询结果进行逻辑分页并展示到页面
场次选择页主要是根据影院ID查找影院详情和根据影片ID、影院ID和播放的开始日期查询当天的所有场次详情
位置选择页主要是根据场次信息的ID查询场次的详情信息和订单的创建，订单创建参考选座购票的订单创建
支付页主要包括了订单的查询和订单的支付

1-2 页面展示

首页

详情页

评论页面

影院选择页

场次选择页

位置选择页

支付页

客户中心页

搜索页

1-3 模块业务说明

电影模块

客户端的电影模块完成的主要是对影片进行一系列复杂的查询操作。首先，进入影片首页，是查询所有的影片信息用于展示热播榜和评分榜。这里没有使用搜索引擎(刚开始没有解决es查询所有数据时只返回至多10条记录的限制)和分页，不分页是因为两个榜单使用了同一个查询，而评分榜和热播榜的排序规则又不一样；所以，这里使用了js进行排序。然后，影片详情页展示了影片的详细信息和评论信息（评论展示使用了逻辑分页），这里也可以对影片进行评分和写评论。其中，主要逻辑还是围绕影片详情的数据模型而展开的处理，包含影片的多表联查（影片信息+演员+导演）；因为影片详情的查询是完全基于java代码完成的联表操作，循环和查表比较多，所以这里将影片详情的数据缓存到了redis。下一次查询便会优先从缓存中获取，以便提高查询效率。针对评论功能，详细介绍请参考评论模块。点击购票后，首先进入的是影院选择页。影院选择有关电影的操作比较简单，就是到缓存获取影片的基本信息；如果缓存没有，就到数据库查询，数据结构也简单。涉及到的主要逻辑还是关于影院的查询，详细介绍请参考影院模块；评论功能参考评论模块。
（略…）

评论模块

除了根据影片ID查询影评的功能外（用于影片详情页的影评展示），所有的增删改查功能都做了登录拦截，未登录用户不能操作。

影院模块

影院选择的主要逻辑是围绕影院的基本信息展开的多表多条件筛选处理。筛选过程介绍，第一步：如果选中了影院的品牌，首先会根据影院品牌去查询符合条件的所有影院，然后结合影片ID进行筛选；如果没有选中品牌，将会直接查询所有的影院，然后根据影片ID筛选。第二步：根据影片ID查询所有有关该影片的放映排期（即场次信息），并根据场次反向搜索所有的影院，然后根据放映的时间筛选符合条件的影院信息。第三步：进一步合并第一步和第二步的筛选结果并分页。影院详情的处理主要是围绕数据模型而展开，影院详情数据模型包括了影院的基本信息、影院的服务和影院播放的影片等信息。
（略…）

场次模块

场次，又称放映计划，在描述中可能会称其为排期或者观影计划。根据影片ID、影院ID和播放的开始日期查询当天的所有场次详情的过程介绍，第一步：根据影院ID到影厅表中查询所有的影厅，并根据影厅查询所有的放映计划，最后根据影片ID筛选计划。第二步：根据选中的观影日期筛选第一步的查询结果。第三步：将所有的场次包装到场次详情，围绕场次详情模型展开的逻辑处理，场次详情的数据模型包括了排期、归属的影厅、归属的影院、影厅类型、影片的语言版本和座位售出情况等多表实体。
（略…）

选座购票

选座购票这一块呢，其实主要就是创建订单和订单支付。订单创建成功后，在有效期内（为了开发方便，这里设置成了五分钟）可以完成付款。如果订单有效期过了（也称订单超时）就会被自动取消，同时，被占用的座位也会被自动释放。这里的自动释放座位是通过延时队列和定时任务实现的。有关订单的所有功能也都做了登录拦截，未登录的用户无法操作。

创建订单
首先，创建订单的时候，会接收到订单的座位信息和关联的影片放映计划。在接收到订单信息后会首先核查该座位是不是已经被预定，如果没有被预定的话就会锁定这个座位，也就是通常说的占座。占座成功后会生成订单的唯一流水号和订单的创建时间等相关信息，这里为了提升订单在页面的展示效果，使用了uid-generator来创建16位的纯数字ID。然后，当前的订单会以待支付的状态被记录到数据库。并且，在数据被记录到数据库以后，也是在这个时候，我把订单的ID发送到了延迟队列。其他有关订单的查询功能主要是围绕订单详情的数据模型展开，订单详情的数据模型包括了订单基本信息、放映的影片等实体信息、场次详情和其他
过期订单座位释放
因为在创建订单时已经发送了订单的ID到延迟队列，所以，我这里只需要创建一个消费者去接收这个ID，并在接收到这个消息后根据ID去查询数据当前订单的状态，如果订单仍然是待支付状态，就会被视为过期订单并释放其占有的座位。当然，为了更严格的检查开发过程中意外遗落的过期订单，我还额外创建了定时任务每隔一段时间就去扫描数据库，并检查是不是存在过期订单，如果扫描到过期订单，同样的会将这个过期订单处理掉。
订单支付
在订单支付这一块，我做的就比较简单，就是通过简单的代码逻辑来实现虚拟支付，没有模拟真正的那种支付环境。但是，在虚拟支付前，我也是做了幂等性拦截和订单超时处理的。支付成功后，订单的状态就会被修改成已支付并记录到数据库。
幂等性拦截
支付的幂等性拦截就是防止短时间内订单出现重复支付（默认是检查30秒内的重复性请求）。首先，在加载支付页时，就会获取到订单的ID，并利用axios的拦截器，在每个请求到达服务器时都携带这个ID到后台。然后，后台的幂等性拦截器就会拿到这个ID并检查这个ID在redis中是否已经存在，如果不存在就会放行这个请求并把ID记录到redis。记录的同时也给这个ID设置了30秒的有效时间。如果查询到该ID在redis已经存在，就会直接响应浏览器表示该请求已经在处理。
（略…）

支付模块

支付模块的所有功能都添加了幂等性拦截。

在执行虚拟支付请求时，会检查订单是否超时，防止意外的超时订单被支付；并同时检查订单是否已经处于支付状态，主要是为了处理超过幂等性的限制时间后，可能引发的重复支付问题。支付成功后将会修改订单的状态。
取消订单的主要逻辑就是执行虚拟退款业务。处理器在接收到退款请求时，订单的状态首先会被修改为退款中，然后抽取订单中的核心数据（如：订单ID、金额、影片的放映计划）并序列化。精简后的订单数据则会被发送到消息队列，等待消费者处理退款业务。消费者端在真正执行退款业务的时候，会检查该请求是否满足退款条件，如：离影片的开播时间是否已经小于30分钟或者影片是否已经放映结束等。只有满足退款条件的请求才能允许取消订单，取消后的订单会被标记为删除并且被占用的座位也会被重新释放。

用户模块

除了注册功能，所有有关用户的功能都添加了登录拦截，未登录用户无法访问。

用户注册。注册的话主要就是对用户的一个添加操作。首先，我给用户提供了一张表，用来给用户填写基本的账号信息。当然，用户还需要根据图片的验证信息输入验证码，验证通过后才能提交注册信息。我在做这个模块的时候，事先是定义了一个接口，这个接口的主要功能就是三个，分别对应验证码的创建、验证码的校对和用户的注册，接下来就是实现这个接口的事情。这里我就主要说明一下用户的注册，在接收到用户提交的账户信息后。我首先是检查账户是否已经被注册过，其实就是检查该账户在数据库是不是已经存在。然后，检查邮箱等数据格式是不是正确。当这些检查工作都通过后，就会生成用户ID和用户的昵称。在这里，因为考虑到用户信息安全的问题，所以对密码进行了加密处理。加密逻辑就是生成一个随机的字符串，然后把用户的密码和这个字符串进行拼接；拼接后，再通过MD5的方式对拼接后的密码进行加密，最终把加密后的字符串储存到数据库，并且也把这个随机的字符串也存到数据库中。
订单管理。订单管理主要实现的功能包括取消订单和删除订单。另外，订单管理页面在发送任何请求到服务器的时候，都会携带用户的ID到后台。这时候，后台的身份验证拦截器就会拦截到该请求。在拦截器内部，会根据传递过来的用户ID到redis中去查看该用户的信息是否存在，如果不存在，则表示该用户未登录，请求将会被拒绝；如果存在，则会放行请求到对应的处理器处理业务逻辑，并找到对应的url返回。
用户信息修改。用户在修改自己的信息时，后台仍然是先检查用户提交的数据是否满足数据应有的格式，格式不满足的请求依旧会被拒绝执行。在用户昵称传递为空时，依旧会获取随机昵称。当数据检查执行通过后，数据会被修改到数据库并更新用户在缓存中的登录信息
用户信息精确查询。通常只是根据用户ID来执行查询，查询到的用户信息将不包含用户的敏感信息（如：账号、密码等）；优先仍然是到缓存查询用户的登录信息并返回
（略…）

登录模块

用户登录时，会触发登录请求拦截。在该拦截器中，会根据用户的权限将请求分发到不同的处理器，任何不符合规范的登录请求都将会被分发到统一的登录入口，执行非法的登录请求。登录过程中，就是检查用户的账号、密码和权限是否符合数据库中记录的数据。当然，因为加密的原因，在检查用户密码时就需要特殊处理，我首先根据用户名取出当时存到数据库的那个拼接用的字符串，然后和当前的用户秘密拼接并使用MD5加密，加密之后和数据库中的加密密码进行比较，如果一致，就登陆成功；如果失败就登录失败。在用户登录成功后，信息会被保存到redis，证明用户登录成功。每次需要检查用户是否登录时，拦截器都会到缓存中查看用户信息是否存在。这个登录信息在被保存到redis的同时也被设置了默认30分钟的登录过期时间。当然，每次进入客户端处理器的任意请求都将会由另外的拦截器去刷新当前登录用户在缓存中的过期时间。也就是说，用户长时间未操作的话，登录身份是会自动过期的，并且这个时间是30分钟。
（略…）

搜索模块

搜索功能
搜索这一块呢，我用的是Elasticsearch。首先，我在电脑上安装了Linux系统，并在系统中搭建了Elasticsearch的环境【这个环境的搭建也很简单，就是先解压安装包，然后再给他自带的jdk配置环境变量，最后修改配置文件中的IP地址并开放端口的远程访问能力】。然后，开始的时候我特意设计了一个搜索引擎的初始化接口，这个接口的主要功能就是重置索引和预热数据库中的影片信息到索引库和缓存。【预热影片就是定义一个方法，把数据库里面的影片数据查询出来并封装到对象里面，然后把封装的对象一个个通过高级客户端把数据储存到搜索引擎的储存库】。为了方便关键字搜索，我还使用了es的中文分词器。当然，es还有很多其他的设置，比如：分页、高亮显示等。但是，在这个项目中我目前只是使用了分页，就是在查询前通过设置查询的起始位置和单次查询的总记录量来达到分页这个效果。如果要设置高亮的话可以通过初始化高亮生成器去设置它的高亮属性(域和前后缀)。
同步更新
在做这个搜索模块时，还有重要的一个功能，就是索引库的同步更新。在影片管理模块做增删改等逻辑的时候，我没有直接操作es索引库，而是在这里使用了消息队列。因为，当初我在考虑做这个项目的时候，是打算在后期把它改造成一个分布式项目的，然后分别部署到"Linux"系统上去运行，这个时候每个模块都应该是独立的，就不能通过代码直接去操作索引库（主要还是为了练习消息队列的使用）。在对影片进行增删改的时候，我把对影片操作的消息发布到了RabbitMQ，这里我记录了影片的id和一个代表逻辑操作的标识号【add:1232】。然后，启用了一个消费者专门去监听这个消息。当消费者接收到对影片的具体操作时，我就可以获取到对影片的操作标识，然后根据id将影片信息查询出来，并根据操作标识来判断这个查询结果的处理逻辑。如果是修改，因为搜索引擎没有修改操作，所以可以把结果直接覆盖到索引库。

2、管理端

服务启动后，会要求对搜索引擎执行初始化。实际上，就是生成搜索引擎的索引和文档。如果同名索引已经存在，则该程序会删除原先的索引重新执行初始化。重新初始化后，原先创建的文档也会被覆盖。只有当初始化工作完成后，才能进入后台管理页面。

2-1 后台管理概要

1）影片模块，主要负责管理所有的影片信息。核心功能包括添加、修改影片和管理影片的下架等

影片预热。接收到影片预热请求时，会到数据库查询所有的影片信息，并把影片的信息保存到缓存和搜索引擎。（默认只筛选评分大于5分的影片到缓存）
添加、修改或下架影片时。会在将影片信息更新到数据库的同时，将影片的数据同步到缓存和搜索引擎。

2）影院模块，主要用来管理电影院。核心功能包括添加、修改影院和影院的详情预览

3）影厅模块，主要用来管理放映厅。核心功能包括添加、修改影厅和影厅的详情预览

4）场次模块，放映场次（也叫：放映计划）主要是为了方便管理影院的播放计划。核心功能包括更新今日计划（根据影片的ID自动创建播放计划），移除历史计划、取消计划和添加单条计划

2-2 页面展示

影片管理首页

添加影片

影院修改页

影厅修改页

影片计划管理页

创建放映计划

2-3 模块业务说明

电影模块

（略…）

影院模块

影院模块实现了影院详情信息的基本增和改，并且提供了影院详情预览的功能。该模块涉及到的主要逻辑还是在已放映影片的上架和下架，不管是增加还是修改，上架和下架已放映影片都是共用同一方法。而这两者间的主要区别在于，下架已放映影片时，会检查该影片是不是已经生成过放映计划；如果已经生成了放映计划，将无法将影片从放映列表下架。

影厅模块

影厅模块实现了影厅详情信息的基本增和改，该模块的复杂点在于影厅布局的处理。在添加影厅时，由于布局表和影厅表是通过影厅的ID关联，并且影厅的ID为自增ID。所以，需要先添加影厅的基本信息到数据库后拿到其自增的ID才能将布局信息保存到数据库。修改影厅信息时，影厅的布局作为核心数据，只能被重置而不能被修改，重置的逻辑是先删除后添加。删除，如果当前影厅已经存在放映计划，将会导致布局信息删除失败（准确的说是为了防止已经生成了订单的影厅被误操作）。如果检查到该影厅没有正在进行中的放映计划，在移除布局时，该影厅产生的历史放映计划（这里指的是已经结束了的放映计划）也会被一并清理（不会清理该影厅产生的历史订单）。

场次模块

放映计划是电影院不可或缺的，同时也是数据变动异常频繁的数据。设置今日计划更新是为了每天都可以快速的生成大批量的放映计划，可在计划管理首页手动更新，也可以设置定时任务每天更新。更新规则是：每部影片在一个影院中有且仅生成一条放映计划。可以理解为同一天的同一个影院只能在一个影厅的某一段时间放映该影片（且仅限一场）。同时，也支持指定一个任意的时间来更新（默认时间是自动获取今天的时间更新）。需要注意的是，这个任意时间最好不要超过未来的五天时间，如果超过这个时间，生成的计划将无法保证当前计划的唯一性（即：可能出现重复计划）。清理历史计划时，默认是清理前30天的所有历史数据，以保证这些不必要的数据占用大量内存。取消计划时，会检查当前计划是否已经生成过订单，如果通过该计划可以查询到任何一条订单数据（包括标记为已删除的订单），将禁止取消此次计划；如果没有创建任何订单，该日程会被标记为已下架。添加单条放映计划时，仍然会检查当前计划是否已经存在，如果存在，将会导致计划创建失败。

3、消费端

3-1 模块业务说明

支付模块

接收精简版的订单数据并调用退款业务

电影模块

处理预热请求。后台管理程序启动后，可以对影片的数据进行预热，就是提前将影片的数据查询出来并保存到搜索引擎和缓存；添加和修改影片时，程序会在更新成功后将新的影片信息同步更新到搜索引擎和缓存；点击下架影片后，影片信息不会从数据库中真实删除，而是使用字段标记，并且在标记成功后会清理该影片在缓存和搜索引擎中的历史数据。
模块业务说明