前言

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

image-20220812091312419

主要存在以下几点问题：

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

2). 开发效率低

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

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

为了解决上述问题，现在比较主流的开发方式，就是前后端分离开发，前端人员开发前端的代码，后端开发人员开发服务端的业务功能，分工明确，各司其职。

1. 前后端分离开发

1.1 介绍

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

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

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

image-20220812091340909

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

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

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

1.2 开发流程

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

image-20220812091353345

image-20220812091403361

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

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

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

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

1.3 前端技术栈

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等），并将其转换和打包为合适的格式供浏览器使用。

2. Yapi

2.1 介绍

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

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

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

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

2.2 使用

  1. 创建项目
  2. 添加分类
  3. 添加接口
  4. 运行接口

还可以进行接口文档的导入导出

3. Swagger

3.1 介绍

官网：https://swagger.io/

image-20220812091748924

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

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

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

  3. 接口功能测试

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

直接使用Swagger, 需要按照Swagger的规范定义接口, 实际上就是编写Json文件，编写起来比较繁琐、并不方便,。

而在项目中使用，一般会选择一些现成的框架来简化文档的编写，而这些框架是基于Swagger的，如knife4j。

knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案。

3.2 使用方式

1、导入knife4j的maven坐标

1
2
3
4
5
<dependency>
    <groupId>com.github.xiaoymin</groupId>
    <artifactId>knife4j-spring-boot-starter</artifactId>
    <version>3.0.2</version>
</dependency>

2、 导入knife4j相关配置类

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

image-20220812094755191

  1. 在配置类中声明一个Docket类型的bean, 通过该bean来指定生成文档的信息。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Bean
public Docket createRestApi() {
    //文档类型
    return new Docket(DocumentationType.SWAGGER_2)
            .apiInfo(apiInfo())
            .select()
            .apis(RequestHandlerSelectors.basePackage("com.itheima.reggie.controller"))
            .paths(PathSelectors.any())
            .build();
}

private ApiInfo apiInfo() {
    return new ApiInfoBuilder()
            .title("瑞吉外卖")
            .version("1.0")
            .description("瑞吉外卖接口文档")
            .build();
}

==注意：==

image-20220812094849337

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

3)、设置静态资源映射

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

1
2
registry.addResourceHandler("doc.html").addResourceLocations("classpath:/META-INF/resources/");
registry.addResourceHandler("/webjars/**").addResourceLocations("classpath:/META-INF/resources/webjars/");

image-20220812094958417

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

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

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

1
2
3
4
"/doc.html",
"/webjars/**",
"/swagger-resources",
"/v2/api-docs"

image-20220812095044324

3.3 查看接口文档

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

image-20220812095131345

3.4 常用注解

问题说明

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

image-20220812095226328

注解介绍

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

注解 位置 说明
@Api 类 加载Controller类上,表示对类的说明
@ApiModel 类(通常是实体类) 描述实体类的作用
@ApiModelProperty 属性 描述实体类的属性
@ApiOperation 方法 说明方法的用途、作用
@ApiImplicitParams 方法 表示一组参数说明
@ApiImplicitParam 方法 用在@ApiImplicitParams注解中，指定一个请求参数的各个方面的属性

4. 项目部署

4.1 部署架构

image-20220812101422138

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

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

前端部署服务器： Nginx

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

4.2 环境说明

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

服务器 软件 名称
192.168.2.200 Nginx(部署前端项目、配置反向代理)，MySQL(主从复制的主库) 服务器A
192.168.2.201 JDK1.8、Git、Maven、jar(项目jar包基于内嵌Tomcat运行)、MySQL(主从复制的从库) 服务器B
localhost Redis(缓存中间件) 服务器C

==这里选择自己的那两个虚拟机，有云服务器的用云服务器也可以==

4.3 前端部署

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

image-20220812101555205

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  server {
      listen       80;
      server_name  localhost;

      location / {
          root   html/dist;
          index  index.html;
      }

location ^~ /api/ {
	rewrite ^/api/(.*)$ /$1 break;
	proxy_pass http://192.168.2.200:8080;
}

      location = /50x.html {
          root   html;
      }
  }

这里写自己虚拟机的ip地址

3、通过nginx访问前端工程

192.168.2.200

image-20220812103111665

4.4 反向代理配置

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

image-20220812104222038

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

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

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

1
2
3
4
location ^~ /api/ {
    rewrite ^/api/(.*)$ /$1 break;
    proxy_pass http://192.168.2.201:8080;
}

这一段配置代表，如果请求当前nginx，并且请求的路径如果是 /api/ 开头，将会被该location处理。

而在该location中，主要配置了两块儿信息： rewrite(url重写) 和 proxy_pass(反向代理)。

配置解析：

1). 路径重写rewrite

1
rewrite ^/api/(.*)$ /$1 break;

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

比如： 

1
/api/employee/login ------> ^/api/(.*)$ --------> 此时 (.*) 匹配的就是 employee/login ------> 最终重写为/$1 : /employee/login

2). 反向代理

1
proxy_pass http://192.168.2.201:8080;

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

4.5 服务端部署

1、 在服务器B(192.168.138.101)中安装jdk、git、maven、MySQL

之前都弄过了，略

2、使用git clone命令将git远程仓库的代码克隆下来

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

1
2
3
4
5
6
7
8
#创建java代码存放目录
mkdir -p /usr/local/javaapp

#切换目录
cd /usr/local/javaapp

#克隆代码 , 需要使用自己的远程仓库
git clone 自己的远程仓库

image-20220812105127644

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

image-20220812110653621

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

image-20220812110906765

等待打包完成

image-20220812111002236

登陆成功

image-20220812111042376

4.6 图片展示问题处理

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

1、修改图片存储目录

image-20220812111122498

修改为：

1
2
reggie:
  path: /usr/local/img/

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

2.将本地的图片文件夹上传到服务器

image-20220812111753101

3.重新执行shell脚本,进行自动化部署

image-20220812111443235

4.测试

成功获取到图片

image-20220812111829927

🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉

🎉🎉 完结撒花 🎉🎉

🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉