本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾何小锋老师分享内容整理而成，文字编辑：吴召军@腾讯，录音整理：刘玉强@京东。
欢迎关注“高效运维（微信ID：greatops）”公众号并置顶，以抢先赏阅干货满满的各种原创文章。
讲师介绍：何小锋
拥有18年的研发经验，喜欢技术，追求卓越。
2011年加入京东，担任了京东两届架构委员会常委。在京东负责过百亿级的分布式消息系统。2014年下半年开始负责基于Docker的弹性技术平台，通过诺亚方舟项目，成功的让京东各个业务系统全面迁移到容器上。
在京东期间支持过多次的618和双11大促，见证了京东的技术演进过程，在弹性计算、中间件、存储和大并发分布式系统等方面积累了丰富的实践经验。
大家好，我是来自京东的何小锋，今天我跟大家分享一下《京东Docker的实践经验》。
1、京东容器之路
1.1 面临的挑战
京东为什么要使用Docker？京东在以前主要是基于物理机进行应用的部署，随着京东业务的发展，面临着很多挑战。
比如说，硬件采购周期比较长，新的应用有可能会等一个月，物理机才会上线。
很多应用部署到物理机上，应用资源的使用情况，大家掌握得不是很清楚，你没有办法精细化运营这个应用。
它是用得多了还是用得少了？而且硬件的成本也很高，每年京东物理机采购上万台，成本很高。
在双11或者6·18之前会做一些压力评估，需要快速扩容，现在扩容的话如果采用物理机的话，京东会花费一个月的时间进行扩容操作，非常慢。京东还有很多数据中心，要把整个部署完需要很长的时间。
1.2 用户关注
我们采用一些虚拟化或者容器的技术解决我们面临的问题，在跟用户沟通的过程中，用户真的不太关注你是采用物理机还是容器、虚拟化的技术，其实他们更关注的是，你给我换了技术以后，系统是不是稳定的？
例如，一些下单操作、京东首页性能要求敏感的应用，对性能是非常看重的，如果使用容器，要确保性能没有损失。
京东有五千多名研发人员，要确保用户的体验，如果你换了新的技术，还需要对所有的人再一次的培训，花费的时间是非常长的。
1.3 容器化之路
在2013年我们最初采用的是虚拟化的KVM的技术，在用的过程中，面临了性能的问题，有几个核心的应用性能达不到要求。
在2014年我们看到容器发展比较迅速，在2014年四季度采取容器技术进行试点，最先试点的是京东图片系统，发现性能非常不错，而且我们做了弹性伸缩调度，效果也非常明显。
所以，我们在2015年第一季度就把弹性的平台做起来了，在6·18的时候就用在了生产环境，在6·18的时候没有采用物理机来分配，能分配容器的全部使用容器分配，分配了差不多1万个容器。
在6·18期间非常稳定，并且在下半年新机房的建设全部采用容器建设，目前京东的容器数已经差不多有10万的规模。
1.4 选择Docker的原因
我们从KVM切进Docker的时候，做了一个评估，我们觉得Docker还是非常胜任京东应用场景的。
它比较轻量，性能比较好，可以快速部署，稳定性足够高，在京东的环境下对安全性也要求不高，所以说，我们用Docker非常合适京东私有云的环境。
2、弹性计算架构
其实京东的私有云的弹性的架构还是比较简单的，我们采用了开源和自研相结合的架构。
基础的平台更多的采用社区开源的技术，包括OpenStack、Docker、虚拟化网络、OVS，存储是采用京东资源的分布式存储系统。
在上层我们使用的是自己的一个调度系统，是一个CAP的调度，它做了一些应用的治理和部署，包括弹性的调度、监控。
2.1 OpenStack
在Docker的外面我们包了一个OpenStack，社区里有很多人不使用OpenStack，其实我们是结合京东的一个现状来采用的OpenStack。
京东做虚拟化是从OpenStack开始做的，所以说下面的团队对OpenStack还是非常了解的，我们沿用OpenStack做集群的管理，而且OpenStack也相对比较成熟。
我们做Docker的时候，社区这些都不是很完善。所以，我们就是沿用OpenStack，而且OpenStack社区的方案还是非常多的。
还有一个目的，我们现有的京东公有云也是做了OpenStack做了集群的调度和管理。
2.2 网络
网络方面比较简单，我们就直接选择了OVS/VLan的模式进行处理，但是在性能上我们做了优化，特别是一些包的延迟，做了很大的提升。
经过我们的优化以后，本身网络的一些性能会有20%的提升。
为了保持用户的习惯，京东所有的基础设施都是以IP来做区分的，所以我们为每一个容器都分配一个独立的IP。
2.3 存储
我们是使用了京东的自研的分布式系统来接JFS来做块存储，本地存储是用于满足日志的需求。
把日志打在物理机上，不是打在容器里面，主要是为了满足容器丢了，日志还可以查看一段时间，通过分布式的日志系统，近实时地把日志采集走，如果容器宕机的情况下，它可能会有那么一丁点时间日志没有上传到分布式日志系统中，但是可以人工地恢复这一块的数据。
2.4 镜像分层合并
镜像分层上，我们采用了OS层、基础层、应用层的架构，把平时变更比较频繁的应用层做了镜像，相对比较小，这样可以减小一些存储的压力。
2.5 镜像中心
在京东有比较严格的项目管控机制，我们会对生产环境、线上的环境、预发布环境、开发、测试环境，我们会对线下的测试环境把镜像做好，做好之后再推到生产环境。
镜像在开放环境和生产环境是严格隔离的，必须要经过一些处理才能上传到生产的环境上。
镜像的存储还是使用我们京东的JFS这样一个分布式的对象存储，它也支持块存储。
2.6 配置中心
京东有很多不同的环境，它的配置是不一样的。所以，构建了自己的配置中心，在容器或应用启动的时候，可以自动拉取对应的配置，可以满足一个镜像尽量不用改动就可以部署在多个环境里面。
2.7 调度系统
我们自研的调度系统是一个类似于工作流的引擎，能够做到动态服务发现，便于扩容。
为什么要采用这样呢？
容器调度更多的是一个流程的调度，它要把京东的基础设施等按照一定的流程串起来。
我们目前实现的一些调度流程，包括线上做一些镜像，包括上线、下线、重启、故障牵引、弹性收缩。
2.8 弹性扩容流程
这一块的流程，我们首先做了弹性的评估，觉得要进行一个弹性扩容以后，首先会创建整个容器，会做一些相关的授权。
比如说，可能会有一些MySQL的授权，还有一些其他权限的授权，通过我们的部署系统把这个应用部署上，再去检测这个应用是否起来了，这个应用起来的时候也有可能出现一些故障。
在整个起来以后，才为把我们的监控、统一日志注册上，最后正式起来以后才会把流量打进来，调用一些负载均衡，让它把流量可以引到这台容器上，最后再上一个弹性的流程，才是一个完整的结束。
2.9 故障迁移流程
在一些故障迁移方面，如果检测到某一台主机或者容器出现故障的情况下，也会触发它迁移的过程。
牵引首先会把流量摘掉，让没有流量打到容器上，创建一个新的容器把应用部署上，然后把它注册起来。
我们在牵引的过程中会保持整个容器的IP不变，这样就少了很多其他授权的一些操作了，数据库授权这些东西就不用再去做了。
2.10 弹性调度算法
京东也实现了自动的弹性调度，弹性调度的算法相对还是比较复杂，它会根据我们现有应用的一些元素和信息，包括应用的重要程度、所属的业务域、需要的软硬件来进行评估，还有需要的规格，这个应用需要部署哪些机房，所有的信息我们都会弹性调度选择对应的机房机架。
我们还做了一个扩展，集成了京东微服的一个框架，会把微服采集到的一些性能数据给汇报上来做一个评估，是否要对这个应用进行扩展，进行一个弹性调度。
弹性角度目前是根据应用的分组，在一个机房的负载情况下做一个弹性，而不是根据一个容器实时地进行弹性，最后是应用整体情况负载做一个弹性。
因为有时候出现一些应用程序的Bug，可能某台负载比较高，但是整体负载比较低。
3、弹性计算应用场景
现在核心的一些应用，除了大数据的应用，其他应用基本上全部牵到这个容器上，我们现在所有的机房都是用容器建设的，主要应用的技术架构都可以牵进来。
比如Nginx等，还有我们京东的微服的架构JSF，包括Oracle的一些应用，还有redis，redis在京东是一个非常大的容器集群，它也是放在我们这个容器上。
京东也在用容器做MySQL的管理，不是所有的应用都需要微软很高性能的MySQL独享物理机，我们有一个云数据库是提供一些其他应用来使用的。
4、自动化运维
4.1 系统监控指标
我们采纳容器来做推广以后，对我们一些自动化的运维也做了很大的帮助。首先是监控，我们会把所有容器的基本指标都能采集到，包括系统的负载、网络的流入和流出，在这方面的一些指标采集也做了扩展。
把这些数据采集起来之后做一些实时的计算，存在基于Hbase的数据库下，这个量也非常大，我们现在容器量很大了，每一分钟都有这样的数据上传下来，所以数据量是非常大的。
然后，会做一些监控报警，根据自己的一些指标进行配置，是否需要去做监控报警。另外，根据这个指标其实也可以触发我们自动弹性的一个伸缩策略。
4.2 监控页面
可以对一个容器进行监控，也可以对一个应用做一个整体的评估，包括这个应用网络流出、整体CPU占用量，可以从多个维度进行查看。
4.3 报警策略
可以让应用进行个性化的设置，只需要设一套策略以后，每一个容器出现问题都会进行实时的报警，包括一些邮件、短信的通知。这也是跟我们京东所有的用户体系打通的。
4.4 一键水平扩容
我们要做扩容，以前扩容要部署物理机，各种情况也是非常麻烦的，现在我们可以快速地扩容，一键地进行扩容。
4.5 一键垂直扩容
除了这种水平的扩容之外，还支持垂直的扩容，因为应用有可能会对一些规格进行一些调整，比如要把自己的内存扩大，这方面也做了一定的垂直扩容。
但是这里是有一定局限的，如果本机上不够的话，我们只能牵引到其他机器上进行扩容。
4.6 宕机探测架构
自动化容器宕机检测
因为有很多机房，有可能一个点去检测机器的话，评估出来的报告是不准确的。
所以，我们在每个机房里都会有很多检测的程序，每个机房只负责检查本机房的容器，分布在不同的机架上、不同的交换机上，同时检测某一台容器，如果说全部认为这台机器可能会宕机，我们认为它的评估是比较准确的，认为这个容器宕机了就触发故障迁移流程。
4.7 硬件故障探测
对于硬件故障我们进行了一些检测，这里主要是通过一些协议，拿物理机硬件报警的一些信息，京东的物理机数量越来越多，但是采购的机器或多或说的经常会有一些问题，所以说我们需要自动地检测出来，及时地进行通知，做一些故障牵引。
4.8 故障通知
我们检测到物理机出新故障以后，会马上给相关的人做一些通知，进行一些处理。
4.9 应用部署巡检
在使用容器建设过程中，随着新机房的建设，逐步的扩容会造成一些应用部署的情况并不是非常健康。
我们会从应用的整体架构会做一个巡检，报告某个机房部署过多，如果需要跨机房容灾的话，必须确保两个机房的数量一致，还需要确保应用跨交换机部署。
如果应用在一个交换机下部署过多的话，该交换机宕机会影响应用的承载能力。
所以，我们会从多个角度巡检部署是否是健康的，做一个邮件的报告，让应用进行一些调整。
5、数据驱动的精细化运营
5.1 资源利用率
在精细化运营上，会以每个小时为单位计算容器资源使用率，然后根据容器的资源使用率计算应用的资源使用率，通过应用和部门关系，计算部门资源使用率。这样，我们能够很好地控制目前的应用随意申请容器。
5.2 容器资源利用率
通过容器资源使用率，通过简单的数据的分析，可以计算出应用使用情况。
如果一个新的应用来申请容器，可以找到一个类似的应用评估一下容量的数量，包括负载的情况，可以得出一个合理的数据。
5.3 部门资源利用率
部门的资源使用率可以作为部门考核的依据，这样可以看出部门申请了多少资源，整体的资源使用率是高还是低。
5.4 资源剩余情况
掌握现有资源情况，还剩余多少，是否需要尽快补充资源，可以给硬件采购的人提供一些建议。
5.5 配额管理
京东有一个比较特色的东西就是配额的管理，因为京东是一个非常大的集团，大家资源的需求可能各不相同，为了满足一些重要系统的需求，我们会对一、二级部门进行一个资源的隔离。
界定这个部门最多可以使用多少资源，做一个整体的划分，下面所有容器的申请、弹性的角度都必须在总体的配额下进行管理。
6、实践经验
- 无状态，同时对磁盘IO要求不高的应用，很适合部署到弹性云
- 微服务应用由于能自动服务注册发现，辅助均衡，非常适合部署到弹性云
- 推荐使用万兆网络和网卡，避免网络共享出现资源竞争
- 选择稳定的操作系统版本，不同的版本可能会有一些内核的Bug，一旦出现问题，整个系统都会出现问题，对应用来说是灾难性的
- 推荐高配置物理机，合理得CPU和内存比，便于充分利用资源。如果说不合理的话，会浪费很多CPU和内存
- 采购高质量的交换机和物理机。如果物理机有质量问题，可能会影响非常多的应用，对这方面我们的要求把关是非常严格的
今天我跟大家分享的内容就到这里，谢谢大家！
Q&A
提问：现在容器的应用已经差不多到了十万的规模，看到监控整个容器里面的情况，光容器这部分的指标就已经达到了近百亿了，对监控的数据信息是怎么处理和保存的？
何小锋：我们是使用的Open TSDB这样 基于Hbase的，京东有一个大数据部门，它会运营Hbase，它有一个非常大的集群，我们全部存在里面，数据一直不会删除，这样会之间地根据数据分析应用的资源情况，也可以做资源的未来预测。
提问：接着上一个朋友的问题问一下，MySQL其实也是部署在容器里面的，但是一般来说MySQL数据库是不建议这么做的，您当时是出于什么样的考虑？
何小锋：京东有一些非常核心的应用的MySQL，目前还没有部署在容器里面。但是还有很多的应用对IO要求不是很高，如果每个应用独占一个MySQL，其实是非常浪费的。
所以，我们会采用一个云数据库的方案进行管理，主要是做资源的隔离，为性能要求不是很高的应用，提供MySQL的服务。
提问：一般我们用Docker如果这个出现问题，直接把它停掉直接推一个，但是数据是放在上面，一推全部的数据都丢了。
何小锋：京东本身的MySQL也要做高可用的方案，它也有自己的主从、数据的复制，当一台数据丢了，通过DBA主从切换，继续提供服务。
提问：原生的Open STDB只支持数值型的数据插入，对于字符型数据是怎么处理的，是直接操作原生Hbase吗？
何小锋：我们现在存的全部是数值型的，没有字符上的。
提问：你里面有一个注册日志服务的功能，我想了解一下注册日志服务的应用场景和所应用到的技术，比如有没有用到流处理？注册的话，应该有一个日志的收集，收集包含了什么样的应用和系统，Docker支持吗？这方面希望关注一些。
何小锋：京东的日志有专门的一套平台进行采集和收集，你建了一个容器以后，需要把应用和信息推给它，它才能把容器产生的日志、目录这里面的数据采集到。它是一个单独的日志系统，它会实时地采集数据流，发布到平台上供检索。
提问：我们发现在共享磁盘的情况下，它的高速读写会有一些性能损耗，可能没有那么高，IO不能达到那么高。这样，假如说日志打得很满的话，打到数据磁盘这一块怎么处理？
何小锋：有几个日志要求性能非常高，我们并不是直接打到物理机的硬盘上，采用了内存文件系统方式，让它的性能更高一下。
提问：本身做了一个第三方的内存文件系统。
何小锋：对。
提问：比如说，像你们非常多的容器，整体的服务发现调度能再说一下吗？
何小锋：京东很早就有一个微服务的架构，目前京东的应用都是基于该服务架构，它本身原生已经支持了服务发现，我不用在容器上再做很多的服务发现的扩展工作，应用起来本身会自动地把一些服务（地址）提供上去，让消费者就可以连上来进行数据的处理。
提问：请您详细说一下，您刚才说容器对高IO不是很好，您怎么得出这个结论的？
何小锋：本身一台物理机上会有非常多的容器，有非常多的应用在跑，大家如果都是高IO的话，肯定会有竞争的问题，如果是独享，IO影响不大，但是如果大家的应用都是同时享IO的话，就会影响。
比如说，一个应用是大数据的，它拉大量的数据，又遇到一个应用是疯狂地刷日志的情况，肯定会对IO有影响，现在也经常有这样的问题需要我们去解决。
提问：您说的CPU和内存比指的是物理服务器，能不能分享一下您这边推荐什么样的CPU和内存？
何小锋：这是根据不同公司而定的，我们京东采集一般都是64G、256G的内存，京东为了性能，把很多本地化内存为了充分地利用起来，一个应用起来可能希望你给8G、16G的内存。
我们根据这个应用它需要多少，如果是普通的应用，需要4C、8C，如果内存过低，如果用4C，差不多有60多个核，可能会用15个容器。如果是15个容器，每个应用希望是16G的内存，太少了，你根本就生不了那么多。
所以，可能需要你的内存，满足应用的需求。但是不同的公司是不一样的，要根据自己公司的情况去计算。
提问：刚才说的十万个容器，Docker引擎一直在升级，对于我们的容器存续时间这么长，容器升级是怎么做的？
何小锋：我们到现在还没有升级，现在还使用的是最原始版本。
提问：新建的容器呢？
何小锋：容器的版本和操作系统一样，不会随便去升，虽然新版本容器提供了很多新的功能，但是一旦要升的话，我们所有的架构需要做一些调整，对系统的稳定性影响是比较大的。
提问：终于有这个提问的机会，今天是唯一一个在容器中讲到存储的，我是做存储的。我说的数据库是更底层的，我们的容器和存储之间能不能做一个配合，我们一个系统解决方案中做容灾，容器容灾有两种办法，基于容器的解决办法本身怎么做，两者之间有没有结合？京东有什么考虑？
何小锋：存储也是可以做容灾的，我们现在是分布式的部署，我们目前的应用就是做了一个分布式的存储系统。一旦应用要上容器，我们要跟他沟通应用的场景，比如说数据恢复以后，宕机以后数据还是有需要的，从另一台机器恢复，这样的场景我们都会使用分布式的存储系统。如果本身数据影响不是很大的话，就可以让它使用本地存储，没有去做严格的规定。
提问：我想问一下，京东的监控代理是在每个主机上部署，还有选择性的部署？
何小锋：我们每个主机上都会有，其实我们现在监控是系统层面的监控和应用层面的监控，应用层面的监控是在每个容器里面都有的。
我们现在有很多应用的指标，调用到一些性能，这些东西我们是在每个容器里都有。我们容器里面监控的指标会占到5%左右的CPU，本身性能对应用影响不是很。
提问：京东的容器布在物理机上，你们有没有做业务隔离，两个应用系统用了容器做安全性的隔离？
何小锋：我们对应用的业务域或者重要级别是有区别的，根据应用单独把物理机做一些划分出来，比如这一台物理机就是给某一台重要的业务做的。
提问：物理机各个应用之间不会互用这台物理机，是吧？
何小锋：对，如果是应用有这方面的需求，我们是可以这样做的。
提问：你们当初把它建在物理机之前，有没有考虑在虚拟机上搭容器？
何小锋：虚拟机的话，它的性能已经满足不了应用的需求。
提问：是存储的系统吗？
何小锋：虚拟机的性能是达不到的，它本身要做一些系统的调度，资源的开销还是比较大的，因为京东6·18的压力非常大，一旦有10%、20% 性能损耗都不可以。
提问：固态容器里的应用应该是分布式的，虚拟机损耗的点通过更多的容器来支撑，应该问题不大？
何小锋：但是虚拟机性能比较多，需要的资源会更多。
提问：应用是不共享物理资源的，如果新上来一个开发应用，新上的应用比较多，这个资源池会提前做好吗？
何小锋：也不是所有的应用都共享，我们只对核心应用的策略做一些划分，大的应用可能一台共享这个资源，如果应用上来我们会根据业务域，我们知道这个业务是否是重要的，这个业务是用于下单的还是生产的，它的业务域不一样的话，重要性也是不一样的。
提问：何老师说要用好的网卡、好的服务器，请问你们用的是什么网卡？是英特尔的，戴尔，还是IBM x86服务器？
何小锋：我们用的是x86服务器，采用大厂商的服务器，如戴尔。网卡的话，目前新采购的都是万兆网卡，英特尔的比较多。
提问：你们的虚拟化用的是什么样的软件？是KVM吗？
何小锋：KVM已经被我们放弃了，我们就是基于容器。
提问：是在物理机上，是吗？
何小锋：对。
提示1：点击文末“阅读原文”链接，即可下载本演讲的PPT及实况录音。边听边看，岂不快哉？
提示2：更加精彩的GOPS全球运维大会·上海站即将于9月23-24日举行，约么?
get运维新技能，怎么总是抢先一步？
“置顶”高效运维公众号，第一时间看到相关好文章就可以啦！那怎么“置顶呢“？
请打开高效运维公众号，点击右上角小人，将“置顶公众号”滑到右边即可。
文/何小锋
文章来自高效运维微信公众号
本文链接：https://www.yunweipai.com/7035.html
网友评论comments