作为容器技术的负责人和容器技术的布道者，我们认为容器接下来肯定会大放异彩，而容器会在部署、运维对我们服务监控的过程中，能够大幅度提高我们的效率，也能够大幅度提高机器的使用效率。

大家好我是七牛容器云计算的负责人袁晓沛。因为作为容器技术的负责人和容器技术的布道者，我们认为容器接下来肯定会大放异彩，而容器会在部署、运维对我们服务监控的过程中，能够大幅度提高我们的效率，也能够大幅度提高机器的使用效率。另外一方面让软件工程师兴奋得一点，容器好玩的是以API的方式也就是可编程化的方式操作整个数据中心，这样子的话所有前面的事情都是可以自动化下来的，这是很酷的一件事情。我先简单讲一下容器化的由来，这角度可能不太一样。

我们当前这云应用想要去做计算的云化困扰，首先当前的应用场景是比较多样化，比如说我们区块链人工智能是资源消耗型的应用，物联网是需要传感器特殊的硬件，像AI这一些东西可能需要GPU这一些特殊的硬件，所以应用的场景是比较多样化。另外一点是OS的多样化，现在好多企业服务它们的应用还是在widow的及还有一个开发语言式多样化，我们一个团队内部甚至可能会有不同的语言出现比如说C++还有JAVA还有Python、还有Golang，还有不同公司的语言更是多样化所以导致云化也比较的困扰。最后一个是云平台的多样化，当前云平台其实有蛮多的，有七牛、阿里、腾讯、青云还有AWS、Open Stack。其实我们企业在上云的过程中大家都有一个顾虑，就是说我们很担心企业应用架构被某一个云厂商绑架，这也导致云化有很多的困扰和困难，这是当前主要的一个问题。

另外一个就是当前企业架构云化的立场，早期的话我们企业管理，就是说一个企业内部是所有的事情都是自己管，从下面的网络存储到物理的服务器，到了虚拟化这一层到操作系统，再到这一些数据库缓存的中间键，最后到上层的应用都是我们自己管，而对于我们企业来讲其实各个纬度都需要一些人，比如说在硬件和网络的层面是需要运维方面的人，在上层应用方面又需要应用开发的工程师，所以对他来讲这个链路是比较长成本也是比较高的，接下来到laas层面就是现在大家用到阿里云或者AWS虚拟机服务，用到虚拟机服务就是说下面网络、存储、物理机这一些东西都不要关注，还要关注中间键，以及上层的这一些应用，甚至OS的话我们自己关注一些，我们还要关注操作系统，这一些纬度稍微多操心一点，没有做到完全没有负担的。

到第三个阶段对于我们应用开发者只能关心自己的应用的业务，我只需要关注实现什么样子，我不用关心业务跑在什么的物理架构上，物理机或者虚拟机，我也不用关心监控、运维、日志怎么去管，我只要想要就能给我，这是当前所崇尚，这是当前正在走的一个阶段，所有下层的Runtimn，操作系统、系统化存储网络这一些东西统统有人帮我搞定，我只需要做我的业务。

为什么容器化和这阶段特别契合呢？首先容器左边这一边是谷歌非常重要的基础架构，而谷歌基础架构副总裁展望未来十年软件开发微服务和容器的方式呈现这方式可以改变未来。因为在谷歌没有阶段虚拟机占主导地位，谷歌前两年出了一个论文，内部的所有系统包括GFS都是跑再一个容器系统里面，但是这容器系统本质上还是（Com）不是Docker的理念，在大型的数据中心已经践行了。容器是一个巨大的变革，至少像云计算一样，我们七牛也是这么认同。

左边是虚拟机，整个虚拟机是构建虚拟机一层，所以说我们还是要操心这操作系统，而且这操作的起停还是有一定的成本，操作系统的运行有一定的性能损耗，最重要的一点其实就是它的运维是无法自动化，还有一点它跑在物理机上，我们物理机只能跑几十个虚拟机。但是右边是一个容器的架构，所谓容器的架构就是直接跑在物理机上是没有虚拟化这一层，虚拟化是很薄的应用层隔离来实现的。在这一层上我们只用关心我们的应用，以及我们应用的依赖，而且这一层应用的依赖是可以打包，在这样的环境下我们的容器起停是可以做到秒级，容器的进项的获取是比较快。所以在这种情况下我们一台机器可以运行数百个容器，甚至有可能上千个容器，如果你物理机够强的话是可以做到这样。

所以整个看来容器它在2016年是软件行业几大趋势之首，另外一个就是容器，Docker是比虚拟机更轻量化的虚拟化技术。第三用Docker的方式来实现应用的标准化，可以让我们对应用混合型部署，可以比较容易的迁移，而且我们关注应用这一层面，而不用关注具体它所跑的运行环境，以及下层的基础硬件。

接下来我会介绍一下七牛几个典型的容器场景。简单来讲就是七牛它最早是在2015年左右就把我们的容器放在多媒体处理业务上，我们简单来讲应用发布从一天时间，有时候应用发布一天，但是我们几分钟，另外一个我们物理资源利用率从40%提高70%以上。因为多媒体转码业务是CTU密集型业务，它的资源利用率意味着我们的物理资源成本降的更低。

接下来是2016年我们把容器用在我们大数据业务里面，我们基于一个大的物理的资源池，可以秒级创建一个Spark集群，另外一个就是我们可以一键扩容新的节点在现有的Spark集群里面。

最近是我们把机器学习的训练业务在容器里面，这样我们把一个机器模型到上限可以做到完全无人工干预可以自动化进行。当前我们在七牛有五个以上的数据中心，运行着上千台的机器、上千台高性能机，也有近百台GPU的机器都是运行的容器。其中里面有上千个应用，整个容器的数量有上万个，这是当前容器在七牛的运行情况。

我介绍一下七牛的多媒体转码的业务，这是我们业务的介绍，其实我们这多媒体转码业务是运行在我们存储和CDN之间的业务，是用户在下载视频或者下载一个图片的时候会实时对这图片和视频做这种格式或者码力或者分辨率的变化，它里面有两种类型的一种应用，第一种类型是七牛自己研发的转码应用，还有一种是第三方供应商提供的转码服务。这跟我们线上的情况机器数是比较多，而且每天的请求数是近百疑次请求，QPS是到十元左右，之前可以支持5000路地化转码。这转码系统最早是运行在物理机上，物理机上就有几个痛点，其中第一个就是部署比较难，因为七牛的官方应用有几十个，但是我们的供应商第三方用户他们的转码用户有几千个应用，这样子的话基于手动去部署，手动去运维就非常的琐碎和麻烦，因为应用数特别多，所以之前我们做法是需要事先规划物理机的资源，需要规定机器的配置，部署和回滚都比较麻烦。另外一点就是资源利用率比较第。因为之前的话我们是把服务的实力部署和具体的物理机的绑定在一起的，所以无法灵活调配，所以不同的应用业务的峰值和流量不一样，所以导致机器的压力和负载是非常不均衡的。

而且就是在这种情况下资源利用率比较低下，平均不到40%左右。接下来一个就是说运维比较难，因为你的服务部署之后你需要看它的监控还有日志，甚至要配置它的告警，这一些基于物理机的情况下都需要手动来搞，还有业务峰值比如说某一个厂商某一个转码服务，在双十一的时候就需要业务量比较大，它就需要伸缩，但是我们很难去实时的弹性伸缩，必须事先去帮它做好这事情手动来做。另外一点就是多服务它是无隔离的方式来做混布，相互影响。因为有的服务流量比较大，它如果挂了会导致机器宕机，会牵连到机器部署的其他服务，所以问题还比较多。

这是我们做容器化平台化之后的一个框图，简单来讲就是我们无论是七牛的官方应用还是我们的第三方应用我们都让它以容器的方式打包它的服务，按照我们这平台的规范，用容器的方式来打包它的服务、传到我们的进项中心，它的每一个发布是基于某一个集群，它的发布是有一个版本号，每一次发布都是可以回溯，而且每一次发布实际的数量可以及时来选，这样整个的流量自动化起来，日志和监控的信息通过平台的方式让这方式呈现在里面，甚至可以通过API的方式呈现，这用户可以随时去，他可以需要调用这API，可以获取日志监控的信息。

这容器平台化的一个优势，第一个是快速部署，我不需要事先规划物理机资源，因为我们把所有物理机资源放在一起供所有的人来用，对于使用者来讲一键可以发布应用，甚至可以做到灰度升级。第二点资源利用率提高，因为原来的部署是固化在某台机器上很容易导致物理机资源负载不均衡，负载机器的方法可以让物理机负载均方差可以降低到10%以下，这是物理机平均资源利用率提高百分之七八十以上。最后一点就是说对于运维的便捷性，监控日志告警这一些东西都是平台化自己分会，业务峰值自动弹性伸缩，多服务以容器隔离的方式混布，我们定CPU、内存什么样这是带来的一些好处。

这边是一个更具体的阐述，就是左边这里是一种传统的部署方式，比如说应用A部署在集群B里面，应用B部署在集群B里面，我已经固化这种部署，A资源利用率达到80%，甚至会把机器压的宕机，但是C只有10%，不能帮A抗压力这是传统的部署方式带来了一些缺点。资源是静态规划的，如果说想让这资源更均衡，我们就需要人肉、手工去做迁移和伸缩，出现故障也需要人肉去抗可能需要大量的冗余资源去抗这情况，右边是集群达到的平台也好，也就是说应用A、应用B、应用C通过容器实力部署在ABC大集群里面，其实本身来讲这集群不分ABC，就是所有的容器部署在这里面均衡的分布，甚至有一些机器的这种负载高，我们会动态做一些容器的迁移，这样保证整个集群相对来讲它的机器的负载均方差比较低，大概负载都是50%60%不会有人太高、不人有人太低这样的情况。这样就让我们的集群利用率太高，我们不需要特别冗余的资源。

这是一个典型的场景，我们电商秒杀的场景，比如说我们常见到618或者双11的情况，某一个图片处理，其实七牛这样的电商类客户还是蛮多了，按照以往会提前打招呼，你要帮我备一些，这样子我才能抗618、双11但是有了容器集群管理系统以后，我们集群硬件都纳入系统管理，所以到了活动期间，这业务对应的应用峰值上来之后，我们基于发现KBS应用系统自动的扩容新的应用实力，所以活动期间应用实力会变高，应用的TPS也会升高，所以这种情况秒级的扩容完全无人工干预可以应付客户秒杀业务非常峰值的场景。

接下来是我们的spark大数据平台，按照大数据这技术栈，我们大数据分几个纬度，首先是上面可视化的纬度，就是软件有Zeppelin，可以发一些命令，第二个是批量实时，比如说Hadoop、Mesos运算软件。第三层是集群调度，比如说Hadoop议案或者Mesos集群调度平台。最后一个是存储就是开源长期适用的Hdfs。最后一层还有关于大数据服务的监控、运维相关的，比如说监控服务Prometheus还有Influxdota等等，我们还有一些高可用的Zookeeper，像一个每一个组件布一个完备的服务，每一层都是必须所以这结构是蛮复杂的。

七牛这边我们有一个Spark业务基于对七牛存储的驱动来运行的，它支持多租户比较适用于处理大量日志的Bucket每一个用户可以建spark集群。我们七牛是为线上服务，痛点很明显就是部署比较难，前面提到大数据的组件比较多，仅就spark本身来由一个Master有一个Worker还有一个Zepplin可视化的东西，我们的用户随时需要启动一个新的集群，基于物理机很难自动化下来。另外一个资源规划比较难，因为用户对于分析的数据量级是不太确定，对于分析结果时长期待也不一致比较难把握，所以对于要多少资源也比较难确定，第三点运维比较麻烦，还是监控日志告警这一些东西都是手动，业务峰值的时候跟前面一样也没法伸缩，各种业务还是会互相影响的。所以我们这边玩法是这样子，这个图大家看不清楚，简单描述一下首先把大数据的各个组件就是Master、Work。容器化就是搞到容器里面来运行，模板化就是把这一些每个容器的运行参数，运行的环境以模板编排的方式写到同个文件里面，而且在这文件里面能够构建多个节点之间的协作关系。另外一点就是参数化，为什么参数化呢？因为不同的用户在起一个Spark集群需要规格是不一样的，不同用户需要CPU内存强劲一点要16和32G，有的用户1核2G就可以了，另外一个Worker的个数，因为Worker个数越多每一个规格越强，处理能力就越大，所以不同用户对这两点需求不一样，在这样的参数情况下在应用创建的时候，其实我们有一个界面是让用户去选择这一些规格，多少个Worker，多少CPU配置，就需要集群管理系统启动起来，最后一点就是伸缩性，当你发信整个集群不太够用了，Worker想等的时间够久，一种是横向伸缩，就是我增加更多的Worker，在这里面也是一条命令的事情，因为我们只要重新设一下Worker容器数量就行了，因为Worker有Master信号就是可以加集群工作，另外一个纵向的伸缩，但是基于容器我们可以很容易做到，因为我们可以改变现在有的这一些容器实力的规格，如果这容器所在的物理机上是有剩余的资源改完规格重启一把就能继续工作，这一些它能使用的CPU和内存的配额就更大了。如果说资源不够随时切到另外一台有足够资源的上重新启动起来这一点也比较容易做到。

所以Spark容器化优势对我们有一个优势，就是一键部署，不需要事先规划资源，物理机的资源池化随时创建新的Spark集群，而且为新的集群增加Worker和调整配额。运维就是一站式日志、监控和告警。

最后简单说一下机器学习业务，这是七牛机器学习框架图。中间这一个蓝色长掉是我们容器本身，基于这容器我们机器学习的Cafue Mxnet都是容器平台之上，基于这系统我们可以让我们所有机器学习的镜像，基于镜像可以快速构建新的机器学习。另外一点可以为大量训练提供弹性的资源。第三个是训练后的资源，因为训练后它是一个模型，模型你要发布基于传统的方式还是需要人肉，基于容器就可以打包发布，把这模型发布一个新的集群。最后一个资源利用率提高，大幅度提高机器学习的硬件成本，提高它的效率，因为机器学习这一边的话，它其实往往是依赖GPU，一台GPU二三十万比较贵，我们如果能够提高这一些资源利用率，对于机器学习业务来讲能够降低他们的成本。

最后我想讲的就是容器这东西很好玩，能够我们以软件变成化的方式调度我们区域资源、操作我们资源中心，包括日志、自动、升级、降级，欢迎大家都来玩容器，谢谢大家。