扛过618全部流量，京东15万Docker集群如何炼成

Posted 2021-04-24 GitChat精品课

从1万Docker到15万，从试水部分应用到承担全部流量，京东弹性云团队用了1年的时间，为2016年618大考交上了新的答卷。Docker化的技术细节，京东技术团队是如何实现的呢？日前，京东云中间件首席架构师何小锋接受CSDN记者专访，介绍了基于Docker的京东弹性云构建、优化和规模化推广始末、备战618的相关举措，以及Docker部署和迁移心得。

何小锋介绍，基于Docker 的弹性云能够简化应用部署和扩容，提升系统伸缩能力，保障618高并发流量下的系统稳定性，同时及时采集容器的指标，对应用的负载进行评估预测，有助于自动化运维和精细化管理。在Docker化的尝试过程中，京东先进行局部尝试、验证，再进行大规模推广，优先迁移计算类应用、无状态应用，在不影响业务的情况下平滑迁移。何小锋认为，可以使用成熟的方案替换Docker里面的新特性以保证系统稳定性，并集成公司的基础设施和应用治理、监控报警等功能，才能完整实施企业解决方案。

嘉宾简介

何小锋，京东云中间件首席架构师，拥有18年的研发经验，2011年加入京东，担任了京东两届架构委员会常委。目前负责京东云中间件部，包括缓存平台、消息平台、微服务框架、弹性云等产品。

CSDN：能否介绍下京东的弹性云平台？

何小锋：京东弹性云是京东标志性的战略研发项目，它基于Docker（容器）简化了应用的部署和扩容，提高了系统的伸缩能力；京东目前拥有容器数量超过15万，已经成为全球最大规模Docker集群之一，有力地保障了整个运维系统的平稳运行；而京东的数据中心现在布局华北、华东、华南三大地区，多中心模式有力支撑了京东的所有业务，将为整个系统提供更加强大的承载力。

经受住了2015年618和双11大流量的考验后，2016年双活的数据中心已经全部采用弹性云进行建设，同时今年618流量全部落到弹性云上。京东弹性云通过云计算将用户的流量均匀分散到弹性云的高性能节点，优化微服务来驱动订单的生产。京东弹性云会根据历史数据的计算进行资源预估和储备，实现自动化运维和精细化管理。而像618大促这样的流量高峰期，弹性云会自动补充资源，做到弹性扩展，在流量低谷期，又可以进行资源回收，从而将资源灵活地调度起来，在提升资源利用率的同时确保了运维系统的稳定性。

CSDN：618流量高峰是平时的多少倍？面对比平时高很多的流量高峰，弹性云平台做了哪些准备？

何小锋：对于618流量高峰，我们做了如下准备：

1.     按照平时的10倍进行的预估，并提前做了资源扩容，准备了足够的资源池，配合业务方进行压测演练。

2.     为了确保系统的稳定性，我们启动了弹性云双机房容灾项目，如果其中一个机房出现问题，系统将自动把流量切换到另一个机房，实现跨机房的容灾，保证无论在何种情况下，都能让数据迅速恢复，让应用系统的容灾能力得到极大的保障。

3.     我们每天都对物理机、网络、容器和应用部署进行巡检，确保应用部署跨机架部署均匀，每个机房都能抗住100%的流量。

4.     我们建立了一个非常成熟的监控体系，可以面向容器级别进行监控，能够准确了解每个容器的问题，并及时收到报警，为京东应用系统应对突发情况增加了一层有效的防护。

CSDN：京东弹性云平台整体是基于Docker来打造的，你们选择Docker之前做了哪些评估和测试？

何小锋：京东弹性云首先应用于京东私有云上，在选择Docker之前，我们尝试了KVM虚拟化方案，各方反馈性能不够好，无法满足大促的需求。在2014年底，我们决定采用Docker容器化方案，基于Docker镜像的方式进行发布，其快速的弹性伸缩能力适合京东大规模生产需求，并且其具备轻量、高性能和便捷性的优势。我们首先使用京东图片系统来验证其性能和弹性伸缩能力，之后再逐步推广到如单品页这样的核心系统，并进行网络的优化，以满足京东应用的性能。应用中我们采用和物理机混合部署的模式，经过2015年618和双11大流量的考验，验证了Docker的稳定性。所以到2016年的618大促，我们才有信心使用Docker来抗100%流量。

CSDN：从落地到大规模推广Docker的过程中遇到哪些阻力，如何解决的？

何小锋：在部署中，我们首先要确保弹性云足够的稳定之后，才能将核心应用迁移上来。通过弹性云的培训，让用户对Docker容器有了足够的了解，我们也采用了物理机和弹性云混合部署，通过长时间的运行指标，并且经历了618和双11大流量考验之后，更给用户树立了信心。

另外最重要的是要满足性能的需求，确保大促不受影响。我们对用户反馈的性能问题逐步优化，通过优化网络，简化模型，提升网络性能，解决应用刷日志问题的方式作出了改善。

最后还要满足用户习惯，便于推广。每个容器都有独立的IP，用户可以SSH登陆上去操作；同时用户也可以集成现有的基础设施系统，通过自动部署、统一日志、统一监控、HA等等；在应用中还可以采集丰富的监控指标，让用户感觉和物理机操作是一样的。此外，日志保留到本地物理机磁盘上，更确保了用户检索日志的需求。

CSDN：能否详细介绍京东弹性云的架构？据了解你们是基于开源和自研相结合的架构，这是基于哪些考虑？

何小锋：京东云的基础平台（JDOS）能够实现基础设施，包括网络，物理机和存储的资源管理、容器的生命周期管理以及监控指标采集。

京东云的应用平台（CAP）则负责应用治理、部署、监控报警、资源利用率统计以及手动和自动的弹性伸缩。

我们采用开源主要是为了提高效率，因为目前业界已经有相应的成熟方案，可以直接使用，以加快交付效率。另外一点，也是为了满足京东的应用场景，集成京东的基础设施，实现在开源的基础上进行了改造或者自主研发。

CSDN：大规模/跨数据中心集群的存储、网络问题是如何解决的？

何小锋：我们的方案包括：

•     京东研发的京东文件系统（JFS），提供对象存储和块存储，实现跨数据中心的复制。

•     京东研发的mysql云数据库，支持跨数据中心的复制。

•     京东研发的JIMDB，兼容Redis协议，实现跨数据中心的复制。

•     京东研发的HBase集群，支持跨数据中心的复制。

•     网络采用OVS/VLAN模式，为私有云简化了模型，跨网段访问通过物理交换机实现。

CSDN：服务之间的调度是如何实现的？针对618的规模挑战与效率挑战的矛盾如何取舍？

何小锋：弹性云集成了京东很多基础设施，例如部署、数据库授权、负载均衡等等。并且我们已经通过自主研发的CAP来实现面向应用的调度，同时容器的创建、销毁过程，也都是基于任务和状态机来实现。

我们的任务调度框架基于Zookeeper和状态机来实现，这样便于动态扩容。通过各个节点向Zookeeper注册，并由选举出的Leader负责在数据库中扫描出待执行的任务，根据当前存活的任务节点和负载均衡算法，派发到各个节点执行。任务执行完毕后，更改状态为最终状态。如果任务失败，可以设置下次重试时间进行重试。同时为了避免冲突，相同资源之间的调度也做了支持互斥的处理。

CAP会实时计算应用的资源利用率，预测是否要进行扩容，如果需要，就会生成扩容申请，并分解成各个任务，由内部的编排进行任务的调度。

正如之前提到的，为了应对618大流量的考验，我们提前进行了大规模的扩容，做好了充分的准备。

CSDN：你们对Docker做了哪些优化？你认为Docker在生产环境下，还需要哪些改进？

何小锋：为了在京东生产环境下使用，我们做了如下改进：

•     优化了Docker dameon，便于升级；

•     另外在镜像存储上还使用了京东自研的JFS；

•     放弃了Docker的网络模型，改用更成熟稳定的OVS；

•     日志主要通过卷输出到物理机上；

•     完善了监控数据的采集；

•     Docker本身不带调度和弹性伸缩的功能，需要根据应用场景研发弹性调度功能。

CSDN：采用容器技术对自动化运维和精细化运营有哪些帮助？

何小锋：在采用容器后，用户能够实现快速的应用部署，提升交付效率。以前应用采用物理机方式部署，部署较慢，需要各处申请权限、配置HA。现在这些都可以交给弹性云来做到一键部署。

在部署之前，我们不能准确掌握系统的整体压力，也无法及时响应应用的扩容。但在采用弹性云之后，我们能够及时采集容器的指标，对应用的负载进行评估预测，并进行自动的弹性的伸缩；另外，我们也可以提前手动一键扩容来满足秒杀等特殊场景的需求。

弹性云能够及时采集物理机、容器的指标，根据报警策略进行报警，同时也能对出现故障的实例快速进行迁移。

通过采集的指标，可以实时计算出容器的资源利用率，同时也可以计算出应用和部门的加权平均资源利用率，这样便于资源的统一调配。

CSDN：通过你们的实践，能否给正在考察Docker的团队一些建议？

何小锋： Docker是比较新的技术，经过京东的大规模生产实践，证明以Docker为核心的系统可以做到非常稳定、高效。为了确保系统的稳定性，我们建议使用成熟的方案替换Docker里面的新特性。此外，我们还建议必须集成公司的基础设施和应用治理、监控报警等功能，才能完整实施企业解决方案。

CSDN：在进行云迁移的云考量因素有应用、数据库、文件等，能否详细介绍其中的注意事项？

何小锋：京东把应用迁移到弹性云，考虑了如下几点：

•     计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。

•     应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。

•     应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。

•     在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。

•     容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。

•     修改底层，让应用在运行时能准确地拿到自身容器的核数。

CSDN：未来实现全局流量调度的挑战有哪些规划？

何小锋：在全局流量的调度中，实现快速地进行流量切换和故障迁移有三要素：要把流量调度到最近的机房；要让每个机房的流量和应用的部署实现均衡；要让每个容器的流量和自身的规格均衡。

在应用中，我们的策略包括：

•     根据入口流量和应用历史指标，设计数据模型，准确的评估大促各个应用需要准备的资源，并进行自动化的扩容，以减少备战工作量。

•     结合Kubernetes进行更精细化的调度，以镜像方式发布推广，更加快速调度流程。

•     最大程度地降低日志对磁盘IO的影响，日志直接通过网络采集，只有网络故障的时候才落到本地。

•     把各个Agent从应用镜像里面移除，采用统一的容器来管理系统的Agent，便于升级，降低对系统负载的影响。

•     总而言之，就是提高资源利用率，在空闲时段，能把计算资源提供给大数据计算。

CSDN：未来把弹性云、缓存云输出到公有云平台，还需要解决什么问题？

何小锋：弹性云和缓存云输出到公有云平台，首先需要解决租户隔离、网络安全等问题。这些在私有云场景是不需要解决的。另外依赖的京东私有云的基础设施系统，如中间件和监控报警等，在公有云上也需要相应的解决方案。