京东 618：Docker 扛大旗，弹性伸缩成重点

不知不觉中，年中的 618 和年终的 11.11 已经成为中国电商的两大促销日，当然，这两天也是一年中系统访问压力最大的两天。对于京东而言，618 更是这一年中最大的一次考试，考点是系统的扩展性、稳定性、容灾能力、运维能力、紧急故障处理能力。弹性计算云是京东 2015 年研发部战略项目，它基于 Docker 简化了应用的部署和扩容，提高了系统的伸缩能力。目前京东的图片系统、单品页、频道页、风控系统、缓存、登录、团购、O2O、无线、拍拍等业务都已经运行在弹性计算云系统中。

过去的一段时间里，弹性计算云项目在京东内部获得了广泛应用，并且日趋稳定成熟。一方面，这个项目可以更有效地管理机器资源，提高资源利用率；另外还能大幅提高生产效率，让原来的申请机器上线扩容逐渐过渡到全自动维护。京东弹性计算云项目将深刻影响京东未来几年的基础架构。

受访嘉宾介绍

刘海锋，京东云平台首席架构师、系统技术部负责人。系统技术部专注于基础服务的自主研发与持续建设，包括分布式存储、以内存为中心的 NoSQL 服务、图片源站、内容分发网络、消息队列、内部 SOA 化、弹性计算云等核心系统，均大规模部署以支撑京东集团的众多业务。

InfoQ：能否介绍下京东弹性计算云项目的情况，你们什么时候开始使用 Docker 的？目前有多大的规模？

刘海锋：弹性计算云项目在去年第四季度开始研发，今年春节后正式启动推广应用。经过半年多的发展，逐渐做到了一定规模。截至 6 月 17 日，我们线上运行了 9853 个 Docker 实例（注：无任何夸大）以及几百个 KVM 虚拟机。京东主要的一些核心应用比如商品详情页、图片展现、秒杀、配送员订单详情等等都部署在弹性云中。弹性计算云项目也作为今年 618 的扩容与灾备资源池，这估计是国内甚至世界上最大规模的 Docker 应用之一。随着业务的发展以及 IDC 的增加，预计今年年底规模会翻两番，京东大部分应用程序都会通过容器技术来发布和管理。

系统架构可以这样简洁定义：弹性计算云 = 软件定义数据中心 + 容器集群调度。整个项目分成两层架构，底层为基础平台，系统名 JDOS，通过『OpenStack married with Docker』来实现基础设施资源的软件管理，Docker 取代 VM 成为一等公民，但这个系统目标是统一生产物理机、虚拟机与轻量容器；上层为应用平台，系统名 CAP，集成部署监控日志等工具链，实现『无需申请服务器，直接上线』，并进行业务特定的、数据驱动的容器集群调度与弹性伸缩。

InfoQ：能否谈谈你们的 Docker 使用场景？在 618 这样的大促中，Docker 这样的容器有什么优势？618 中有哪些业务跑到 Docker 中？

刘海锋：目前主要有两类场景：无状态的应用程序，和缓存实例。这两类场景规模最大也最有收益。不同的场景具体需求不同，因此技术方案也不相同。内部我们称呼为“胖容器”与“瘦容器”技术。从资源抽象角度，前者带独立 IP 以及基础工具链如同一台主机，后者可以理解为物理机上面直接启动 cgroup 做资源控制加上镜像机制。

618 这样的大促备战，弹性计算云具备很多优势：非常便捷的上线部署、半自动或全自动的扩容。Docker 这样的操作系统级虚拟化技术，启动速度快，资源消耗低，非常适合私有云建设。

今年 618，是京东弹性计算云第一次大促亮相，支持了有很多业务的流量。比如图片展现 80% 流量、单品页 50% 流量、秒杀风控 85% 流量、虚拟风控 50% 流量，还有三级列表页、频道页、团购页、手机订单详情、配送员主页等等，还有全球购、O2O 等新业务。特别是，今年 618 作战指挥室大屏监控系统都是部署在弹性云上的。

InfoQ：你们是如何结合 Docker 和 OpenStack 的？网络问题是如何解决的？

刘海锋：我们深度定制 OpenStack，持续维护自己的分支，称之为 JDOS（the Jingdong Datacenter Operating System）。JDOS 目标很明确：统一管理和分配 Docker、VM、Bare Metal，保证稳定高性能。网络方面不玩复杂的，线上生产环境划分 VLANs + Open vSwitch。SDN 目前没有显著需求所以暂不投入应用。我们以『研以致用』为原则来指导技术选择和开发投入。

InfoQ：能否谈谈你们目前基于 Docker 的 workflow？

刘海锋：弹性计算平台集成了京东研发的统一工作平台（编译测试打包上线审批等）、自动部署、统一监控、统一日志、负载均衡、数据库授权，实现了应用一键部署，并且全流程处理应用接入，扩容、缩容、下线等操作。支持半自动与全自动。

InfoQ：这么多的容器，你们是如何调度的？

刘海锋：容器的调度由自主研发的 CAP（Cloud Application Platform）来控制，并会根据应用配置的策略来进行调度；在创建容器的时候，会根据规格、镜像、机房和交换机等策略来进行创建；创建完容器后，又会根据数据库策略、负载策略、监控策略等来进行注册；在弹性调度中，除了根据容器的资源情况，如 CPU 和连接数，还会接合应用的 TPS 性能等等来综合考虑，进行弹性伸缩。

目前已经针对两大类在线应用实现自动弹性调度，一是 Web 类应用，二是接入内部 SOA 框架的服务程序。大规模容器的自动化智能调度，我们仍在进一步做研究与开发。

InfoQ：目前主要有哪些业务使用了 Docker？业务的选择方面有什么建议？

刘海锋：目前有 1000 个应用已经接入弹性云，涵盖京东各个业务线，包括很多核心应用。目前我们主要支持计算类业务，存储类应用主要应用到了缓存。数据库云服务也将通过 Docker 进行部署和管理。

特别强调的是，业务场景不同，技术方案就有差别。另外，有些对隔离和安全比较敏感的业务就分配 VM。技术无所谓优劣和新旧，技术以解决问题和创造业务价值为目的。

InfoQ：你们的缓存组件也跑在 Docker 中，这样做有什么好处？IO 什么的没有问题吗？有什么好的经验可以分享？

刘海锋：我们团队负责一个系统叫 JIMDB，京东统一的缓存与高速 NoSQL 服务，兼容 Redis 协议，后台保证高可用与横向扩展。系统规模增长到现在的三千多台大内存机器，日常的部署操作、版本管理成为最大痛点。通过引入 Docker，一键完成容器环境的缓存集群的全自动化搭建，大幅提升了系统运维效率。

技术上，缓存容器化的平台并不基于 OpenStack，而是基于 JIMDB 自身逻辑来开发。具体说来，系统会根据需求所描述的容量、副本数、机房、机架、权限等约束创建缓存容器集群，并同时在配置中心注册集群相关元数据描述信息，通过邮件形式向运维人员发出构建流水详单，并通知用户集群环境构建完成。调度方面，不仅会考虑容器内进程，容器所在机器以及容器本身当前的实时状况，还会对它们的历史状况进行考察。一旦缓存实例触发内存过大流量过高等扩容条件，系统会立即执行扩容任务创建新的容器分摊容量和流量，为保证服务质量，缓存实例只有在过去一段时间指标要求持续保持低位的情况下才会缩容。在弹性伸缩的过程中，会采用 Linux TC 相关技术保证缓存数据迁移速度。

InfoQ：使用过程中有哪些坑？你们有做哪些重点改进？

刘海锋：坑太多了，包括软件、硬件、操作系统内核、业务使用方式等等。底层关键改进印象中有两个方面：第一，Docker 本地存储结构，抛弃 Device Mapper、AUTFS 等选项，自行定制；第二，优化 Open vSwitch 性能。比如，优化 Docker 镜像结构，加入多层合并、压缩、分层 tag 等技术，并采用镜像预分发技术，可以做到秒级创建容器实例；优化 Open vSwitch 转发层，显著提升网络小包延迟。