容器化技术的出现标准化了服务的基础设施，统一了应用的打包分发、部署及操作系统相关类库等，解决了测试及生产部署时环境差异的问题，更方便分析排查问题。对运维来说，由于镜像的不可变性，更容易进行服务部署升级及回滚。另外利用诸如 Kubemetes 之类的容器管理平台，更容易实现一Kaiyun官方网站.h30e.com target=_blank>Kaiyun官方网站键部署、扩容、缩容等操作，更能将微服务架构、DevOps、不可变基础设施的思想落地下来。本文重点讲述 Spring Cloud 如何使用 Docker 实现容器化。

　　操作系统层面，可以选择传统的 Centos、Ubuntu 或者轻量级的 Alpine。其中 Ubuntu 16.04 版本的镜像大小约为 113M，压缩后大约 43M；Centos 7 版本的镜像大小约为 199M，压缩后大约为 73M；而 Alpine 3.7 版本镜像大小约为 4.15M，压缩后约为 2M。关于基础镜像的选择，一个是考虑镜像大小，一个是只提供最小的依赖包。关于第二点，不同的服务应用依赖包是不同的，这里不再展开，只从镜像大小角度考虑的话，Alpine 是首选，镜像小，远程推拉镜像的速度快，更为方便，这里建议釆用 Alpine 镜像作为基础镜像。从 Docker 镜像分层缓存的机制来考虑，如果选择了比较大的基础镜像，DockerFile 编写时可以适当分层，然后集中在几台镜像打包机上处理镜像打包及上传，这样可以充分利用打包机镜像分层缓存的机制，减少上传镜像的耗时。但是对于分布式服务的 Docker 部署，目标服务实例部署的机器比较多而且是随机的，就没办法利用这个机制来加快镜像下载速度。

　　选择 Alpine 有个麻烦的地方就是 Alpine 采用的是 musl libc 的 C 标准库，而 Oracle JDK 或 OpenJDK 提供的版本则主要是以 glibc 为主，虽然 OpenJDK 在一些早期版本会放出使用 musl libc 编译好的版本，不过在正式发布的时候，并没有单独的 musl libc 编译版本可以下载，需要自己单独编译，稍微有些不便。因此可以考虑在 Alpine 里加上 glibc，然后添加 glibc 的 JDK 编译版本作为基础镜像。

　　阿里云上有已构建好的不同版本的 JDK 镜像，拉取到本地就可以直接使用：

　　# 第一种方式：不使用身份认证或者使用POM配置里的私有仓库账号进行Push

　　执行以下命令运行镜像，实际项目中可以根据项目需要调整对应的 JVM 参数：

　　JDK9 及以上的版本与之前的版本有一个比较大的变动，就是 JDK9 及以上的版本支持模块系统 JPMS，同时 JDK 自身也模块化了，里面的 Modular Run-Time Images 功能特性以及 jlink 工具对于镜像的优化非常有帮助，可根据所需模块来精简 JDK。

　　Jlink 工具可以用来将已有的 JDK 按所需模块进行优化，并重新组装成一个自定义的 runtime image，其基本语法如下：

　　创建对应 Dockerfile，配置内容如下，其中指定了需要依赖的 JDK 模块，目的是通过 Jlink 生成精简的 JDK，点击下载完整的示例代码。

　　查看镜像的大小，可以发现精简后的 JDK 包括 app.jar，总大小在 100M 以内：