在2015年的618大促中,京东大胆启用了基于Docker的容器技术来承载大促的关键业务(图片展现、单品页、团购页),当时基于Docker容器的弹性云项目已经有近万个Docker容器在线上环境运行,并且经受住了大流量的考验。而今年618,弹性云项目更是担当重任,所有的核心业务均已经跑在Docker上,包括商品页面、用户订单、用户搜索、缓存、数据库。像618大促这样的流量高峰期,弹性云可以自动管理资源,做到弹性扩展,而在流量低谷期,又可以进行资源回收,在提升资源利用率的同时确保了运维系统的稳定性。据官方估计,本次大促活动中,京东线上将会启动近20万个Docker容器,从数量上来看,京东是全球范围内Docker的应用大户之一。
为了了解相关的详情,InfoQ记者采访了弹性云项目负责人鲍永成。此外,鲍永成将会在InfoQ主办的 CNUTCon全球容器技术大会 上分享本次618大促的具体技术细节,欢迎关注。
鲍永成,京东弹性计算组项目负责人,带领弹性计算团队,深耕IaaS领域,致力于打造京东强大的虚拟化平台。2013年初加入京东,重点在京东弹性云平台系统研发,运营多个中大规模IaaS集群,包括(京东弹性云、公有云、混合云等产品),在OpenStack研发&性能优化、自动化部署、KVM、Docker、分布式系统等方面有一定的实践经验。
鲍永成:从数量上来讲,去年618线上容器应对峰值为9853个实例,今年截止6月17日线上容器突破208220实例;在整体布局上来看,对比去年618,弹性云在规模上和业务全容器化实现战略落地。
在应用层面,京东所有应用100%通过容器技术来发布和管理应用集群。值得指出一点:今年618有9879个容器实例支撑DB集群,对京东云数据库提供非常便利的支持。
弹性云核心架构没有很大变化,依然简洁定义:弹性云=软件定义数据中心+业务容器集群调度。在此基础上,有两点增强:
鲍永成 : 网站、交易、无线、微信手Q、数据库等全部核心和非核心业务都跑在Docker上。
因为京东业务在多年前就开始微服务化治理,所以应用层架构调整很小。现如今微服务化比例已经很大,所以容器技术的融入比较顺利。弹性云平台,算是站在多年对各个业务系统微服务化治理的巨人肩膀上。
鲍永成 : 监控采取自主研发系统,该系统负责海量数据采集和存储工作,其构架如图。
对于20W+容器监控,需要注意:指标采集传输一定要设计得非常高效,并且要做到采集过程对资源的消耗控制,建议使用加速告警和监控图表跟踪缓存状况。
鲍永成 : 弹性云有两种模式:
鲍永成 :
鲍永成 :
1. 集群规模 : 介于高效运维,弹性云集群走的是大集群架构的思路。单个OpenStack集群会建设得非常大,目前单集群规模控制在6千台计算节点左右。
管理6K台计算节点集群,仅仅使用原生OpenStack是很困难的,因此我们对OpenStack依赖的数据库、MQ等全部重新设计实现,设计经过测试可以支撑1W台计算节点。
2. 单实例性能调优 : 很多核心的业务对单个请求的响应时间有极其严格要求,这势必要求弹性云提供的每一个容器实例均要具有极好的性能,我们从CPU和网络两方面入手。
针对CPU,我们采取Scale-up算法灵活调配CPU分配,使繁忙业务可以及时获得足够多CPU资源。
在网络这块,主攻方向为如何把万兆卡的性能发挥出来。我们对OVS(Open vSwitch)做了一些改进:减少了一些锁,优化peer port和网卡中断。这带来近乎物理机网卡的网络性能。
鲍永成 :
收益 :
京东弹性计算云通过软件定义数据中心与大规模容器集群调度,实现海量计算资源的统一管理,并满足性能与效率方面的需求。
提升业务自助上线效率。
应用部署密度大幅提升,资源使用率提升,节约大量的硬件资源。
面临一些规模性挑战 :
内核因为bug升级;全部容器化后,底层依赖系统的版本高度一致,很容易带来因为底层bug需要规模性升级,幸运的是我们在内核团队建设这块一直非常重视,已经有内核发布版本、内核热patch等方式,有效解决此类问题。
鲍永成 : 重点分享软件定义数据中心、大规模容器集群调度以及Docker容器性能调优。
感谢郭蕾对本文的审校。