SpringBoot-2.3镜像方案为什么要做多个layer
内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；
背景
《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中，我们体验了官方推荐的镜像制作方案，执行docker history命令观察镜像内部，发现是由多个layer组成的，如下图：
问题来了：搞这么多layer干啥？接下来以图文方式，您一起理解docker镜像layer对java开发者的的作用；
声明
本文的目标是通过图文帮助java开发者理解docker镜像的layer作用，内容和实际情况并未完全保持一致，例如基础镜像的layer没有提到，而且java镜像的layer可能不止业务镜像、配置文件、依赖库这三层；
常见角色
使用docker时，有三个常见角色：
镜像制作者：本文中就是SpringBoot应用开发者，写完代码把应用做成docker镜像；
docker公共镜像仓库：镜像制作者将镜像推送到仓库给大家使用；
镜像使用者：从镜像仓库将镜像下载到本地使用；
接下来的故事围绕上述三个角色展开；
从制作到使用的过程
如下图，SpringBoot应用开发者，写完代码把应用做成docker镜像，该镜像的TAG是1.0，此时开发者将镜像推送到公共仓库时，一共要推送三个layer：
接下来，使用者要下载镜像，就从镜像仓库下载三个layer：
此时，三个角色拥有的内容都是一样，都是三个layer：
这时候SpringBoot开发者修改了业务代码，于是做了个新的镜像（TAG是2.0），然后推送到镜像仓库；
重点来了：因为只改了业务代码，因此只有业务class的layer是新的，只有这个layer会被推送到仓库，如下图：
对镜像使用者来说，如果之前下载过1.0的镜像，此时要用2.0镜像的话，只要从仓库下载最新的业务class的layer即可：
最终结果如下，公共仓库和镜像使用者都已最小的代价得到了2.0镜像：
可见，使用多个layer的镜像，在镜像的分发过程中，相比单一layer的镜像会更加高效，尤其是使用hub.docker.com这样的外网公有仓库，以及频繁发布新版的场景下；