Cloud Native 26 min read

How JD Scaled to 100,000 Docker Containers: Lessons in Cloud‑Native Operations

This article details JD.com's journey from physical servers to a massive Docker‑based cloud‑native platform, covering challenges, architecture, elastic scheduling, monitoring, and resource‑driven operations that support tens of thousands of containers across multiple data centers.

Efficient Ops
Efficient Ops
Efficient Ops
How JD Scaled to 100,000 Docker Containers: Lessons in Cloud‑Native Operations
何小锋 拥有18年的研发经验,喜欢技术,追求卓越。 2011年加入京东,担任两届架构委员会常委,负责百亿级分布式消息系统。2014年下半年开始负责基于Docker的弹性技术平台,推动全业务系统迁移到容器上。 在京东期间支持多次618和双11大促,积累了弹性计算、中间件、存储和大并发分布式系统的实践经验。

正文

大家好,我是来自京东的何小锋,今天我跟大家分享一下 《京东Docker的实践经验》 。

1、京东容器之路

1.1 面临的挑战

京东为什么要使用Docker?随着业务发展,传统基于物理机的部署面临硬件采购周期长、资源使用不透明、成本高、扩容慢等挑战。

在双11或6·18前的压力评估需要快速扩容,采用物理机需要一个月时间,效率极低。

1.2 用户关注

用户更关注系统的稳定性和性能,而不是底层是物理机还是容器。对性能敏感的业务必须保证容器不会带来性能损失。

1.3 容器化之路

2013年最初使用KVM虚拟化,性能不足。2014年四季度开始在京东图片系统试点容器,取得良好性能并实现弹性伸缩。

2015年第一季度弹性平台上线,6·18期间在生产环境使用约1万个容器,后续新机房全部采用容器建设,容器规模已达约10万。

1.4 选择Docker的原因

Docker 轻量、性能好、部署快、稳定性高,且对安全性要求不高,适合京东私有云环境。

2、弹性计算架构

京东私有云采用开源与自研相结合的架构,底层使用 OpenStack、Docker、OVS 等,存储使用京东自研的分布式存储系统。

上层使用自研的 CAP 调度系统,实现应用治理、弹性调度和监控。

2.1 OpenStack

在 Docker 之上使用 OpenStack 进行集群管理,利用其成熟生态和京东已有的公有云经验。

2.2 网络

采用 OVS/VLAN 模式,优化网络延迟,实现约20% 性能提升。每个容器分配独立 IP,保持用户习惯。

2.3 存储

使用京东自研的分布式块存储 JFS 以及本地存储满足日志需求,日志先写入本地再同步到分布式系统,确保容器故障后仍可恢复。

2.4 镜像分层合并

镜像采用 OS 层、基础层、应用层三层结构,将频繁变更的应用层做小镜像,降低存储压力。

2.5 镜像中心

严格的项目管控机制确保镜像在不同环境(开发、测试、预发布、生产)之间隔离,使用 JFS 作为镜像存储。

2.6 配置中心

构建配置中心,容器启动时自动拉取对应环境配置,实现一次镜像多环境部署。

2.7 调度系统

自研调度系统类似工作流引擎,支持动态服务发现、弹性扩容、故障迁移、弹性收缩等流程。

2.8 弹性扩容流程

弹性扩容先评估资源需求,创建容器并授权,完成监控、日志注册后再接入流量,实现完整的扩容闭环。

2.9 故障迁移流程

检测到容器故障后,先摘流量,创建新容器部署应用并注册,保持容器 IP 不变,减少授权操作。

2.10 弹性调度算法

调度算法综合考虑业务重要性、资源需求、机房位置等因素,结合京东微服务框架的性能数据,实现基于应用分组的弹性调度。

3、弹性计算应用场景

核心业务几乎全部迁移到容器,包括 Nginx、微服务框架、Oracle、Redis、MySQL 等,容器规模已达十万级。

4、自动化运维

4.1 系统监控指标

容器监控采集系统负载、网络流入/流出等指标,数据存储在基于 HBase 的 OpenTSDB 中,支持实时计算和资源预测。

4.2 监控页面

提供容器级和应用级监控视图,可从 CPU、网络、磁盘等多维度评估。

4.3 报警策略

支持邮件、短信等实时报警,已与京东用户体系打通。

4.4 一键水平扩容

实现快速水平扩容,避免传统物理机部署的繁琐。

4.5 一键垂直扩容

支持内存、CPU 等资源的垂直扩容,若本机资源不足则迁移到其他机器。

4.6 宕机探测架构

在每个机房部署多点检测程序,若多数检测点认定容器宕机,则触发故障迁移。

4.7 硬件故障探测

通过协议监控物理机硬件报警信息,实现自动故障检测和通知。

4.8 故障通知

硬件故障检测后立即通知相关人员进行处理。

4.9 应用部署巡检

对跨机房部署进行巡检,确保资源均衡,防止单机房或单交换机过载。

5、数据驱动的精细化运营

5.1 资源利用率

按小时统计容器资源使用率,进而计算应用和部门的资源使用率,实现精细化资源控制。

5.2 容器资源利用率

通过容器使用率分析,为新应用提供容量评估和负载预测。

5.3 部门资源利用率

部门资源使用率作为考核依据,帮助评估资源申请与实际使用情况。

5.4 资源剩余情况

监控剩余资源,为硬件采购提供建议。

5.5 配额管理

对一、二级部门进行资源配额隔离,确保关键系统资源得到保障。

6、实践经验

无状态、磁盘IO要求不高的应用适合弹性云。

微服务因自动服务注册发现而适合弹性云。

推荐万兆网络和网卡,避免资源竞争。

选择稳定的操作系统版本,防止内核Bug导致灾难。

高配置物理机与合理的CPU/内存比例有助于资源充分利用。

采购高质量交换机和物理机,确保系统稳定。

Q&A

提问:现在容器的规模已达十万,监控数据如何处理和保存?

何小锋:我们使用基于 HBase 的 OpenTSDB,将所有监控数据持久化在大数据集群中,数据不会删除,可用于资源分析和预测。

提问:MySQL 是否适合部署在容器中?

何小锋:核心业务的 MySQL 仍在物理机上,IO 要求高的场景不适合容器。对 IO 要求不高的业务,我们提供云数据库方案,实现资源隔离。

提问:容器出现问题时,数据会不会丢失?

何小锋:MySQL 采用主从复制,高可用方案保证数据不丢失,容器故障时可切换。

提问:OpenTSDB 只支持数值型数据,字符型如何处理?

何小锋:我们目前只存储数值型数据。

提问:日志服务的技术实现是什么?

何小锋:我们有专门的日志平台,容器启动后将日志推送到平台,实时采集并提供检索。

提问:高 IO 场景下容器的性能如何?

何小锋:大量容器共享 IO 会产生竞争,核心业务对 IO 要求高时会采用专用资源。

提问:推荐的服务器和网卡配置是什么?

何小锋:使用 x86 服务器,主要厂商如戴尔,网卡采用万兆 Intel。

提问:虚拟化软件使用的是什么?

何小锋:已放弃 KVM,直接基于容器。
monitoringCloud NativeDockeroperationsresource managementelastic scheduling
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.