文章目录

• 瑞吉外卖项目优化-Day03

• 课程内容
• 前言
• 1. 前后端分离开发

• 1.1 介绍
• 1.2 开发流程
• 1.3 前端技术栈

• 2. Yapi

• 2.1 介绍
• 2.2 使用

• 2.2.1 准备
• 2.2.2 定义接口
• 2.2.3 导出接口文档
• 2.2.4 导入接口文档

• 3. Swagger

• 3.1 介绍
• 3.2 使用方式
• 3.3 查看接口文档
• 3.4 常用注解

• 3.4.1 问题说明
• 3.4.2 注解介绍
• 3.4.3 注解测试
• 3.4.4 提交到远程仓库

• 4. 项目部署

• 4.1 部署架构
• 4.2 环境说明
• 4.3 前端部署
• 4.4 反向代理配置
• 4.5 服务端部署
• 4.6 图片展示问题处理

• 前后端分离开发
• Yapi
• Swagger
• 项目部署

外卖项目优化-03-前后端分离开发
Yapi(定义访问路径，测试controller接口，生成接口文档)
Swagger(后端直接生成controller接口描述+测试，导出接口文档)
项目部署(Nginx前端，反向代理。 Tomcat后台，shell脚本直接git pull)

当前项目中，前端代码和后端代码混合在一起，是存在问题的，存在什么问题呢？

主要存在以下几点问题：

1). 开发人员同时负责前端和后端代码开发，分工不明确

2). 开发效率低

3). 前后端代码混合在一个工程中，不便于管理

4). 对开发人员要求高(既会前端，又会后端)，人员招聘困难

为了解决上述提到的问题，现在比较主流的开发方式，就是前后端分离开发，前端人员开发前端的代码，后端开发人员开发服务端的业务功能，分工明确，各司其职。我们本章节，就是需要将之前的项目进行优化改造，变成前后端分离开发的项目。

前后端分离开发，就是在项目开发过程中，对于前端代码的开发由专门的前端开发人员负责，后端代码则由后端开发人员负责，这样可以做到分工明确、各司其职，提高开发效率，前后端代码并行开发，可以加快项目开发进度。

目前，前后端分离开发方式已经被越来越多的公司所采用，成为当前项目开发的主流开发方式。

前后端分离开发后，从工程结构上也会发生变化，即前后端代码不再混合在同一个maven工程中，而是分为 前端工程 和 后端工程 。

前后端分离之后，不仅工程结构变化，后期项目上线部署时，与之前也不同:

1). 之前: 前后端代码都混合在一起，我们只需要将前端和后端的代码统一打成jar包，直接运行就可以了。

2). 现在: 拆分为前后端分离的项目后，最终部署时，后端工程会打成一个jar包，运行在Tomcat中(springboot内嵌的tomcat)。前端工程的静态资源，会直接部署在Nginx中进行访问。

前后端分离开发后，面临一个问题，就是前端开发人员和后端开发人员如何进行配合来共同开发一个项目？可以按照如下流程进行：

1). 定制接口: 这里所说的接口不是我们之前在service， mapper层定义的interface； 这里的接口(API接口)就是一个http的请求地址，主要就是去定义：请求路径、请求方式、请求参数、响应数据等内容。(具体接口文档描述的信息, 如上图)

2). 前后端并行开发: 依据定义好的接口信息，前端人员开发前端的代码，服务端人员开发服务端的接口； 在开发中前后端都需要进行测试，后端需要通过对应的工具(PostMan、Swagger)来进行接口的测试，前端需要根据接口定义的参数进行Mock数据模拟测试。

3). 联调: 当前后端都开发完毕并且自测通过之后，就可以进行前后端的联调测试了，在这一阶段主要就是校验接口的参数格式。

4). 提测: 前后端联调测试通过之后，就可以将项目部署到测试服务器，进行自动化测试了。

1). 开发工具

Visual Studio Code (简称VsCode)

Hbuilder

2). 技术框架

A. Node.js: Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境。(类似于java语言中的JDK)。

B. Vue : 目前最火的的一个前端javaScript框架。

C. ElementUI: 一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的桌面端组件库，通过ElementUI组件可以快速构建项目页面。

D. Mock: 生成随机数据，拦截 Ajax 请求，前端可以借助于Mock生成测试数据进行功能测试。

E. Webpack: webpack 是一个现代 JavaScript 应用程序的模块打包器(module bundler)，分析你的项目结构，找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言（Sass，TypeScript等），并将其转换和打包为合适的格式供浏览器使用。

YApi 是高效、易用、功能强大的 api 管理平台，旨在为开发、产品、测试人员提供更优雅的接口管理服务。可以帮助开发者轻松创建、发布、维护 API，YApi 还为用户提供了优秀的交互体验，开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。

YApi让接口开发更简单高效，让接口的管理更具可读性、可维护性，让团队协作更合理。

源码地址: https://github.com/YMFE/yapi

官方文档: https://hellosean1025.github.io/yapi/

要使用YApi，项目组需要自己进行部署，在本项目中我们可以使用课程提供的平台进行测试，域名： https://mock-java.itheima.net/ 可惜已经不能用了

简言之： 很方便地进行接口(请求url)的定义，管理
可以在Yapi上面创建接口，前后端开发人员都可以在这个平台上看到接口，依据这些接口，开发自己的代码。

2.2.1 准备

注册账号，登录平台： https://yapi.pro/#

注意得用邮箱登录，用户名无法登录

2.2.2 定义接口

登录到Yapi平台之后，我们可以创建项目，在项目下创建接口分类，在对应的分类中添加接口。

1). 创建项目

2). 添加分类

在当前项目中,有针对于员工、菜品、套餐、订单的操作，我们在进行接口维护时，可以针对接口进行分类，如果没有对应的分类，我们自己添加分类。

3). 添加接口

接口基本信息录入之后，添加提交，就可以看到该接口的基本信息：

但是目前，接口中我们并未指定请求参数，响应数据等信息，我们可以进一步点击编辑，对该接口 详情进行编辑处理。

点击导入json，然后直接写json，会方便一点

4). 运行接口

Yapi也提供了接口测试功能，当我们接口编辑完毕后，后端服务的代码开发完毕，启动服务，就可以使用Yapi进行接口测试了。

注意： 由于菜品分页查询接口，是需要登录后才可以访问的，所以在测试该接口时，需要先请求员工管理接口中的登录接口，登录完成后，再访问该接口。

在Yapi平台中，将接口文档定义好了之后，前后端开发人员就需要根据接口文档中关于接口的描述进行前端和后端功能的开发。

测试接口功能需要下载插件，根据提示的教程下载就ok了，edge浏览器比较方便，直接应用商店搜索cross-request即可

2.2.3 导出接口文档

在Yapi平台中我们不仅可以在线阅读文档，还可以将Yapi中维护的文档直接导出来，可以导出md，json，html格式，在导出时自行选择即可 。

而在导出的html文件或md文件中，主要描述的就是接口的基本信息， 包括： 请求路径、请求方式、接口描述、请求参数、返回数据等信息。展示形式如下：

真没想到，竟然还能生成描述如此细致的文档：

2.2.4 导入接口文档

上述我们讲解了接口文档的导出，我们也可以将外部的接口文档导入到Yapi的平台中，这样我们就不用一个接口一个接口的添加了。我们可以将课程资料中提供的json格式的接口文档直接导入Yapi平台中来。

链接：https://pan.baidu.com/s/1upq_RMuFH6J4TT9BxxxB8w 提取码：gn7l

其中导入方式目前使用得比较多的还是swagger和postman
swagger方式其实就是导入swagger生成的json文件

导入过程中出现的确认弹窗，选择"确认"。

导入成功之后，我们就可以在Yapi平台查看到已导入的接口。

看看人家swagger生成的json，返回数据好完备啊：

后端人员经常使用到的工具

官网：https://swagger.io/

Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。功能主要包含以下几点:

A. 使得前后端分离开发更加方便，有利于团队协作

B. 接口文档在线自动生成，降低后端开发人员编写接口文档的负担

C. 接口功能测试

使用Swagger只需要按照它的规范去定义接口及接口相关的信息，再通过Swagger衍生出来的一系列项目和工具，就可以做到生成各种格式的接口文档，以及在线接口调试页面等等。

直接使用Swagger, 需要按照Swagger的规范定义接口, 实际上就是编写Json文件，编写起来比较繁琐、并不方便, 。而在项目中使用，我们一般会选择一些现成的框架来简化文档的编写，而这些框架是基于Swagger的，如knife4j。knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案。而我们要使用kinfe4j，需要在pom.xml中引入如下依赖即可：

接下来，我们就将我们的项目集成Knife4j，来自动生成接口文档。这里我们还是需要再创建一个新的分支v1.2，在该分支中进行knife4j的集成，集成测试完毕之后，没有问题，我们再将v1.2分支合并到master。

使用knife4j，主要需要操作以下几步:

1). 导入knife4j的maven坐标

2). 导入knife4j相关配置类

这里我们就不需要再创建一个新的配置类了，我们直接在WebMvcConfig配置类中声明即可。

A. 在该配置类中加上两个注解 @EnableSwagger2 @EnableKnife4j ,开启Swagger和Knife4j的功能。

B. 在配置类中声明一个Docket类型的bean, 通过该bean来指定生成文档的信息。

注意： Docket声明时，指定的有一个包扫描的路径，该路径指定的是Controller所在包的路径。因为Swagger在生成接口文档时，就是根据这里指定的包路径，自动的扫描该包下的@Controller， @RestController， @RequestMapping等SpringMVC的注解，依据这些注解来生成对应的接口文档。

3). 设置静态资源映射

由于Swagger生成的在线文档中，涉及到很多静态资源，这些静态资源需要添加静态资源映射，否则接口文档页面无法访问。因此需要在 WebMvcConfig类中的addResourceHandlers方法中增加如下配置。

4). 在LoginCheckFilter中设置不需要处理的请求路径

需要将Swagger及Knife4j相关的静态资源直接放行，无需登录即可访问，否则我们就需要登录之后，才可以访问接口文档的页面。

注意这些静态资源是项目一启动，swagger就会自动生成的（前提是上面的配置都做好了）

在原有的不需要处理的请求路径中，再增加如下链接：

经过上面的集成配置之后，我们的项目集成Swagger及Knife4j就已经完成了，接下来我们可以重新启动项目，访问接口文档，访问链接为： http://localhost:8080/doc.html

我们可以看到，在所有的Controller中提供的所有的业务增删改查的接口，全部都已经自动生成了，我们通过接口文档可以看到请求的url、请求方式、请求参数、请求实例、响应的参数，响应的示例。 并且呢，我们也可以通过这份在线的接口文档，对接口进行测试。

注意： 由于我们服务端的Controller中的业务增删改查的方法，都是必须登录之后才可以访问的，所以，我们在测试时候，也是需要先访问登录接口。登录完成之后，我们可以再访问其他接口进行测试。其实也可以直接用当前浏览器访问页面登陆(YApi不行，Swagger可以)

我们不仅可以在浏览器浏览生成的接口文档，Knife4j还支持离线文档，对接口文档进行下载，支持下载的格式有：markdown、html、word、openApi。

其中OpenAPI下载的就是: default_OpenAPI.json。就是之前导入YApi的json文件

生成的文档完全不逊于Yapi

• 还把Conreoller类里面所有方法的返回值当做Model整理了一下：

实在是太方便了，配置一下controller包扫描，swagger就自动帮我们生成了controller里所有接口(url请求路径)，PostMan还要自己写访问路径，Swagger就连请求路径都是项目启动时自动生成的，简直不要太方便啊

3.4.1 问题说明

在上面我们直接访问Knife4j的接口文档页面，可以查看到所有的接口文档信息，但是我们发现，这些接口文档分类及接口描述都是Controller的类名(驼峰命名转换而来)及方法名，而且在接口文档中，所有的请求参数，响应数据，都没有中文的描述，并不知道里面参数的含义，接口文档的可读性很差。

3.4.2 注解介绍

不接注解默认就显示类名、方法名、也没有任何中文描述

为了解决上述的问题，Swagger提供了很多的注解，通过这些注解，我们可以更好更清晰的描述我们的接口，包含接口的请求参数、响应数据、数据模型等。核心的注解，主要包含以下几个：

3.4.3 注解测试

以SetMeal模块为例，测试这些注解的使用，以及使用后Swagger文档有哪些展示效果

1). 实体类

可以通过 @ApiModel , @ApiModelProperty 来描述实体类及属性

2). 响应实体R

3). Controller类及其中的方法

描述Controller、方法及其方法参数，可以通过注解： @Api， @APIOperation， @ApiImplicitParams, @ApiImplicitParam

4). 重启服务测试

我们上述通过Swagger的注解，对实体类及实体类中的属性，以及Controller和Controller的方法进行描述，接下来，我们重新启动服务，然后看一下自动生成的接口文档有何变化。

在接口文档的页面中，我们可以看到接口的中文描述，清晰的看到每一个接口是做什么的，接口方法参数什么含义，参数是否是必填的，响应结果的参数是什么含义等，都可以清楚的描述出来。

总之，我们要想清晰的描述一个接口，就需要借助于Swagger给我们提供的注解。

3.4.4 提交到远程仓库

• 先直接提交v1.2分支
• 然后切换到master分支，再合并v1.2到master，再提交master分支

具体过程比较简单，不赘述了。

在本章节，我们要做的是项目的部署，包含前端项目的部署，及后端项目的部署。

具体ip可能和自己的不大一样，但是都能区分

PC端： 主要是为餐厅的员工及管理员使用的后台管理系统，对分类、菜品、套餐信息进行维护。

移动端： 可以基于微信公众号或小程序实现，我们课上并未实现，这部分的工作是前端开发人员需要开发的。

前端部署服务器： Nginx

后端部署服务器： Tomcat(boot内嵌的)

由于我们的服务器数量有限，就使用这三台服务器，具体的软件规划如下:

由于我们前面的课程中Nginx、MySQL的主从复制、Redis、JDK、Git、Maven都已经演示过安装及配置了，这里我们就不再演示软件的安装了。

1). 在服务器A(192.168.138.100)中安装Nginx，将课程资料中的dist目录上传到Nginx的html目录下

将整个dist目录上传至/usr/local/nginx/html目录下
不能直接上传目录，得先打包再解包，注意用7zip打成tar包，否则linux端解包不了

直接解压到当前目录

2). 修改Nginx配置文件nginx.conf

将nginx.conf配置文件中，将原有的监听80, 82, 8080端口号 的虚拟主机注释掉，引入如下的配置信息：

vim比较麻烦，可以在下面ftp目录中双击打开编辑

注意此时若nginx已经启动，要么重启，要么刷新一下配置文件

此时还没有启动nginx，直接启动即可，会自动加载最新的配置文件

3). 通过nginx访问前端工程

http://192.168.141.100

前端工程部署完成之后，我们可以正常的访问到系统的登录页面，点击登录按钮，可以看到服务端发起的请求，请求信息如下：

而大家知道，在我们之前开发的工程中，是没有/api这个前缀的,那这个时候,在不修改服务端代码的情况下，如何处理该请求呢?

实际上，通过nginx的配置就可以轻松解决这个问题。

在上述我们配置的nginx.conf中，除了配置了静态资源的加载目录以外，我们还配置了一段反向代理的配置，配置信息如下：

这一段配置代表，如果请求当前nginx，并且请求的路径如果是 /api/ 开头，将会被该location处理。而在该location中，主要配置了两块儿信息： rewrite(url重写) 和 proxy_pass(反向代理)。 接下来我们就来解析一下这两项的配置。

1). 路径重写rewrite

这里写的是一个正则表达式，代表如果请求路径是以 开头，后面的请求路径任意，此时将原始的url路径重写为 ，这里的指代的就是通配符 .* 这一块的内容。比如：

2). 反向代理

路径重写后的请求，将会转发到后端的 http://192.168.138.101:8080 服务器中。 而这台服务器中，就部署的是我们的后端服务。

注意，以下都在101服务器上做

1). 在服务器B(192.168.138.101)中安装jdk、git、maven、MySQL，使用git clone命令将git远程仓库的代码克隆下来

A. 确认JDK环境

B. 确认Git环境

C. 确认Maven环境

D. 将我们开发完成的代码推送至远程仓库,并在服务器B中克隆下来

前端不是我们自己单独开发的，就上传人家的
后端是我们自己开发的，gitee仓库有，就直接clone了

2). 将资料中提供的reggieStart.sh文件上传到服务器B，通过chmod命令设置执行权限

3). 执行reggieStart.sh脚本文件，自动部署项目

注意项目打包方式得是jar包，而非war包，如果不是，修改后重新push

执行完shell脚本之后，我们可以通过 ps -ef|grep java 指令，查看服务是否启动。

4). 访问系统测试

http://192.168.141.100/

换了一套前端页面，后端是我们自己开发的，但是只要请求接口是对应地，就完全没有问题，完美适配

在上述的测试中，我们发现菜品的图片无法正常展示。原因是因为，在我们的配置文件中，图片信息依然是从 E:prodataimg 中加载的，但是在Linux服务器中，是不存在E盘的。

1). 修改文件存储目录

将文件存储目录修改为：

修改完成之后，需要将变动的代码提交到本地仓库，并推送至远程仓库。

2). 执行shell脚本,进行自动化部署

3). 将本地的测试图片文件夹img(整个文件夹)上传到服务器B的/usr/local目录下

4).访问测试

http://192.168.141.100/ 请求的还是服务器A(100), 但是实际提供服务的还是服务器B(101)

redis我也放在100服务器上，也要手动启动一下下

reggie_take_out/target/reggie_take_out.log 可以查看日志，项目上线之后，log.info直接就不打印了，只在开发环境下打印，也太智能了，果然比syso直接打印要好。

外卖项目，到此正式结束

https://gitee.com/hzawhu/reggie_take_out/tree/v1.0

真的学了不少东西