容器相比虚拟机最大的特点之一就是轻量和快捷。但目前制约容器快速启动的点就是容器镜像。正可谓成也萧何败也萧何。

容器的启动依赖镜像，关于镜像 OCI 格式之前的文章已经分析。OCI 分层的方式虽然提高层的复用，但严格的分层结构还是会导致文件的重复存储，一个G的文件，可能只是修改一行，就需要将整个文件拷贝到上层修改。

虽然容器的镜像相比虚拟机已经很小了，但即便几百M的镜像，在大规模场景中还是存在下载的瓶颈。个人把镜像分发的演进分为三个阶段。

1、多仓库方案

这个阶段就是部署多个镜像仓库，为了避免单个仓库的压力，最简单有效的方案就是部署多个仓库分担负载。

这种方案需要修改主机的域名解析，从而分配到不同的镜像仓库。多个镜像仓库之间会复制镜像。

2、P2P方案

上一篇文章分享了drangfly。drangfly便是一个p2p 方案，就像迅雷下载一样，为了避免中心节点的压力，采用p2p的方案，让每个节点都可以成为服务节点，提供下载能力。只需要通过一个中心调度节点supernode，分配种子的位置即可。

3、延迟加载

上面的方案还是延续OCI 的个数，这里介绍一种新的镜像加速方案：延迟加载。延迟加载的原理是：大部分容器启动的时候，并不需要镜像里面的所有文件，而是只需要加载少量的文件的文件就可以启动服务了。后续依赖的其他数据延迟加载就可以了。而传统的OCI 格式，必须等到整个镜像都下载完成，才能启动容器。

这里比较流行的是stargz和nydus，下图是nydus原理

通过 fuse 文件系统，当读取数据的时候，如果发现文件不存在，会通过后端的OSS 加载数据。其实延迟加载的路径可以通过文件系统，甚至可以通过块存储，从数据块层面提供延迟加载的能力。

上面的延迟加载也可以和p2p 结合使用，通过p2p 解决大规模情况下的延迟加载。

但无论如何，上面的方案都存在一定的延迟，如果对速度有极致追求的，可以将镜像做出一个快照，当我们启动容器的时候，通过快照生成一个数据盘，然后直接把这个盘挂载到主机上面，启动容器，延迟最小，无论是十几个G 还上百G 的镜像都可以在毫秒级别完成镜像下载。