双 11 · 一场技术的决战

课程介绍

每年双11是国内各大电商贴身肉搏，激烈交锋的时刻，同时也是把几十天的交易量浓缩到一天释放的日子。为了准备双11的大促，各家都会在营销、促销、技术保障、物流、售后、客服等各个环节付出相当大的努力。当然，这也是一次互联网技术团队的大检阅。

• 阿里是如何支撑 17.5万笔/秒的下单峰值的？
• 数万台服务器是如何在十分钟内快速部署的？
• 3000万用户使用的“拍立淘”是怎么做图像搜索与识别的？
• 7秒交易过亿的苏宁易购如何保证库存系统的稳定？
• 以闪购为卖点的唯品会是如何应对线上压测的？

本期我们将带您一睹各家团队在这场技术决战中的“制胜法宝”。

本书内容

阿里篇 · 弹性扩容背后的技术

容器镜像之于容器技术

作为一种轻量级的虚拟化技术，容器技术所具备的敏捷、可移植、可控性，使得它一经推出就受到众多开发者的追捧。但其实更重要的是，容器技术定义了一种标准化的交付方式——容器镜像。

容器镜像将应用的代码以及代码环境依赖都都打包在一起，这是一个与环境无关的交付物，可以应用在软件生命周期的任何阶段。就像集装箱改变了传统的运输体系，创造了容器镜像的容器技术彻底改变了传统的软件交付模式。

纵观全球，整个容器技术在近三年得到了爆发式的增长。据统计有67%的企业在生产环节或者尝试在生产环节中使用 Docker，帮助他们敏捷进化，提高研发交付的效率。据 Docker Con 2017的统计，近三年应用数增长了30倍，约有百万级别的容器化应用数。而容器镜像的拉取个数，近三年更是趋于了指数级别增长，承载了约110亿次拉取。

图1 Docker Con2017 年容器镜像拉取情况的最新统计

双十一与容器镜像服务的故事

早在2015年，阿里巴巴就在尝试使用容器技术。2016年双十一就已经将所有交易核心应用容器化，几十万容器撑起了双11交易17.5万笔/秒的下单峰值。而在今年，阿里巴巴已在集团范围实现在线服务全部容器化，内部已达到百万级容器部署规模，其中双11交易峰值到32.5万笔/秒并且可以实现十分钟内万台服务器的快速部署。

截止目前，容器镜像服务支撑了集团10万镜像的托管，共计2亿次的镜像下载量。

为了承受高压，我们做了多维度的优化

在早期的容器推行演练中，由于当时发布系统日均的发布量上万，很多应用的规模开始破万，发布失败率开始增高，影响到了业务的正常迭代流程。这个困境的根本问题在于发布过程大量大应用镜像拉取的需求，而应用镜像内容过于冗余臃肿，彼时存在大量超过5G的大镜像，文件服务器扛不住大量的请求。

为了解决多规模、并发情况下容器镜像的获取问题，我们考虑了容器镜像大小、容器内容加速及流控、镜像 Registry 性能等三个大维度的优化。

容器镜像大小优化

Action1：之前将所有的构建过程编写在同一个 Dockerfile 中，包括应用及其依赖库的编译、测试、打包等流程，这里可能会带来的一些问题：镜像臃肿、镜像层次嵌套深、也可能存在源代码泄露的风险。我们进行了多阶段镜像构建优化，将镜像制作过程中的中间产物与最终镜像构建产物分离，形成最精简的应用镜像。

图2 多阶段镜像构建优化后获取最精简应用镜像

Action2：将功能统一的命令聚合到同一层来完成，将使用频繁的应用或环境制作成基础镜像复用，尽可能减少镜像的层数。关于容器镜像优化的最佳实践，我们也开展了很多的线下沙龙活动进行分享，可以通过《Docker 镜像优化与最佳实践》了解更多。

容器内容加速和流控

在大规模的镜像分发场景之下，优化镜像本身的大小作用有限，我们依然需要考虑如何从系统上提升镜像拉取的性能。最初很容易想到服务器扩容，可是扩容后又发现后端存储成为瓶颈。此外，大量来自不同 IDC 的客户端请求消耗了巨大的网络带宽，造成网络拥堵。同时，很多业务走向国际化，大量的应用部署在海外，海外服务器下载要回源国内，浪费了大量的国际带宽，而且还很慢；如果传输大文件，网络环境差，失败的话又得重来一遍，效率极低。

为了解决这些问题，阿里推出了蜻蜓这个产品。蜻蜓通过使用 P2P 技术同时结合智能压缩、智能流控等多种创新技术，解决大规模文件下载以及跨网络隔离等场景下各种文件分发难题，大幅提高数据预热、大规模容器镜像分发等业务能力。

在本地机器使用了分层的方式来下载镜像，下面介绍下 Docker Pull 的执行过程：Docker Daemon 调用 Registry API 得到镜像的 Manifest，从 Manifest 中能算出每层的 URL，Daemon 随后把所有镜像层从 Registry 并行下载到 Host 本地仓库。

所以最终，镜像传输的问题变成了各镜像层文件的并行下载的问题。而蜻蜓擅长的正是将每层镜像文件从 Registry 用 P2P 模式传输到本地仓库中。那么具体又是如何做到的呢?

图3 Docker 镜像分层下载图

事实上蜻蜓会在 Host 上启动 proxy，Docker Engine 的所有命令请求都会通过这个 proxy，我们看一下图4。

图4 蜻蜓 P2P 容器镜像分发示意图

首先，docker pull 命令，会被 dfget proxy 截获。然后，由 dfget proxy 向 CM 发送调度请求，CM 在收到请求后会检查对应的下载文件是否已经被缓存到本地，如果没有被缓存，则会从 Registry 中下载对应的文件，并生成种子分块数据（种子分块数据一旦生成就可以立即被使用）；如果已经被缓存，则直接生成分块任务，请求者解析相应的分块任务，并从其他 peer 或者 supernode 中下载分块数据，当某个 Layer 的所有分块下载完成后，一个 Layer 也就下载完毕了，同样，当所有的 Layer 下载完成后，整个镜像也就下载完成了。

蜻蜓支持多种容器技术，对容器本身无需做任何改造，镜像分发比 natvie 方式提速可高达57倍，Registry 网络出流量降低99.5%以上。为阿里巴巴业务的极速扩张和双十一大促保驾护航。

镜像 Registry 性能优化

蜻蜓利用 P2P 的模式解决了从 Registry 获取镜像层并传输到本地的问题，不过当镜像拉取规模在几万并发的量级的时候，从 Registry 获取镜像的 Manifest 也会成为性能瓶颈。容器镜像服务从代码层面、基础设施层面做了很多定制化的增强。

在代码层面：容器镜像服务增加了对于 Docker Registry 优化，根据之前的镜像请求，自动分析热点数据并增加了热点数据的缓存，从容应对大规模并发下镜像 Manifest 的拉取。增加了对镜像下载源的动态判断，根据镜像下载请求的不同来源，自动返回离镜像下载最近的 Registry 地址。

在基础设施层面：为了应对流量的突发，容器镜像服务加强了针对 Registry 流量、存储的多维度监控，定时进行监控探活，并且实时收集监控数据，当达到监控阈值，Registry 会自动进行报警和基础设施的弹性扩容。

镜像服务惠及云上用户

自2015年起面向阿里集团内部和对阿里云容器服务提供支撑以来，阿里云容器镜像技术积累了深厚的经验。一般而言，大家认为容器镜像服务是为用户提供了安全稳定的镜像托管能力，但是实际上并不至于此：除了镜像托管以及镜像的上传下载之外，容器镜像服务还包含了从镜像构建到应用部署等一整套的 DevOps 能力。

为了将阿里巴巴在容器技术上的积累带给云上用户，容器镜像服务（ContainerRegistry）于2017年10月30日正式对外公测。容器镜像服务免费提供了安全的镜像托管能力，稳定的国内外镜像构建服务，便捷的镜像授权功能，便捷化容器镜像全生命周期管理。

具体而言镜像服务具备的独特优势：基于全球多地域支持，可以就近托管容器镜像，保障应用镜像的极速上传、下载操作；在镜像构建方面上则做到了自动构建、海外构建、多阶段构建（multi-stagebuild）支持，还可以通过 webhook 动态通知容器服务集群进行应用的重新部署；此外，由于安全是重中之重，还加入了镜像安全扫描功能和多维度的镜像漏洞报告。

总结

容器镜像服务通过 Registry 性能优化，蜻蜓通过 P2P 技术结合智能压缩和流控等方案，共同解决了大规模文件下载以及跨网络隔离等场景下各种文件分发难题，在阿里已然成为重要的基础设施之一，为业务的极速扩张和双十一大促保驾护航。

阿里云容器服务团队
成立于2015年，于2016年公有云容器服务正式商业化、专有云企业版正式发布、产品实现国际化，于今年发布专有云敏捷版，全面升级提供 Kubernetes 和 Swarm 的支持。

阿里篇 · 拍立淘中的图像搜索和识别

苏宁篇 · 库存架构转变

唯品篇 · 双 11 大促技术保障实践

奖励篇 · 微博运维的功守道

阅读全文: http://gitbook.cn/gitchat/geekbook/5a3c787a902f0f2223e252cf