| 去年的双十一过后，InfoQ曾经采访过京东云平台首席架构师刘海锋。刘海锋，2013年加入京东，担任云平台首席架构师、系统技术部负责人，主持建设存储、中间件、弹性计算等私有云技术体系。
3月31日，在华为ICT巡展北京站的活动中，刘海锋分享了《京东基础云服务技术演进》。
基础云服务支撑着京东很多业务的发展。它可以分为三个层次，包括底层的存储服务，核心的中间件以及上层的弹性计算云，通过API以服务的形式支撑其他业务单元。下面我们分别来看一下。
存储系统面对的挑战与应对之道
存储是互联网公司最基础的东西。这也是开发团队花精力最多，持续迭代的一个技术方向。
挑战1：非结构化存储
京东每天有千万级的商家上传图片，用户浏览完图片后会产生交易订单，需要很多文本来描述这些订单。另外京东有自己的库房，任何一份订单经过拆分，经过库房的流转，每一分订单又会产生几十份非结构化的数据，涉及商品的入库、出库、调拨等。商品送到客户手中之后，还有签单信息、银行小票，未来这些信息的电子化、和银行对账，又是很多非结构化的数据。
非结构化的数据越来越多，如何存储这些数据？商家的图片、交易的订单、库房的记录、电子签收的信息，这些数据都是非常关键的，而且这些数据有一个特点，量比较大，但每份数据一般都比较小。
JFS:Jingdong Filesystem
京东针对非结构化数据开发了大规模分布式存储系统JFS（Jingdong Filesystem），支持BLOBs/files/blocks。现在这个系统已经到了3.0版本，可以统一管理小的对象、大的文件以及私有云中可持久化的块设备。
技术方面，因为数据不能丢失，所以从一开始就讲究强一致的复制，使用了Paxos复制；在存储引擎以及各种数据模型上采用了统一的存储管理；随着规模的增大，到了几PB数据的时候，采用了Reed-solomon码来降低存储成本；元数据的管理和Hadoop的集成方面，目前也有不错的进展和落地的应用。
目前该系统已经在支撑京东商城的如下服务：
图片服务
订单履约
物流数据交换
电子签收
内部云存储服务
虚拟机与容器卷存储
挑战2：越来越多的缓存
为保证快速响应，很多数据都会放到内存里，比如商品的价格，搜索推荐的结果等。越来越多的缓存，越来越多的大内存机器，不同的业务，如何管理它们也是很大的挑战。最早，很多小规模的公司可能会采用Memcached、Redis等，但当到了很大规模的时候，技术也会发生质变。
Jimdb：分布式缓存与高速NoSQL
Jimdb是京东研发的企业级NoSQL服务，能够统一做分布式的缓存，也能做高速的键值存储，完全兼容Redis的协议。与Redis相比，它有如下特性：
精确故障检测与自动切换
RAM/SSD混合存储
在线横向扩容
异步、同步、局部复制
全自动化接入与管理
其中“全自动化接入与管理”这一点是最近半年的主要工作，目的是降低维护成本。
Jimdb在京东部署了3000多台机器，都是大内存+固态硬盘的，支撑了京东的商品详情页、搜索、推荐、广告点击等很核心数据的快速访问。
下一代新存储平台
刘海锋的团队最近在做的事情是，更多考虑多数据中心的复制，让数据更加可靠，并且希望做统一的存储服务，实现One
Jingdong One Stroage，用一个系统抽象出文件、对象、表甚至缓存，能够在分布式的多个数据中心实现统一的复制存储底层的数据，在主IDC做缓存，甚至全量内存加速；向上支持在线服务、Hadoop，支持私有云内部的容器卷的管理等。
中间件：消息队列与SOA
底层存储的上面就是各种中间件。
挑战：越来越多的消息传递
京东跟很多互联网公司不一样的地方是，除了北京和江苏的核心机房，在全国各地还有很多商品的库房，每个库房会有几十台服务器，相当于一个小型的数据中心，消息队列不仅要串联核心机房里的业务，还要驱动库房里的订单生产环节，跟业务存在很强的依赖关系。从订单管道，到核心机房，再到仓储库房，普遍是用消息队列驱动业务流程的。日均消息数超过百亿。
JMQ：Jingdong Message Queues
面对业务挑战，京东的消息队列系统经过了三代演进，于去年双十一之前上线了JMQ并完成切换。
JMQ有如下特点：
机房断电不丢消息
因为库房的网络环境是不稳定的，所以必须保证不丢消息。
组提交技术
引入了数据库中经典的group commit技术，提高同步刷磁盘的写的性能。
透明压缩
灵活复制
挑战：越来越多的在线服务
电商系统内有很多服务。这些服务内部会互相调用，对外也要开放一些接口，供商家或者合作伙伴使用。
JSF：Jingdong Service Framework
京东在这方面的解决方案是JSF。可以做到运行时服务质量分析，提供了完善的服务治理功能。目前在京东已经接入了几万台服务器，更好地支持了内部的SOA化以及对外的服务开放。
弹性计算
弹性计算云是目前的主要工作。
挑战：越来越多的机器
任何一个高速发展的互联网公司，机器数量都是在成倍增加的。随着业务规模的增长，机器的数量也在不断增加。现在就要面对这样的场景：有很多数据中心，而每个数据中心内的机器又会被划分给不同的业务，比如有的机器处理交易，有的处理订单履约，有的处理搜索，有的处理图片等等，面对这么多机器，应该怎样管理，让研发团队的效率更高呢？
弹性计算云
该项目的愿景是在IDC的资源和业务系统之间建立一个桥梁，让业务与机器完全解耦，做到真正自动化维护，缩短产品开发到上线的流程，让工程师的精力更多放在产品的设计和研发上，而不必关注如何申请资源、如何上线；提高资源利用率和服务质量，让研发团队的生活更美好。
从公司整体来看，希望能够提高资源的利用率。因为很多机器是分散的，由各个业务团队使用，必然有很多机器是空闲的，统一管理必然能提高资源的利用率。
弹性计算云的整体架构如下图所示，分拆两层服务。底层是基础服务，实现软件定义数据中心。通过OpenStack和Docker的结合，实现容器化。JFS实现可靠的存储。上层是平台服务，希望通过集成部署，实现资源的统一分配，业务不用关注自己到底部署到哪台机器上，并由平台根据业务量实现自动伸缩。
现在这个系统已经在部分业务中落地，大规模落地会在今年年完成。具体而言，像商品详情页、图片系统，就是弹性计算云支撑的，用户的每一次浏览，都有这个系统在做贡献，能够按访问流量自动调度资源。在流量高峰的时候，这两个服务会自动扩容。
做为总结，刘海锋总结了两点：
1. 业务发展推动基础架构的演进；
2. 技术的关键是团队。 |
