京东 11.11:电商狂欢背后的云基础设施服务

  • 臧秀涛

2014 年 11 月 11 日

话题:架构云计算DevOps语言 & 开发

每年的 11.11 促销,都是对几大电商的软硬件平台服务能力的一次大考。在系统升级改造的过程中,京东商城引入了自己的云平台,将交易、订单、仓储、搜索等核心系统需要的一些基础设施抽象了出来,以服务的形式提供。面对峰值负载,很多压力都会传导到底层的云设施。京东的云平台是如何准备来应对云存储的呢?为此 InfoQ 采访了京东商城技术研发体系云平台首席架构师刘海峰。他负责的是包括存储、缓存和消息队列在内的基础系统,还有服务框架。

稳定的云平台

刘海峰首先介绍了发展历史,过去两年,京东以自主研发为主,开发了适合自己业务模式的存储系统——京东文件系统(JFS),并基于 JFS 向外提供私有云存储服务。最大的一个客户就是图片存储,京东的每一张图片都存在 JFS 平台上,另外还有订单、库房的报文等。自主研发使得系统更加可控,其可靠性、稳定性,都能很好地把握。JFS 采用了主动复制策略,保证绝对的强一致性,通过自己设计的复制算法,能够保证在机器故障、磁盘故障、甚至文件删除等问题存在时,数据都不会丢失。

缓存云也是云平台的核心产品之一。可以分为两个方面,一是纯缓存,为各个业务提供统一的缓存服务。如果电商的各个业务都自己设计和维护一套缓存,成本会非常高。而将全集团的缓存统一管理,通过细粒度的混合部署,完全弹性的、多租户的管理,实现弹性伸缩,极大地提高机器的使用效率,节省成本。

另一个是 Jimdb——基于内存与 SSD 的分布式缓存与高速 KV 存储服务,这在搜索系统、推荐系统等中都有应用。

可靠的消息队列

消息队列(MQ),或者叫消息平台,随着互联网业务的发展,微服务这种形式越来越流行,也就是一个模块做一件事情,模块之间尽量松耦合,模块之间用消息队列串联起来。可以认为消息队列是数据中心里面,各业务系统之间的管道。在京东,消息队列的开发经历了三个阶段。前两代是基于开源软件实现的,现在的产品是完全自主研发的 JMQ,在 11.11 之前已全面上线。商品相关的队列和订单相关的队列都依赖此服务,MQ 如果出现问题,会导致订单等购物行为出现故障。不过 11.11 目前运行比较平稳,能够做到消息绝对不丢失。

MQ 有一个很大的技术挑战,要能够快速地收,可靠地存。如果下游的消息消费者处理比较慢,系统就需要能够缓存大量消息。因为自己开发,这里可以做很多优化。举例而言,有的大队列可能是 1 个发送者,有 100 个消费者,很多开源系统可能会存 100 份。但这里通过优化,可以只存一份,消费者可以通过偏移量或指针去访问。从今天的效果来看,在这个方向上的技术投入非常值得。

微服务之得失

在服务框架方面,进行了微服务化改造。一个模块就做一件事,各个模块可降级、可监控、可分解。除了通过消息队列串联不同模块,还有些地方需要同步调用,京东大概有上万个服务接口,也接入了非常多的服务器,整个服务的注册、发现、互相之间的服务调用,再就是请求的序列化、反序列化,都是通过自主研发的服务框架实现的。

提到微服务,刘海峰也深入介绍了一些自己在这方面的感悟。他认为,微服务对互联网而言是很好的技术方向,对电商也是如此。将系统分为不同的服务模块,系统的韧性会更好,当然有得必有失。这种架构对基础设施的要求会更高,对软件底层平台的要求也更高。因为模块之间的通信有不同方式,比如通过直接调用、消息队列或存储系统,那如何跟踪系统的服务链条,也是一个问题。测试整个系统的峰值性能,抗压能力,也是个很大的挑战。

充分的 11.11备战

谈到 11.11 的备战,刘海峰介绍说,首先一点就是需要把更多的工作放在平时,实际上技术是瓶颈,不是靠堆机器就能解决的,所以要靠平时的积累,设计好、做出好的系统。另外,在出现问题时,团队更加重要,要确保及时响应;而这时候也越来越体会到自主研发的好处,有任何问题,都可以快速地定位并修复,甚至是直接线上修复。只有从零写起才有这种感觉。

我们也谈到了京东云的路线图问题。刘海峰提到,目前还是小步快跑的模式,先抓住一些重点业务,应用起云服务,形成示范效应,再快速地规模化。京东也正在开发一个数据中心操作系统项目——JDOS,基本的事情是统一管理包含物理机、虚拟机和轻量级容器,配合自主研发的存储以及非常灵活的 SDN 互联。

InfoQ 后续还将发布对京东的运维、订单、仓储、搜索等业务负责人的访谈,敬请期待。

如果读者对京东云之前的演进情况感兴趣,可以查看刘海峰在 QCon 北京 2013 上的演讲:《京东文件系统与统一数据中心存储》。

架构云计算DevOps语言 & 开发