为了获得更高效率的云服务，容器技术自诞生以来便受到了业界的广泛支持。通过优秀的隔离技术，容器可以借由挂载不同的运行时从而对不同的应用提供支持。但在实际应用中，随着不同模板数量的增多，容器环境下的镜像分发逐渐成为了一个令云服务管理者头疼的问题。而更加头疼的是，目前业界还没有形成完整统一的镜像分发标准;各个容器的使用者只能自行解决这一难题。
在日前举办的由51CTO主办的WOT全球软件与运维技术峰会上，各方技术大咖齐聚一堂，在开源与容器技术分论坛中各抒己见，探讨了与容器相关的各种技术应用与实践。而在这些讨论中，资深容器技术专家肖德时便就容器环境下的分布式镜像仓库技术阐述了自己的观点。
Docker在镜像分发上留下的空白
在此次WOT峰会的开源与容器技术分论坛中，肖德时表示：虽然目前创建和启动容器的标准工具以及容器的运行时和镜像标准都已经颁布，但OCI仍旧没有发布针对容器环境下的镜像分发标准。而我们所能知道的就是容器镜像分发标准的1.0版本将围绕Docker Registry HTTP API V2来展开。
目前能够确定下来的容器镜像分发标准包括：
Namespace-oriented URI Layout
PUSH/PULL registry server for V2 image manifest format
Resumable layer PUSH support
V2 Client library implementation
而包括不可变镜像参考、多架构支持、V2版兼容性下的迁移等标准在内的众多重要标准则仍旧在讨论中，没有形成共识。
从目前的实际使用情况来看，肖德时表示：官方发布的Docker registry所缺少的特性还很多，企业还无法进行实际的商用部署。针对这一领域，Docker有自己的Docker Hub服务来解决容器的打包、存储和分发问题。但这一服务访问起来很慢，而且他是一个闭源的服务，外界无法知道他是如何实现的。此外，Docker还发布了DTR工具;但这一工具是基于单机环境而设计，本质上无法实现HA扩展，因此也无法满足企业的高可用需求。
Docker发布的registry 2.0虽然是目前用户***可用的开源版本，但从架构上来看，这个工具并不适合一般的企业来用。首先，他本身并没有对应的授权机制，这一点就需要外部的组件来控制;其次，他的访问控制是放在工具内部的，但真正的企业在这方面确实需要其他系统来统一控制的;第三，registry 2.0架构内部缺乏可用的handlers，这使得企业还需要编写额外的组件来实现相应的监控功能;第四，也是最重要的，在存储结构方面，registry 2.0仍然是基于单机来设计的，企业需要具备很高的技术实力才能在这一基础上构建完整的高可用特性。而以上这些正是registry 2.0在商用中所遇到的主要问题。
业界实践
面对这些痛点，一种业界大厂都开始了在镜像分发方面的探索和实践：
腾讯在这方面开发了FID系统：A Faster Image Distribution System for Docker，效果比原生的分发功能好很多，向200个节点分发500M镜像文件的速度是Docker原生的10倍;部署起来也比较方便。
阿里发布了蜻蜓系统，这是一套基于P2P的文件分发系统，吞吐量是原生应用的57倍，带宽占用仅为原来的不到1%。
VMware则面向市场发布了自己的Harbor系统来解决镜像分发问题，同时，他也将registry 2.0本身所固有的一些问题进行了完善。
IBM也在展开相关方面的研究，并发布了Wharf架构。
容器镜像分发，任重道远
在分析了众多业界在容器镜像分发领域的实践之后肖德时表示：目前各家研究的方向和实际的效果来看，P2P技术的确可以有效提高镜像分发的效率，而且文件体积越大、效率就越高。
另外，共享层模式将可以有效降低容器镜像存储的冗余度。
而在最重要的高可用方面，目前的所有解决方案和研究成果也还都需要更多的实践来验证。
经历多年发展，容器技术已经取得了良好的应用效果，并获得了商业用户的广泛认同。但我们也不得不承认，包括容器镜像的打包、存储和分发等领域，目前的容器技术仍显得相当稚嫩。而这些领域也是未来IT厂商和云服务提供商将会重点攻克的领域。
在经历了物理机、虚拟机、云服务等一系列进化之后，容器化必将成为未来的主流发展趋势。而容器技术本身的发展更会因为业界的广泛参与和研究而变得越来越快、越来越好。
