SpringBoot（七）——SpringBoot服务中的监控（druid 监控、Admin 监控）、SpringBoot原理（可执行 jar 包、自动化配置—Starter）、整合Swagger2_druid admin

SpringBoot（七）——SpringBoot服务中的监控（druid 监控、Admin 监控）、SpringBoot原理（可执行 jar 包、自动化配置—Starter）、整合Swagger2

一、SpringBoot服务中的监控

1、监控介绍

2、druid 服务监控

a、前期准备

依赖导入：先导入 druid，这个自带了数据库连接池监控：

然后开始配置（主要是需要配置三个东西）：

b、进入监控页面

输入这个地址就能进入监控页面：

然后就能看到页面：

c、去除广告

因为是阿里的玩意，所以页面下方是有广告的，去除广告也是可以的：
写一个过滤器（广告来自于 common.js 文件里面的某个方法，所以找到那个，然后过滤掉就可以）：

然后加个扫描：

然后就能发现广告没有了。

3、SpringBootAdmin 监控

这个服务监控要有两个服务。服务端负责监控其他应用。

a（1）、服务端前期准备

一个注解就完事：

a（2）、客户端前期准备

然后简单写一个例子：

监控一个应用的数据信息，首先就需要这个应用把数据暴露数来，如果想要暴露一个应用的数据，上图中，就选第一个，暴露出来的数据是 json 格式的数据；client 依赖会自动收集 Actuator 的数据，上报给 server，server 收集到数据以后，会进行渲染，然后展示出来。无论是什么用什么工具，都需要 Actuator 。

b、页面展示

看一下监控页面：
开启服务端：
首先输入这个 url，然后就会自动跳转：

c、查看信息（暴露的数据）

数据暴露出来后怎么访问呢？

然后看下访问结果：

意思是查看项目的健康状况，这个意思是项目在线。

如果想要看更详细的信息，需要加配置（客户端配置），然后启动客户端：


然后就能发现多了很多信息，甚至还能测试接口：

d、上报 json 信息到服务端

可以发现查看这些 json 信息不方便，可以从网页来查看，就需要上报，上报要配置 server 在哪：

然后效果：

点击进入，可以查看应用的详细信息：

如果这时关闭客户端，一般来说会告诉我们应用掉线了：

但是这个还不够，我们可以设置如果服务掉线了给我们发一封邮件：

e、服务掉线自动发邮件

在服务端写。
首先需要加入邮箱的依赖。
大致用法：

甚至 钉钉和企业微信都支持：

详细功能自行翻阅上篇博客，有教到发送邮件。

二、SpringBoot原理

1、可执行 jar 包

a、可执行 jar 包解释

其他的 jar 包无法直接运行，但是 SpringBoot 的可以直接运行；但是能直接运行也是有代价的，代价就是无法被其他项目所依赖。
拿上面的例子来打包：

打包后就会出现这两个东西。

于是我们尝试导入第一个 jar 包，尝试去使用：


可以发现报错，无法使用。这就是前面说的代价。这是因为 SpringBoot 里面有一个打包的插件：

点开后可以发现有其他功能：

第一个功能是镜像，这个指令可以把 SpringBoot 打包成 image，放到 docker 容器里面跑。

第二个是生成项目的构建信息。

第三个是帮助信息。

第四个是重复打包（重点）。很明显一开始打包的时候，就是使用原本的打包指令，也就是可以被其他项目锁依赖，不能运行；之后才是运行这个，二次打包，结果就是打包成可执行的 jar；那么一开始的 jar 包哪里去了呢？就是打包后的第二个文件，这个才是 maven 正常打包出来的。第一个 jar 文件是在第二个 jar 文件的基础上用 SpringBoot 的插件二次打包出来的。这时候如果导入的是第二个 jar 文件（要把后面的后缀删掉，只留 .jar），就能发现就是正常的打包文件。

b、分离可执行 jar 包与可依赖 jar 包

如果想把可执行 jar 包跟可依赖的 jar 包区分开来，可以这么做：

这时候在执行原生的打包，然后看结果：

下面的是可执行 jar。

2、自动化配置——Starter

先自己写一个例子帮助理解，写一个统计单元方法执行时间的方法。

a、前期准备

然后删掉部分依赖，只留下小部分，下面截图是留下的依赖：

那么现在就是一个普通的 maven 工程。

b、代码

第一步，自定义注解：

然后：


文件目录：

c、安装

接着就是安装到本地仓库中去。不是打包！！！

d、使用

接着就是新建一个项目，然后导入。

这时候想要统计时间很简单，在方法上加一个 @TimeLog：

结果：

如果想关掉：

三、SpringBoot 整合 Swagger2

首先这里先说明一点：运行 swagger2 会报个错误，这个错误不用管：

1、引言和介绍

swagger 不同版本的用法差别还是十分大的。

目前用得比较多的还是 swagger2。swagger 开源免费。

开发的时候需要有个规范，所以这时开发文档显得尤为重要。开发文档会约定各种开发细节：接口路径、参数、返回值等等。

swagger2 可以根据后端的接口，自动生成接口文档

2、前期准备

接着是 swagger2 的依赖版本和 SpringBoot 版本：

这两个的依赖分别是不同的作用，看上图注释。

接着 application：

3、简单使用 swagger2 ，网页展示接口信息

a、Get方法

首先是启动类要配置注解，开启 swagger2：

然后配置类配置 swagger2：

然后写一个接口：

然后网站效果：

可以看到有个 hello 的接口文档了，点进去就能看到详细信息（用得是 GetMapping，所以展示的是 get 请求，）：

b、post 方法

4、@ApiOperation——接口注释

虽然一般方法起名都会尽量的按照见名知意的原则，但是如果想要网站描述接口，可以通过注解 @ApiOperation 来描述接口：

效果：

5、@Api(tags = “xxx”)——类注释

同理，一般类起名也是见名知意；这里同样有注解给类注释：

效果：

注意：tags 是一个 Spring 数组，所以如果有多个注释都可以展示出来。

6、 @ApiImplicitParam（…）——描述参数的含义

@ApiImplicitParam：这个注解可以用来描述这个参数的含义。

如果是有多个参数呢？

如果有多个参数，就使用 @ApiImplicitParams（{ @ApiImplicitParam… }），这个注解里面用多个 @ApiImplicitParam 注解来一个个描述参数：

7、@ApiImplicitParam（required= xx）——必填参数

还有个参数，就是 required，这个的属性来描述该参数是否是必须参数。

当值为 true 时就是必填参数。但是如果该参数是必填的，一般都是在参数前面使用注解 @RequestParam ；如果使用了这个注解，但没用 required 这个属性，也会显示该参数要必填。但是如果不使用 @RequestParam 注解，而只去使用 required 属性描述是不行的，因为这个作用只是在 swagger2 网站测试接口的时候必填而已。

效果：

8、参数形式的提示

除了 query ，还有 path 和 body 提示。

query：代表参数是 key—value 形式的。

path：代表参数将来是要放在路径中的。

body：代表参数将来是以 Json 格式传输。

9、描述实体类（对象）参数

这里随便新建一个实体类。

比如现在做一个更新接口：

参数是实体类，那么怎么描述实体类呢？这时可就不是用上面的方式来描述了。

描述对象，直接在实体类中加注解来描述：

效果：

10、@ApiResponse——描述响应信息

响应成功或者失败，也可以有注解描述：

效果：
点开接口的详细信息，往下拉可以看到：