第四章 电商云化，4.2 集团AliDocker化双11总结(做者： 林轩、白慕、潇谦)

4.2 集团AliDocker化双11总结

前言

在基础设施方面，今年双11最大的变化是支撑双11的全部交易核心应用都跑在了Docker容器中。几十万Docker容器撑起了双11交易17.5万笔每秒的下单峰值。众所周知Docker技术这几年大热，但若是指望阿里这么大致量的应用所有使用Docker，这可不是一朝一夕就能完成的事情。阿里的应用数量庞大，种类众多，光兼容性的验证没个一、2年的时间没人敢把核心应用放上去。所以虽然Docker能给研发和运维带来的好处，做为技术人员你们都心照不宣，可是想直接去使用，那面对Docker浪潮却只能是坐观弄潮者，徒有羡鱼情。

 

1. T4和Docker的融合

所幸的是，这个情况在去年7月份有了改变，这事要从阿里内部的容器技术产品T4提及。T4是阿里在2011年的时候基于Linux Container(LXC)开发的容器技术基础设施。从12年到15年3年时间里用的应用愈来愈多，实际上已经覆盖了电商领域大部分App。相比Docker的模式和理念，T4其实更适合阿里内部的运维现状。T4是从阿里内部的资源管理和平常运维中土生土长出来的产品，在诞生的第一天就针对内部基础设施、运维工具甚至是运维习惯作了不少特别的设计。T4在LXC容器的基础上，对容器资源和各类统计的可见性作了不少卓有成效的隔离，使得在容器内部看到的资源就是分配给这个容器的资源，内部看到的负载就是这个容器的负载等等。同时在LXC以外还作了容器的磁盘空间配额限制和隔离，容器内看到的那块磁盘大小就是建立容器时分配给他的磁盘配额大小。这样在CPU、网络、内存、磁盘等资源使用和统计监控上作到了容器内和物理机上基本没有区别。原来跑在物理机，或者KVM、Xen中的应用，可以平滑无感知的迁移到T4中。当年从Xen、Kvm迁移到T4的过程当中，不少应用的开发者和Owner确实不知道何时完成迁移的，可能在某次常规的应用发布中，后台工具系统已经自动作完迁移了。甚至直到去年在和一个应用研发的沟通中，他坚信本身的应用是跑在KVM中的，咱们到后台查了一下，其实已经在T4上了。

咱们在去年5月份接手了T4的整个维护工做，发现T4的功能和Docker很是类似，可是T4和Docker相比有一块很大的短板就是没有镜像机制，再加上T4这种对人工运维的友好性，在长期使用中就出现了一个问题，就是应用的容器里面遗留了愈来愈多的不一致，对运维的标准化形成了阻碍。好比有至关一部分应用，在迁移到另一台物理机上后就无法运行了。由于从第一次上线到存活期间作的各类环境变动、软件升级等，很难严格的记录到发布系统里。另一个发现是T4的技术栈和Docker很是类似，都是基于linux内核的cgroup、namespace、chroot、bridge等机制运做起来的。T4使用了LXC，Docker的执行引擎也支持LXC，但神奇的是T4却可以在阿里内部老版本的OS和内核上跑起来。所以直觉告诉我将T4和Docker结合起来应该是可行的。因而从去年6月份开始对这个方向作了探索，终于找到一个恰当的模式，对Docker和T4都作了一些修改整合后，将二者融合为了一个产品，至关于既让T4具有了Docker的镜像能力，又让Docker具有了T4对内部运维体系的友好性，而且可以运行在内部早期的AliOS5u和2.6内核上。这个产品在内部称为AliDocker，在去年8月份推出了第一个雏形版本。另外这个版本还解决了Docker当时很严重的一个问题，就是Daemon退出其上全部的容器都会退出，这一点在真正生产环境大规模部署时是没法接受的。Docker官方直到1.10版本才开始部分解决这个问题。咱们当时的Docker版本从1.5一直跟进到后来大规模部署的1.9版本，经过Docker的Daemon管控进程和容器的解耦，Daemon重启后对以前运行容器的自动识别和从新接管，解决了这个问题。这样Docker在阿里内部大规模应用就有了可能。

从这个版本发布到可以替换T4大规模部署还走了很长的路，首先T4和Docker毕竟是两个不一样的产品，除了你们耳熟能详的容器机制以外，其实还有很是多的细节和特性。为了让应用在迁移中无感知，AliDocker对原先T4容器的细节功能作了全面的兼容，同时对上层的运维系统作了大量改造，使其支持Docker场景下的发布和运维模式，从Docker镜像构建到分发启停、扩容迁移都作了完备的工具和流程支持。其次在T4到AliDocker切换的过程当中，咱们作了2者混跑的支持，也就是说同一台物理机上能够同时跑原来的T4容器和新的AliDocker容器，互不干扰而且能统一运维。由于众多应用的实例是交错部署在众多物理机上的，同一个物理机上每每有十几个不一样应用的实例混跑。这种兼容机制就保证了不一样应用能够按各自的节奏逐步完成Docker化，而不须要在某个时间和空间作一刀切，避免了大规模升级Docker的过程当中没必要要的应用腾挪和迁移。而后在咱们将AliDocker和T4功能彻底对齐，从实例级别到应用级别作了足够的灰度后，推送了一个开关，使得从那一刻开始建立新T4实例时会自动建立为AliDocker实例，从而完成了增量实例的切换。对于存量的T4实例，咱们选择了一个完整的深圳交易单元，分批次作了批量切换，在切换期间若是发生大的问题，能够把深圳单元的流量所有切换到上海。这一保障要得益于阿里的异地多活灾备架构，对于这类底层基础设施的升级可以提供理想的兜底方案，使咱们勇于放开手脚去作，而又能有效的控制风险。所幸在整个升级洗牌的过程当中，没有动用到这个大杀器的功能，虽然出了一些小问题但都能及时修复，影响不大，也让咱们的系统更加健壮，让各个部门的人对交易核心流量切换到AliDocker这件事情更有信心。

 

2. 核心应用镜像化

可是仅仅将运行容器从T4切换到Docker其实对咱们带来的改变并不大。Docker真正的核心价值在于镜像机制，以及镜像机制带来的研发与运维模式的变革。应用镜像化大体来讲有2种方式，一种是比较保守的方式，镜像中只包含基础环境，容器起来后，再登陆到容器中部署应用包。这种方式和原先的T4相似，镜像化上不够完全。为了完全根治环境不一致的沉疴，从机制上杜绝非标准变动，让每一个环境改变都沉淀下来，咱们采起了另外一种更激进的方式：镜像中除了包含基础环境外，还包含应用程序。应用新版本发布时，直接销毁原有的容器，用新版本的镜像启动新的容器提供服务。这样任何在上一个容器中作的小动做都会随着下一次发布所有清洗掉，若是想要保留下来，就必须固化到应用的Dockerfile中。一个应用镜像就表明了应用的全部依赖环境和当前版本。任什么时候间任何地点将应用最新镜像拉起，都能获得和线上其余实例一致的服务和行为。咱们在推广AliDocker的过程当中，一直和全部的应用方强调这个理念，也得到了你们的认同。

因而在今年5月底，咱们成立了专门的项目组，快速推动这个事情，目标是把双11流量覆盖的核心应用所有升级为镜像化模式的Docker应用。因为咱们作到了运行态与T4保持一致，改造过程比较顺利，但实际上线中也遇到了许多问题，其中最大的问题就是发布与扩容速度。在镜像化以前，应用新版本发布时只须要分发应用包自己，而应用包通常只有几百M的大小；切换到镜像化模式以后，因为镜像包含了一个完整OS的lib库以及应用依赖的rpm包，每每有几个G的大小。应用一下感受发布过程变得很是慢了，有时慢到难以忍受。同时这个变化对分发网络和Docker镜像仓库也形成了很是大的压力。在大规模发布或扩容时，很容易把仓库的下载源打挂，发布失败率居高不下，严重影响了整个发布速度和体验。为了解决这个问题，咱们成立了紧急攻坚小组，集中精力对发布扩容链条的各个环节作了大力优化。

首先，在存储上，AliDocker镜像仓库的存储直接使用了阿里云的分布式文件存储产品OSS。阿里内部的线下开发测试环境和线上正式生产环境在网络上是隔离的，而OSS产品在服务端作了线上和线下的打通。AliDocker除了用OSS解决了镜像存储的高可用问题之外，也借助OSS的这个特性实现了线下push镜像线上pull镜像的功能。

其次，在分发架构上，因为阿里在全球各地都有机房，大规模扩容时除了异地机房延迟增长以外，还有可能把长传带宽打满，因此咱们在每一个地区搭建了镜像mirror和超级缓存中心。在节点上下载镜像的单个层时采用了相似BT(BitTorrent)的P2P链式分发技术，P2P分发中超级缓存中心做为默认回源节点。这样镜像仓库mirror加链式分发组成的多级细粒度分布式分发网络大大加快了分发速度，完全解决了服务端网络和存储的压力。

最后，在发布流程上，咱们针对内部发布系统作了多项优化。好比采起了预热模式，线下构建好镜像后就直接异步分发到线上各地域的mirror中，分批发布中第一批机器在执行时，第二批机器就提早去pull镜像。另外把以前固定的分批发布策略改为了智能滚动分批。每一个批次的机器发布执行过程当中，每每总有几台长尾机器比较慢，若是等这些最慢的机器都执行完才去执行下一批，在实例不少的时候会拖慢整个发布的过程。改为智能滚动分批后，在第一批发布完成应用owner确认没有问题以后，后面批次的发布不会等待长尾实例结束就会直接执行下一批，这样大大提升了并行度，减小了发布自动执行过程当中没必要要的等待时间。

在全部这些优化以后，实例最多(近8千个实例)，发布最慢的那个应用，总体发布时间缩短到了原来的1/5，而且发布成功率也大大提升，因分发问题带来的稳定性也随之消失。

 

3. 对Swarm的定制和优化

今年双11的另一个变化是，65%的流量都跑在了云上；交易主链路的核心应用在云上和云下都有实例。在AliDocker出现以前，云上和非云是两套彻底不一样的虚拟化机制，云上是ECS中直接跑应用，云下是物理机的T4容器中跑应用，应用下层的虚拟化机制不一样也形成云上和云下只能采用两套不一样的运维发布系统，让整个运维体系比较痛苦和臃肿。AliDocker出现后，将这2者统一了起来，云下在物理机上跑AliDocker容器，云上在ECS上跑AliDocker容器，应用及上层运维系统看到的都是AliDocker容器。统一的机制带来更简单的实现。咱们在这个时间点引入了Swarm来作Docker容器的管控。Swarm协议基本兼容daemon协议，只在很小的几个点作了改动，能够将一个物理机集群当作一台宿主机来操做，为集群背景下的测试和运维带来了很是大的便捷。咱们对Swarm作了一些改造，使Swarm支持批量建立容器，功能相似后来Docker1.12版本的swarm模式引进的replica概念。由于咱们绝大多数应用最小化的部署实体都是对等部署的，多个容器中跑的是彻底相同的镜像和配置，所以只是将Swarm中一次建立容器的请求处理过程，并行在多个物理机上执行就达到了目的。至于这多个物理机如何选出来，咱们现有的资源管理平台有一套本身的调度系统，所以咱们修改了Swarm的调度部分直接对接到了咱们本身的调度系统上，同时对接了咱们内部的集中式ip资源管理系统。每一个容器的ip独立于宿主机的ip，不须要端口映射，就能够直接发布到服务注册中心，供其余应用直接调用。

这个定制化的Swarm产品在内部称为为AliSwarm，除了调度以外的基础功能都与官方Swarm相同。可是随着AliSwarm接入的节点愈来愈多，官方Swarm的实现部分暴露出了诸多性能问题。好比Swarm内部存在系统线程会随链接数增加的问题，当node达到必定量时大批量增删node很容易形成Swarm实例直接crash；在node节点数变多的状况下，总会有那么一部分node节点不那么健康，在这种网络频繁时断时续的极端状况下，Swarm的内部处理存在链接泄露问题，会使系统资源消耗愈来愈大；每次大规模节点上下线时node列表会发生频繁变化刷新，内部识别哪些是新增node哪些是删除node时作的diff操做会大量消耗cpu；另外对单个容器的查询须要遍历全集群的容器信息，当节点规模在1W以上时，这种遍历也会消耗大量cpu，等等；AliSwarm在逐渐接入整个电商规模节点的过程当中逐步发现这些性能问题，并一一作了解决。官方Swarm单实例可以平稳运行的最大集群规模，按以前官方公布的数字是1000台宿主机。AliSwarm在双11以前实际线上运行的单实例集群规模已经在3万以上，而且32核机器cpu的load在5如下，在双11建站期间可以支持并发3千个以上的实例同时扩容。

节点规模变大以后，每次swarm自身发布初始化过程会持续几分钟，系统可用性下降。同时咱们有部分业务须要独占的隔离资源池，若是为每一个资源池都搭建一套Swarm维护成本比较高。所以咱们开发了SwarmProxy系统，作了基于TLS证书管理多个集群的功能。同时每一个集群运行2个对等的实例，一主一备，同一时间，只有主实例提供服务。主实例发生故障时能够自动切换到热备实例。这样AliSwarm自身版本升级时，就不须要等待新实例初始化完成才能提供服务，而是先让旧实例继续提供服务，新实例启动初始化完成后替换原来的热备实例，成为新的热备，而后再作一次主备切换完成升级。这个主备切换过程会根据版本号大小和新版本初始化完成状况自动执行，毫秒级完成。

 

4. 阿里中间件（Aliware）Docker化

除了交易应用外，今年咱们还推动了阿里中间件(Aliware)的Docker化，中间件相对于应用来讲主要区别是有状态、性能敏感、资源需求差别大、有个性化的运维标准等。中间件的状态通过分析主要分为三类：数据状态、配置状态、运行时状态。针对数据状态，咱们经过挂载Volume的方式，让全部须要持久化的数据，所有直接落到宿主机的指定目录中，以保证容器升级或变动后，数据可以不丢失；针对配置状态，咱们采用了镜像和配置分离的方式，容器启动时，会根据启动参数或环境变量去配置中心动态获取运行时配置，经过这种方式能够实如今任何环境下均使用相同的镜像，以减小镜像构建和传输的成本；针对运行时状态，咱们制定了中间件镜像标准和运行时管控标准，对容器进行操做的时候容器管控平台会按照既定标准和流程进行，以保证整个过程平滑和可以被容器内应用感知并进行相关前置操做。

阿里中间件(Aliware)做为集团内的P0级基础服务，对性能的要求近乎苛刻，咱们在Docker化之初就定下目标，性能损失须要控制在3~5%以内。影响中间件性能的因素主要有网络、CPU、内存、磁盘、内核、依赖包等，因此在实施过程当中，咱们对每一款中间件均进行了详细的性能测试，测试场景涵盖物理机+Docker、物理机+VM+Docker、物理机+T4，通过测试、内核、网络、容器、中间件等多个团队的通力合做，最终全部中间件Docker化后的性能均达到预期，并沉淀出了Docker化场景下针对不一样性能影响因素的调优方案和策略。

阿里中间件(Aliware)对资源的诉求也比较多样，好比消息中间件对网络、磁盘需求较大；缓存中间件对内存需求较大；数据中间件强依赖CPU性能等，针对这种状况咱们在资源调度上会均衡各产品需求，让有不一样资源诉求的中间件共享宿主机资源，以保证宿主机的资源使用率保持在合理的范围，既节约了成本，又提高了中间件的稳定性和性能表现。在双11大促备战期间，咱们还对Docker化的中间件进行了资源的精细化调整，测试并评估了超线程（HT）带来的影响，并对强依赖CPU的中间件进行了调核，以规避资源争抢风险，进一步提升了中间件的稳定性，此外，咱们还具有Docker化中间件资源动态调整的能力，好比双11大促前，咱们能够动态为数据中间件增长CPU配额、为消息中间件增长磁盘配额。

在阿里集团内部，中间件(Aliware)每一款产品都有本身的个性化运维需求和流程，在这样的背景下，咱们以AliDocker为推手，完成了中间件统一运维标准和体系的创建，并产出了中间件Caas平台和场景化运维平台，中间件运维效率、资源管理效率均获得了极大提高，双11前咱们实现了全部中间件的Docker化改造，并承担了线上20%-100%的流量，按计划到财年末咱们将实现中间件的100%Docker化。

在今年刚刚过去的双11中，从AliDocker引擎到上层运维部署体系都经历了一次大考，最终交易全链路全部核心应用所有在AliDocker容器中圆满完成了1207亿成交额的答卷，也证实了AliDocker技术体系在电商交易级别的大规模应用中可以担负重任！