Notion Blog

如何优雅地导入导出数据？

Sun, 21 Jul 2024 00:00:00 GMT

背景 EasyExcel 介绍 EasyExcel中的注解 @ExcelProperty @ExcelIgnore @ExcelIgnoreUnannotated @DateTimeFormat @NumberFormat @ColumnWith @ContentRowHeight @ContentFontStyle @ContentStyle 数据导出（写Excel）controller 使用UserRespVO实现数据导出 ExcelUtils 数据导入（读Excel）controller 使用UserImportExcelVO实现数据导入 ExcelUtils 字段转换器

背景

在SpringBoot项目中，数据导入导出是非常常见的需求。无论是从数据库导出数据到Excel文件，还是从Excel文件导入数据到系统中，都会涉及到数据的格式转换、校验以及异常处理等多个方面。优雅地实现这些功能，能够提高系统的可靠性和用户体验。

EasyExcel

介绍

EasyExcel 是阿里开源的 Excel 工具库，具有简单易用、低内存、高性能的特点。

在尽可用节约内存的情况下，支持百万行的 Excel 读写操作。例如说，仅使用 64M 内存，20 秒完成 75M（46 万行 25 列）Excel 的读取。并且，还有极速模式能更快，但是内存占用会在100M 多一点。

EasyExcel中的注解

`@ExcelProperty`

用于匹配excel和实体类的匹配，参数如下：

名称	默认值	描述
value	空	列名，用于匹配excel中的头，必须全匹配，如果有多行头，会匹配最后一行头
order	Integer.MAX_VALUE	列序号，优先级高于`value`，会根据`order`的顺序来匹配实体和excel中数据的顺序
index	-1	优先级高于`value`和`order`，会根据`index`直接指定到excel中具体的哪一列
converter	自动选择	指定当前字段用什么转换器，默认会自动选择。写的情况下只要实现`com.alibaba.excel.converters.Converter#convertToExcelData(com.alibaba.excel.converters.WriteConverterContext)` 方法即可

`@ExcelIgnore`

默认所有字段都会和excel去匹配，加了这个注解会忽略该字段

`@ExcelIgnoreUnannotated`

默认不管加不加ExcelProperty的注解的所有字段都会参与读写，加了ExcelIgnoreUnannotated注解以后，不加ExcelProperty注解的字段就不会参与

`@DateTimeFormat`

日期转换，用String去接收excel日期格式的数据会调用这个注解，参数如下：

名称	默认值	描述
value	空	参照`java.text.SimpleDateFormat`书写即可
use1904windowing	自动选择	excel中时间是存储1900年起的一个双精度浮点数，但是有时候默认开始日期是1904，所以设置这个值改成默认1904年开始

`@NumberFormat`

数字转换，用String去接收excel数字格式的数据会调用这个注解。

名称	默认值	描述
value	空	参照`java.text.DecimalFormat`书写即可
roundingMode	RoundingMode.HALF_UP	格式化的时候设置舍入模式

`@ColumnWith`

用于设置列宽度的注解，注解中只有一个参数value，value的单位是字符长度，最大可以设置255个字符，因为一个excel单元格最大可以写入的字符个数就是255个字符。

`@ContentRowHeight`

用于设置行高，参数：value行高，-1代表自动行高

`@ContentFontStyle`

用于设置单元格内容字体格式的注解

参数	含义
`fontName`	字体名称
`fontHeightInPoints`	字体高度
`italic`	是否斜体
`strikeout`	是否设置删除水平线
`color`	字体颜色
`typeOffset`	偏移量
`underline`	下划线
`bold`	是否加粗
`charset`	编码格式

`@ContentStyle`

设置内容格式注解

参数	含义
`dataFormat`	日期格式
`hidden`	设置单元格使用此样式隐藏
`locked`	设置单元格使用此样式锁定
`quotePrefix`	在单元格前面增加`符号，数字或公式将以字符串形式展示
`horizontalAlignment`	设置是否水平居中
`wrapped`	设置文本是否应换行。将此标志设置为`true`通过在多行上显示使单元格中的所有内容可见
`verticalAlignment`	设置是否垂直居中
`rotation`	设置单元格中文本旋转角度。03版本的Excel旋转角度区间为-90°~90°，07版本的Excel旋转角度区间为0°~180°
`indent`	设置单元格中缩进文本的空格数
`borderLeft`	设置左边框的样式
`borderRight`	设置右边框样式
`borderTop`	设置上边框样式
`borderBottom`	设置下边框样式
`leftBorderColor`	设置左边框颜色
`rightBorderColor`	设置右边框颜色
`topBorderColor`	设置上边框颜色
`bottomBorderColor`	设置下边框颜色
`fillPatternType`	设置填充类型
`fillBackgroundColor`	设置背景色
`fillForegroundColor`	设置前景色
`shrinkToFit`	设置自动单元格自动大小

数据导出（写Excel）

controller

将从数据库中查询出来的列表，一般可以复用分页接口，需要设置 .setPageSize(PageParam.PAGE_SIZE_NONE) 不过滤分页

将 PostDO 列表，转换成 PostRespVO 列表，之后通过 ExcelUtils 转换成 Excel 文件，返回给前端。

使用`UserRespVO`实现数据导出

`ExcelUtils`

数据导入（读Excel）

controller

使用`UserImportExcelVO`实现数据导入

`ExcelUtils`

字段转换器

如果字段的的注解 converter 属性是 DictConvert 转换器，用于字典的转换。例如说，通过 status 字段，将 status = 1 转换成“开启”列，status = 0 转换成”禁用”列。

EasyExcel定义了 Convert 接口，用于实现字段的转换。它有两个核心方法：

convertToJavaData(...) 方法：将 Excel Row 对应表格的值，转换成 Java 内存中的值。例如说，Excel 的“状态”列，将“状态”列转换成 status = 1，”禁用”列转换成 status = 0。

convertToExcelData(...) 方法：恰好相反，将 Java 内存中的值，转换成 Excel Row 对应表格的值。例如说，Excel 的“状态”列，将 status = 1 转换成“开启”列，status = 0 转换成”禁用”列

Docker

Fri, 02 Jul 2021 00:00:00 GMT

初识Docker 什么是Docker？应用部署的环境问题 Docker解决依赖兼容问题 Docker解决操作系统环境差异 Docker和虚拟机的区别 Docker架构镜像和容器 DockerHub Docker架构安装Docker 卸载（可选）安装docker 启动docker 配置镜像加速 Docker的基本操作镜像操作镜像名称镜像命令案例1：拉取、查看镜像案例2：保存、导入镜像容器操作容器相关命令案例：创建并运行一个容器案例：进入容器，修改文件其他命令数据卷（容器数据管理）什么是数据卷数据集操作命令创建和查看数据卷挂载数据卷案例：给nginx挂载数据卷案例：给MySQL挂载本地目录 Dockerfile自定义镜像镜像结构 Dockerfile语法构建Java项目基于Ubuntu构建Java项目基于java8构建Java项目小结 Docker-Compose 初识DockerCompose 安装DockerCompose 下载修改执行权限查看docker-compose版本 Base自动补全命令部署微服务集群 compose文件修改微服务配置打包部署 Docker镜像仓库搭建私有镜像仓库简化版镜像仓库带有图形化界面版本配置Docker信任地址推送、拉取镜像

初识Docker

什么是Docker？

微服务虽然具备各种各样的优势，但服务的拆分通用给部署带来了很大的麻烦。

分布式系统中，依赖的组件非常多，不同组件之间部署时往往会产生一些冲突。

在数百上千台服务中重复部署，环境不一定一致，会遇到各种问题

应用部署的环境问题

大型项目组件较多，运行环境也较为复杂，部署时会碰到一些问题：

依赖关系复杂，容易出现兼容性问题

开发、测试、生产环境有差异

例如一个项目中，部署时需要依赖于node.js、Redis、RabbitMQ、MySQL等，这些服务部署时所需要的函数库、依赖项各不相同，甚至会有冲突。给部署带来了极大的困难。

Docker解决依赖兼容问题

而Docker确巧妙的解决了这些问题，Docker是如何实现的呢？

Docker为了解决依赖的兼容问题的，采用了两个手段：

将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包形成镜像

将每个应用放到一个隔离容器去运行，避免互相干扰

这样打包好的应用包中，既包含应用本身，也保护应用所需要的Libs、Deps，无需再操作系统上安装这些，自然就不存在不同应用之间的兼容问题了。

虽然解决了不同应用的兼容问题，但是开发、测试等环境会存在差异，操作系统版本也会有差异，怎么解决这些问题呢？

Docker解决操作系统环境差异

要解决不同操作系统环境差异问题，必须先了解操作系统结构。以一个Ubuntu操作系统为例，结构如下：

结构包括：

计算机硬件：例如CPU、内存、磁盘等

系统内核：所有Linux发行版的内核都是Linux，例如CentOS、Ubuntu、Fedora等。内核可以与计算机硬件交互，对外提供内核指令，用于操作计算机硬件。

系统应用：操作系统本身提供的应用、函数库。这些函数库是对内核指令的封装，使用更加方便。

应用于计算机交互的流程如下：

应用调用操作系统应用（函数库），实现各种功能

系统函数库是对内核指令集的封装，会调用内核指令

内核指令操作计算机硬件

Ubuntu和CentOSpringBoot都是基于Linux内核，无非是系统应用不同，提供的函数库有差异：

此时，如果将一个Ubuntu版本的MySQL应用安装到CentOS系统，MySQL在调用Ubuntu函数库时，会发现找不到或者不匹配，就会报错了：

Docker如何解决不同系统环境的问题？

Docker将用户程序与所需要调用的系统(比如Ubuntu)函数库一起打包

Docker运行到不同操作系统时，直接基于打包的函数库，借助于操作系统的Linux内核来运行

如图：

Docker和虚拟机的区别

虚拟机（virtual machine）是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的Ubuntu应用了。

Docker仅仅是封装函数库，并没有模拟完整的操作系统，如图：

💡

Docker和虚拟机的差异：

Docker是一个系统进程；虚拟机是在操作系统中的操作系统

Docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

Docker架构

镜像和容器

Docker中有几个重要的概念：

镜像（Image）：Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。

容器（Container）：镜像中的应用程序运行后形成的进程就是容器，只是Docker会给容器进程做隔离，对外不可见。

一切应用最终都是代码组成，都是硬盘中的一个个的字节形成的文件。只有运行时，才会加载到内存，形成进程。
而镜像，就是把一个应用在硬盘上的文件、及其运行环境、部分系统函数库文件一起打包形成的文件包。这个文件包是只读的。
容器呢，就是将这些文件中编写的程序、函数加载到内存中允许，形成进程，只不过要隔离起来。因此一个镜像可以启动多次，形成多个容器进程。
例如你下载了一个QQ，如果我们将QQ在磁盘上的运行文件及其运行的操作系统依赖打包，形成QQ镜像。然后你可以启动多次，双开、甚至三开QQ。

DockerHub

开源应用程序非常多，打包这些应用往往是重复的劳动。为了避免这些重复劳动，人们就会将自己打包的应用镜像，例如Redis、MySQL镜像放到网络上，共享使用，就像GitHub的代码共享一样。

DockerHub：DockerHub是一个官方的Docker镜像的托管平台。这样的平台称为Docker Registry。

国内也有类似于DockerHub 的公开服务，比如网易云镜像服务、阿里云镜像库等。

我们一方面可以将自己的镜像共享到DockerHub，另一方面也可以从DockerHub拉取镜像。

Docker架构

我们要使用Docker来操作镜像、容器，就必须要安装Docker。

Docker是一个CS架构的程序，由两部分组成：

服务端(server)：Docker守护进程，负责处理Docker指令，管理镜像、容器等

客户端(client)：通过命令或RestAPI向Docker服务端发送指令。可以在本地或远程向服务端发送指令。

安装Docker

企业部署一般都是采用Linux操作系统，而其中又数CentOS发行版占比最多，因此我们在CentOS下安装Docker。

Docker 分为 CE 和 EE 两大版本。CE 即社区版（免费，支持周期 7 个月），EE 即企业版，强调安全，付费使用，支持周期 24 个月。

Docker CE 分为 stable test 和 nightly 三个更新频道。

官方网站上有各种环境下的安装指南，这里主要介绍 Docker CE 在 CentOS上的安装。

卸载（可选）

安装docker

启动docker

Docker应用需要用到各种端口，逐一去修改防火墙设置。非常麻烦，因此建议大家直接关闭防火墙！

启动docker前，一定要关闭防火墙后！！

配置镜像加速

docker官方镜像仓库网速较差，我们需要设置国内镜像服务：参考阿里云的镜像加速文档：https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors

Docker的基本操作

镜像操作

镜像名称

首先来看下镜像的名称组成：

镜名称一般分两部分组成：[repository]:[tag]

在没有指定tag时，默认是latest，代表最新版本的镜像

如图：

这里的mysql就是repository，5.7就是tag，合一起就是镜像名称，代表5.7版本的MySQL镜像。

镜像命令

常见的镜像操作命令如图：

案例1：拉取、查看镜像

需求：从DockerHub中拉取一个nginx镜像并查看

首先去镜像仓库DockerHub搜索nginx镜像。

根据查看到的镜像名称，拉取自己需要的镜像，通过命令：docker pull nginx

通过命令：docker images 查看拉取到的镜像

案例2：保存、导入镜像

需求：利用docker save将nginx镜像导出磁盘，然后再通过load加载回来

利用docker xx --help命令查看docker save和docker load的语法

例如，查看save命令用法，可以输入命令：docker save --help，可知命令格式：docker save -o [保存的目标文件名称] [镜像名称]

使用docker save导出镜像到磁盘：运行命令：docker save -o nginx.tar nginx:latest，

使用docker load加载镜像

先删除本地的nginx镜像：docker rmi nginx:latest，然后运行命令，加载本地文件：docker load -i nginx.tar

容器操作

容器相关命令

容器操作的命令如图：

容器保护三个状态：

运行：进程正常运行

暂停：进程暂停，CPU不再运行，并不释放内存

停止：进程终止，回收进程占用的内存、CPU等资源

其中：

docker run：创建并运行一个容器，处于运行状态

docker pause：让一个运行的容器暂停

docker unpause：让一个容器从暂停状态恢复运行

docker stop：停止一个运行的容器

docker start：让一个停止的容器再次运行

docker restart：重启容器

docker rm：删除一个容器

案例：创建并运行一个容器

创建并运行nginx容器的命令：

命令解读：
docker run：创建并运行一个容器
—name：给容器起一个名字，比如叫做mynginx
-p：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口
-d：后台运行容器
--restart：随docker的启动而启动
nginx：镜像名称，例如nginx

这里的-p参数，是将容器端口映射到宿主机端口。默认情况下，容器是隔离环境，我们直接访问宿主机的80端口，肯定访问不到容器中的nginx。现在，将容器的80与宿主机的80关联起来，当我们访问宿主机的80端口时，就会被映射到容器的80，这样就能访问到nginx了。

案例：进入容器，修改文件

需求：进入Nginx容器，修改HTML文件内容，添加“Frank欢迎您”

提示：进入容器要用到docker exec命令。

步骤：

进入容器。进入我们刚刚创建的nginx容器的命令为：docker exec -it mynginx bash

命令解读：
docker exec：进入容器内部，执行一个命令
-it: 给当前进入的容器创建一个标准输入、输出终端，允许我们与容器交互
mynginx：要进入的容器的名称
bash：进入容器后执行的命令，bash是一个linux终端交互命令

进入nginx的HTML所在目录 /usr/share/nginx/html

容器内部会模拟一个独立的Linux文件系统，看起来如同一个linux服务器一样：

nginx的环境、配置、运行文件全部都在这个文件系统中，包括我们要修改的html文件。

查看DockerHub网站中的nginx页面，可以知道nginx的html目录位置在/usr/share/nginx/html

我们执行命令，进入该目录：

查看目录下文件：

修改index.html的内容

容器内没有vi命令，无法直接修改，我们用下面的命令来修改：

在浏览器访问自己的虚拟机地址，例如我的是：http://192.168.10.100:80，即可看到结果。

其他命令

查看容器日志的命令：

docker logs

添加 -f 参数可以持续查看日志

查看容器状态：

docker ps：只能查看目前正在运行的容器

docker ps -a：查看所有容器，包括已经停止的

数据卷（容器数据管理）

在之前的nginx案例中，修改nginx的html页面时，需要进入nginx内部。并且因为没有编辑器，修改文件也很麻烦。这就是因为容器与数据（容器内文件）耦合带来的后果。要解决这个问题，必须将数据与容器解耦，这就要用到数据卷了。

什么是数据卷

数据卷（volume）是一个虚拟目录，指向宿主机文件系统中的某个目录。

一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。

这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了。

数据集操作命令

数据卷操作的基本语法如下：

docker volume命令是数据卷操作，根据命令后跟随的command来确定下一步的操作：

create：创建一个volume

inspect：显示一个或多个volume的信息

ls：列出所有的volume

prune：删除未使用的volume

rm：删除一个或多个指定的volume

创建和查看数据卷

需求：创建一个数据卷，并查看数据卷在宿主机的目录位置

创建数据卷：docker volume create html

查看所有数据：docker volume ls

查看数据卷详细信息卷：docker volume inspect html

可以看到，我们创建的html这个数据卷关联的宿主机目录为/var/lib/docker/volumes/html/_data目录。

挂载数据卷

我们在创建容器时，可以通过 -v 参数来挂载一个数据卷到某个容器内目录，命令格式如下：

这里的-v就是挂载数据卷的命令
-v html:/root/htm ：把html数据卷挂载到容器内的/root/html这个目录中

案例：给nginx挂载数据卷

需求：创建一个nginx容器，修改容器内的html目录内的index.html内容

分析：上个案例中，我们进入nginx容器内部，已经知道nginx的html目录所在位置/usr/share/nginx/html ，我们需要把这个目录挂载到html这个数据卷上，方便操作其中的内容。

提示：运行容器时使用 -v 参数挂载数据卷

步骤：

创建容器并挂载数据卷到容器内的HTML目录

进入html数据卷所在位置，并修改HTML内容

案例：给MySQL挂载本地目录

容器不仅仅可以挂载数据卷，也可以直接挂载到宿主机目录上。关联关系如下：

带数据卷模式：宿主机目录→数据卷→容器内目录

直接挂载模式：宿主机目录→容器内目录

如图：

语法：

目录挂载与数据卷挂载的语法是类似的：

-v [宿主机文件]:[容器内文件]

需求：创建并运行一个MySQL容器，将宿主机目录直接挂载到容器。实现思路如下：

将mysql.tar文件上传到虚拟机，通过load命令加载为镜像

创建目录/tmp/mysql/conf，将hmy.cnf文件上传到/tmp/mysql/conf

去DockerHub查阅资料，创建并运行MySQL容器，要求：

① 挂载/tmp/mysql/data到mysql容器内数据存储目录

② 挂载/tmp/mysql/conf/hmy.cnf到mysql容器的配置文件

③ 设置MySQL密码

Dockerfile自定义镜像

常见的镜像在DockerHub就能找到，但是我们自己写的项目就必须自己构建镜像了。而要自定义镜像，就必须先了解镜像的结构才行。

镜像结构

镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。

我们以MySQL为例，来看看镜像的组成结构：

简单来说，镜像就是在系统函数库、运行环境基础上，添加应用程序文件、配置文件、依赖文件等组合，然后编写好启动脚本打包在一起形成的文件。

我们要构建镜像，其实就是实现上述打包的过程。

Dockerfile语法

构建自定义的镜像时，并不需要一个个文件去拷贝，打包。我们只需要告诉Docker，我们的镜像的组成，需要哪些BaseImage、需要拷贝什么文件、需要安装什么依赖、启动脚本是什么，将来Docker会帮助我们构建镜像。而描述上述信息的文件就是Dockerfile文件。

Dockerfile就是一个文本文件，其中包含一个个的指令（Instruction），用指令来说明要执行什么操作来构建镜像。每一个指令都会形成一层Layer。

更新详细语法说明，请参考官网文档： https://docs.docker.com/engine/reference/builder

构建Java项目

基于Ubuntu构建Java项目

需求：基于Ubuntu镜像构建一个新镜像，运行一个java项目

步骤1：新建一个空文件夹docker-demo

步骤2：拷贝docker-demo.jar文件到docker-demo这个目录

步骤3：拷贝jdk8.tar.gz文件到docker-demo这个目录

步骤4：拷贝Dockerfile到docker-demo这个目录，其中Dockerfile的内容如下：

步骤5：进入docker-demo

将准备好的docker-demo上传到虚拟机任意目录，然后进入docker-demo目录下

步骤6：运行命令：

最后访问http://192.168.10.100:8090/hello/count，其中的ip改成你的虚拟机ip

基于java8构建Java项目

虽然我们可以基于Ubuntu基础镜像，添加任意自己需要的安装包，构建镜像，但是却比较麻烦。所以大多数情况下，我们都可以在一些安装了部分软件的基础镜像上做改造。例如，构建java项目的镜像，可以在已经准备了JDK的基础镜像基础上构建。

需求：基于java:8-alpine镜像，将一个Java项目构建为镜像

实现思路如下：

主要是将Dockerfile改成下面的内容

使用docker build命令构建镜像：docker build -t javaweb:2.0 .

使用docker run创建容器并运行：docker run —name web2 -p 8090:8090 -d javaweb:2.0

小结

💡

小结：

Dockerfile的本质是一个文件，通过指令描述镜像的构建过程

Dockerfile的第一行必须是FROM，从一个基础镜像来构建

基础镜像可以是基本操作系统，如Ubuntu。也可以是其他人制作好的镜像，例如：java:8-alpine

Docker-Compose

Docker Compose可以基于Compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器！

初识DockerCompose

Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。格式如下：

上面的Compose文件就描述一个项目，其中包含两个容器：

mysql：一个基于mysql:5.7.25镜像构建的容器，并且挂载了两个目录

web：一个基于docker build临时构建的镜像容器，映射端口时8090

DockerCompose的详细语法参考官网：https://docs.docker.com/compose/compose-file/

其实DockerCompose文件可以看做是将多个docker run命令写到一个文件，只是语法稍有差异。

安装DockerCompose

下载

修改执行权限

查看docker-compose版本

Base自动补全命令

如果这里出现错误，需要修改自己的hosts文件：

部署微服务集群

需求：将之前学习的cloud-demo微服务集群利用DockerCompose部署

实现思路：

① 查看cloud-demo文件夹，里面已经编写好了docker-compose文件

② 修改自己的cloud-demo项目，将数据库、nacos地址都命名为docker-compose中的服务名

③ 使用maven打包工具，将项目中的每个微服务都打包为app.jar

④ 将打包好的app.jar拷贝到cloud-demo中的每一个对应的子目录中

⑤ 将 cloud-demo上传至虚拟机，利用 docker-compose up -d 来部署

compose文件

查看cloud-demo文件夹，里面已经编写好了docker-compose文件，而且每个微服务都准备了一个独立的目录：

内容如下：

可以看到，其中包含5个service服务：

nacos：作为注册中心和配置中心

image: nacos/nacos-server：基于nacos/nacos-server镜像构建
environment：环境变量

MODE: standalone：单点模式启动

ports：端口映射，这里暴露了8848端口

mysql：数据库

image: mysql:5.7.25：镜像版本是mysql:5.7.25
environment：环境变量

MYSQL_ROOT_PASSWORD: ******：设置数据库root账户的密码为******

volumes：数据卷挂载，这里挂载了mysql的data、conf目录，其中有我提前准备好的数据

userservice、orderservice、gateway：都是基于Dockerfile临时构建的

内容如下：

修改微服务配置

因为微服务将来要部署为docker容器，而容器之间互联不是通过IP地址，而是通过容器名。这里我们将order-service、user-service、gateway服务的mysql、nacos地址都修改为基于容器名的访问。如下所示：

打包

接下来需要将我们的每个微服务都打包。因为之前查看到Dockerfile中的jar包名称都是app.jar，因此我们的每个微服务都需要用这个名称。

可以通过修改pom.xml中的打包名称来实现，每个微服务都需要修改：

部署

最后，我们需要将文件整个cloud-demo文件夹上传到虚拟机中，使用DockerCompose部署。

进入cloud-demo目录，然后运行下面的命令：

Docker镜像仓库

搭建私有镜像仓库

搭建镜像仓库可以基于Docker官方提供的DockerRegistry来实现。

官网地址：https://hub.docker.com/_/registry

简化版镜像仓库

Docker官方的Docker Registry是一个基础版本的Docker镜像仓库，具备仓库管理的完整功能，但是没有图形化界面。

搭建方式比较简单，命令如下：

命令中挂载了一个数据卷registry-data到容器内的/var/lib/registry 目录，这是私有镜像库存放数据的目录。

访问http://YourIp:5000/v2/_catalog可以查看当前私有镜像服务中包含的镜像

带有图形化界面版本

使用DockerCompose部署带有图象界面的DockerRegistry，命令如下：

配置Docker信任地址

我们的私服采用的是http协议，默认不被Docker信任，所以需要做一个配置：

推送、拉取镜像

推送镜像到私有镜像服务必须先tag，步骤如下：

重新tag本地镜像，名称前缀为私有仓库的地址：192.168.10.100:8080/

推送镜像

拉取镜像

命令中挂载了一个数据卷registry-data到容器内的/var/lib/registry目录，这是私有镜像库存放数据的目录。

访问http://192.168.10.100:5000/v2/_catalog 可以查看当前私有镜像服务中包含的镜像。

如何优雅地记录操作日志？

Sat, 20 Jul 2024 00:00:00 GMT

背景 AOP+注解生成动态日志参考

背景

AOP+注解生成动态日志

参考

Spring Expression Language (SpEL)

美团技术-如何优雅地记录操作日志？

Spring Security OAuth2(1)

Thu, 25 Jul 2024 00:00:00 GMT

前言概述项目准备 Maven依赖创建资源配置资源服务器和授权服务器

前言

接口对接的场景在实际应用中很常见，A厂家有一套HTTP接口需要提供给B厂家使用，由于是外网环境，所以需要有一套安全机制保障，这个时候oauth2就可以作为一个方案。

关于oauth2，其实是一个授权规范。如果你还不清楚授权服务器，资源服务器，认证授权等基础概念，可以移步理解OAuth 2.0 - 阮一峰，这是一篇对于oauth2很好的科普文章。

需要对spring security有一定的配置使用经验，用户认证这一块，spring security oauth2建立在spring security的基础之上。java中的安全框架如shrio，已经有跟我学shiro - 开涛，非常成体系地，深入浅出地讲解了apache的这个开源安全框架。

概述

使用oauth2可以分为简易的分为三个步骤：

配置资源服务器

配置认证服务器

配置spring security

前两点是oauth2的主体内容，但前面我已经描述过了，spring security oauth2是建立在spring security基础之上的，所以有一些体系是公用的。

oauth2根据使用场景不同，分成了4种模式：

授权码模式（authorization code）

简化模式（implicit）

密码模式（resource owner password credentials）

客户端模式（client credentials）

本文重点讲解接口对接中常使用的密码模式（以下简称password模式）和客户端模式（以下简称client模式）。授权码模式使用到了回调地址，是最为复杂的方式，通常网站中经常出现的微博，qq第三方登录，都会采用这个形式。简化模式不常用。

项目准备

Maven依赖

创建资源

暴露一个商品查询接口（后续不做安全限制）和一个订单查询接口（后续添加访问控制）

配置资源服务器和授权服务器

从Seq2Seq到Attention

Mon, 20 Jan 2025 00:00:00 GMT

从 Seq2Seq 到 Attention 前言什么是 Seq2Seq 模型？基于 RNN 的 Seq2Seq 模型如何处理文本/长文本序列？Seq2Seq 模型处理长文本序列时遇到了什么问题？有什么优缺点？基于 RNN 的 Seq2Seq 模型如何结合 Attention 来改善模型效果？参考文献

从 Seq2Seq 到 Attention

前言

自然语言处理（NLP）或是大语言模型（LLM）的底层原理是 Attention（注意力机制），它不仅是如今如日中天的 Transformer 架构的灵魂核心，更是开启这轮 AI 狂飙时代的超级引擎。

其实，技术的演进从来都不是凭空捏造的。要想真正吃透 Attention，必须先回到大模型爆发的“前夜”，去看看上一代霸主——传统 Seq2Seq 模型到底遇到了什么无法跨越的“致命瓶颈”。

什么是 Seq2Seq 模型？

Seq2Seq 是一种常见的 NLP 模型结构，全称是：sequence to sequence，翻译为“序列到序列”。顾名思义：从一个文本序列得到一个新的文本序列。这类任务的特点是：输入序列和输出序列的长度通常是不对等的。

Seq2Seq 模型架构由编码器（Encoder）和解码器（Decoder）两部分组成：

编码器（Encoder）：负责把输入的文本序列（比如“我爱机器学习”）一个个读进去，通过循环神经网络（RNN）不断更新隐状态（hidden state），最终将整句话的语义压缩成一个固定长度的向量。这个向量我们称之为上下文向量（Context Vector）。

解码器（Decoder）：拿到这个 context 向量后，像挤牙膏一样，一步步把目标文本（比如 “I love machine learning”）吐出来。

典型的任务有：机器翻译任务，文本摘要任务。

💡

Seq2Seq 模型中的 Encoder和 Decoder 一般采用的是循环神经网络 RNN（Transformer 模型还没出现的过去时代）。

context 的数组长度是基于 Encoder RNN 的隐藏层神经元数量的，在实际应用中，context 向量的长度是自定义的，比如可能是 256，512 或者 1024。

基于 RNN 的 Seq2Seq 模型如何处理文本/长文本序列？

可以参考 jalammar 制作的动画对 Seq2Seq 处理文本/长文本序列有一个清晰的认识。

我们用数学语言来更精确地还原这个过程。以机器翻译为例，假设序列输入是一个句子，这个句子由个单词组成：

词向量映射：首先，RNN 将句子中的每一个单词通过一个嵌入层（Word Embedding）映射成为一个向量得到一个向量序列：。

编码器隐状态更新：在时间步， Encoder RNN 的内部计算公式为：

这里，是上一个时间步的隐状态，它像一个滚雪球一样，携带了从到的全部历史信息。是 RNN 在时间步的输入单词经过映射得到的向量。

传递 context 向量：当 Encoder 读完最后一个词时，它输出的最后一个隐状态就成为了代表整句话语义的 context 向量：

解码器生成序列：Decoder 接收到 context 后，将其作为初始隐状态，然后开始逐字预测：

其中是解码器上一步输出的单词，是解码器当前的隐状态。

Seq2Seq 模型处理长文本序列时遇到了什么问题？有什么优缺点？

经典 Seq2Seq 看似完美，但在工程实践中却遇到了极大的挑战。它的致命缺点可以总结为一句话：成也 context，败也 context。

打个比方：这就好比让你去读一本 500 页的长篇小说（输入长文本），读完之后不准你翻书，只允许你在脑子里提取出 100 个字的故事大纲（固定长度的 context 向量）。然后，让你根据这 100 字的大纲，把整本书一字不漏地翻译成英文（解码器输出）。

这显然是不可能的任务！

在实际应用中，这种架构存在两个无法调和的矛盾：

基于 RNN 的 Seq2Seq 模型中 Encoder 把所有信息都编码到了一个context向量中，便是这类模型的瓶颈。

信息量与表达能力的矛盾：单只固定维度的向量（比如维度是 512），其所能容纳的信息熵是极其有限的，很难包含所有文本序列的信息。强行将一段成百上千字的文本压缩进如此小的空间，必然会导致严重的信息丢失。

梯度消失与记忆遗忘：由于 RNN 是串行递归计算的，即使使用了 LSTM 或 GRU，在处理到第 500 个单词时，很难再包含1-499个单词中的所有信息了。这就是经典的长距离依赖问题（Long-range Dependency）。

为了打破这个窒息的信息瓶颈，2014 年， Dzmitry Bahdanau 等人提出了一项开创性的技术——注意力机制（ Attention Mechanism）。

基于 RNN 的 Seq2Seq 模型如何结合 Attention 来改善模型效果？

既然问题出在“试图用一个固定向量代表整句话”上，那我们索性不再强行压缩！

Attention 的核心思想非常朴素：

Encoder 在处理输入时，把所有时间步的隐状态全部保留并发送给 Decoder ，而不仅仅是最后一个隐状态。

当 Decoder 在产生第个输出单词时，它会动态地去计算当前输出状态与输入端所有隐状态的关联度（即注意力分配分数）。

接着，根据这些分数对所有隐状态进行加权求和，融合成一个专属于当前时间步的动态 context 向量。

Attention 机制与经典的 Seq2Seq 模型主要有两点不同：

首先，编码器会把更多的数据传递给解码器。编码器把所有时间步的 hidden state（隐藏层状态）传递给解码器，而不是只传递最后一个 hidden state（隐藏层状态）

注意力模型的解码器在产生输出之前，做了一个额外的 Attention 处理：

💡

今天我们不关注 Attention 内部实现的细节，只是简单了解大致的作用，以及其与 Seq2Seq 的区别。

由于编码器中每个 hidden state（隐藏层状态）都对应到输入句子中一个单词，那么解码器要查看所有接收到的编码器的 hidden state（隐藏层状态）。

给每个 hidden state（隐藏层状态）计算出一个分数（我们先忽略这个分数的计算过程）。

所有 hidden state（隐藏层状态）的分数经过softmax进行归一化。

将每个 hidden state（隐藏层状态）乘以所对应的分数，从而能够让高分对应的 hidden state（隐藏层状态）会被放大，而低分对应的 hidden state（隐藏层状态）会被缩小。

将所有hidden state根据对应分数进行加权求和，得到对应时间步的context向量。

💡

所以，Attention 可以简单理解为：一种有效的加权求和技术，其艺术在于如何获得权重。需要注意的是：注意力模型不是无意识地把输出的第一个单词对应到输入的第一个单词，它是在训练阶段学习到如何对两种语言的单词进行对应。

参考文献

[1] Visualizing A Neural Machine Translation Model (Mechanics of Seq2Seq Models With Attention) [2] Attention Is All You Need

Spring Security(3)：如何设计PasswordEncoder？

Thu, 25 Jul 2024 00:00:00 GMT

密码存储演进史慢 hash 算法真的安全吗？spring security 废弃的接口更深层的思考

密码存储演进史

自从互联网有了用户的那一刻起，存储用户密码这件事便成为了一个健全的系统不得不面对的一件事。远古时期，明文存储密码可能还不被认为是一个很大的系统缺陷（事实上这是一件很恐怖的事）。提及明文存储密码，我立刻联想到的是 CSDN 社区在 2011 年末发生的 600 万用户密码泄露的事件，谁也不会想到这个和程序员密切相关的网站会犯如此低级的错误。明文存储密码使得恶意用户可以通过 sql 注入等攻击方式来获取用户名和密码，虽然安全框架和良好的编码规范可以规避很多类似的攻击，但依旧避免不了系统管理员，DBA 有途径获取用户密码这一事实。事实上，不用明文存储存储密码，程序员们早在 n 多年前就已经达成了共识。

不能明文存储，一些 hash 算法便被广泛用做密码的编码器，对密码进行单向 hash 处理后存储数据库，当用户登录时，计算用户输入的密码的 hash 值，将两者进行比对。单向 hash 算法，顾名思义，它无法（或者用不能轻易更为合适）被反向解析还原出原密码。这杜绝了管理员直接获取密码的途径，可仅仅依赖于普通的 hash 算法（如 md5，sha256）是不合适的，他主要有 3 个特点：

同一密码生成的 hash 值一定相同

不同密码的生成的 hash 值可能相同（md5 的碰撞问题相比 sha256 还要严重）

计算速度快。

以上三点结合在一起，破解此类算法成了不是那么困难的一件事，尤其是第三点，会在下文中再次提到，多快才算非常快？按照相关资料的说法：

modern hardware perform billions of hash calculations a second.

考虑到大多数用户使用的密码多为数字+字母+特殊符号的组合，攻击者将常用的密码进行枚举，甚至通过排列组合来暴力破解，这被称为 rainbow table。算法爱好者能够立刻看懂到上述的方案，这被亲切地称之为—打表，一种暴力美学，这张表是可以被复用的。

虽然仅仅依赖于传统 hash 算法的思路被否决了，但这种 hash 后比对的思路，几乎被后续所有的优化方案继承。

hash 方案迎来的第一个改造是对引入一个“随机的因子”来掺杂进明文中进行 hash 计算，这样的随机因子通常被称之为盐（salt）。salt 一般是用户相关的，每个用户持有各自的 salt。此时张三和李四的密码即使相同，由于 salt 的影响，存储在数据库中的密码也是不同的，除非…为每个用户单独建议一张 rainbow table。很明显 salted hash 相比普通的单向 hash 方案加大了 hacker 攻击的难度。但了解过 GPU 并行计算能力之强大的童鞋，都能够意识到，虽然破解 salted hash 比较麻烦，却并非不可行，安全专家似乎也对这个方案不够满意。

为解决上述 salted hash 仍然存在的问题，一些新型的单向 hash 算法被研究了出来。其中就包括：Bcrypt，PBKDF2，Scrypt，Argon2。为什么这些 hash 算法能保证密码存储的安全性？因为他们足够慢，恰到好处的慢。这么说不严谨，只是为了给大家留个深刻的映像：慢。这类算法有一个特点，存在一个影响因子，可以用来控制计算强度，这直接决定了破解密码所需要的资源和时间，直观的体会可以见下图，在一年内破解如下算法所需要的硬件资源花费（折算成美元）

这使得破解成了一件极其困难的事，并且，其中的计算强度因子【可以理解为加密复杂度，例如可以使用private Integer passwordEncoderLength = 4，数值越大，计算开销越大】是可控的，这样，即使未来量子计算机的计算能力爆表，也可以通过其控制计算强度以防破解。注意，普通的验证过程只需要计算一次 hash 计算，使用此类 hash 算法并不会影响到用户体验。

慢 hash 算法真的安全吗？

Bcrypt，Scrypt，PBKDF2 这些慢 hash 算法是目前最为推崇的 password encoding 方式，好奇心驱使我思考了这样一个问题：慢 hash 算法真的安全吗？

我暂时还没有精力仔细去研究他们中每一个算法的具体实现，只能通过一些文章来拾人牙慧，简单看看这几个算法的原理和安全性。

PBKDF2 被设计的很简单，它的基本原理是通过一个伪随机函数（例如 HMAC 函数），把明文和一个盐值作为输入参数，然后按照设置的计算强度因子重复进行运算，并最终产生密钥。这样的重复 hash 已经被认为足够安全，但也有人提出了不同意见，此类算法对于传统的 CPU 来说的确是足够安全，但 GPU 被搬了出来，前文提到过 GPU 的并行计算能力非常强大。

Bcrypt 强大的一点在于，其不仅仅是 CPU 密集型，还是 RAM 密集型！双重的限制因素，导致 GPU，ASIC（专用集成电路）无法应对 Bcrypt 带来的破解困境。

然后…看了 Scrypt 的相关资料之后我才意识到这个坑有多深。一个熟悉又陌生的词出现在了我面前：FPGA（现场可编程逻辑门阵列），这货就比较厉害了。现成的芯片指令结构如传统的 CPU，GPU，ASIC 都无法破解 Bcrypt，但是 FPGA 支持烧录逻辑门（如AND、OR、XOR、NOT），通过编程的方式烧录指令集的这一特性使得可以定制硬件来破解 Bcrypt。尽管我不认为懂这个技术的人会去想办法破解真正的系统，但，只要这是一个可能性，就总有方法会被发明出来与之对抗。Scrypt 比 Bcrypt 额外考虑到的就是大规模的自定义硬件攻击，从而刻意设计需要大量内存运算。

理论终归是理论，实际上 Bcrypt 算法被发明至今 18 年，使用范围广，且从未因为安全问题而被修改，其有限性是已经被验证过的，相比之下 Scrypt 据我看到的文章显示是 9 年的历史，没有 Bcrypt 使用的广泛。从破解成本和权威性的角度来看，Bcrypt 用作密码编码器是不错的选择。

spring security 废弃的接口

spring security 5 对 PasswordEncoder 做了相关的重构，原先默认配置的 PlainTextPasswordEncoder（明文密码）被移除了，想要做到明文存储密码，只能使用一个过期的类来过渡。

实际上，spring security 提供了 BCryptPasswordEncoder 来进行密码编码，并作为了相关配置的默认配置，只不过没有暴露为全局的 Bean。使用明文存储的风险在文章一开始就已经强调过，NoOpPasswordEncoder 只能存在于 demo 中。

更深层的思考

不知道有没有读者产生跟我相同的困扰：

如果我要设计一个 QPS 很高的登录系统，使用 spring security 推荐的 BCrypt 会不会存在性能问题？

spring security 怎么这么坑，原来的密码编码器都给改了，我需要怎么迁移旧密码编码的应用程序？

万一以后出了更高效的加密算法，这种笨重的硬编码方式配置密码编码器是不是不够灵活？

在 spring security 5 提供了这样一个思路，应该将密码编码之后的 hash 值和加密方式一起存储，并提供了一个 DelegatingPasswordEncoder 来作为众多密码编码方式的集合。

负责生产 DelegatingPasswordEncoder的工厂方法：

如此注入 PasswordEncoder 之后，我们在数据库中需要这么存储数据：

你会不会担心密码泄露后，{bcrypt}，{pbkdf2}，{scrypt}，{sha256} 此类前缀会直接暴露密码的编码方式？其实这个考虑是多余的，因为密码存储的依赖算法并不是一个秘密。大多数能搞到你密码的 hacker 都可以轻松的知道你用的是什么算法，例如，bcrypt 算法通常以 $2a$ 开头

稍微思考下，前面的三个疑问就可以迎刃而解，这就是文档中所谓的：能够自适应服务器性能的现代化密码编码方案。