专访京东架构师：海量数据的IT架构演变

最近前有支付宝电缆被挖断，后有携程网瘫痪、股市还暴跌320点，有网友感叹说，在这个世界里，再牛的互联网公司，都干不过蓝翔技校的挖掘机……”“什么互联网＋，什么4.0，什么大数据”，都顶不住传统行业一铲子，听起来让人倍感悲凉，可该网购的还得网购，话说京东也即将迎来618促销大战了，怎么顺利迎战呢？京东在电子商务市场深耕多年了，终于挤进了全球PB级数据管理俱乐部，与Facebook、淘宝并驾齐驱。面对如此海量级别的图片数据，京东又该如何应对呢？本期IT名人堂皮皮邀请到了京东商城资深架构师桂创华(社区ID：uu6088)坐镇，欢迎大家回帖与专家互动。


皮皮（Q1）：您好！很高兴有机会采访到您！有人觉得架构师是个很高大上的职业，从微软到现任京东资深架构师，您的职业生涯经历了哪些转变？您觉得作为一名架构师，需要具备哪些能力？
桂创华（A1）：大家好，我是在2010年加入微软，那时候刚从学校出来，用现在流行一点的话说，还是一个标准的小鲜肉。记得刚加入的时候，微软已经有了很成熟的体系架构，我们可以充分享受各种基础软件带来的便利，会把更多的精力投入到一些工具和算法的研究上，从而提升用户的搜索体验和准确率。来京东后，我做的事情更底层一些，近两年来一直在做京东自主研发的分布式存储平台JFS，支撑了京东大大小小几百个业务数据的存储。

个人觉得，架构师说到底，也就是工作经验更为丰富一些的码农了。我觉得好的架构师首先要有丰富的理论知识，并能够将之付诸实践。此外，架构师还要有前瞻性，对业内前沿技术有较深的了解，能做到有的放矢选择方案。

皮皮（Q2）：企业的IT架构不是一层不变的，随着业务的发展，应用服务器（比如网站、后台、邮件等）、数据库和反向代理、计算集群（文件存储、图片）等都会面临着新的挑战，能不能和我们谈谈京东商城的IT架构，尤其是从传统数据处理到大数据处理过程中，京东商城的IT架构是如何演变的？

桂创华（A2）：这个问题很大。总体来讲，京东的技术架构也是经过了几代的发展，最初的时候，为了支撑京东早期的快速发展，京东技术架构开始从集中式系统向简单分布式系统演化。而到了2009年，为了支撑百万到千万级的订单量增长，京东技术架构进入了SOA化阶段。四年以后，随着业务快速发展，京东技术迈入了云和大数据时代，于是乎催生了我们自主研发的京东分布式文件系统JFS，JFS的集群规模超过千台，存储了PB级别的数据；企业级NoSQL服务JIMDB，服务了公司上千个业务；消息队列系统JMQ，日均消费消息过百亿；私有云服务JDOS，托管调度了公司的各类业务；基于SOA的服务治理平台JSF等等。

皮皮（Q3）：数据库市场近年来群雄逐鹿，异军突起。有Oracle为代表的传统的关系型数据库，也有大数据时代下红极一时的NoSQL数据比如MongoDB与Redis，还有在SQL与NoSQL之间游离需求平衡的NewSQL数据库。京东商城用到的数据库是什么？
桂创华（A3）：根据业务不同的需求，我们都有在用，结构化数据存储主要以Mysql为主。NoSQL最初很多业务在用Redis，但随着规模的持续增长，在使用过程中出现了不少痛点，即使是非促销日，京东的订单数字也能达到数亿，几十亿商品图片及其缩略图的存储给京东带来了极大的挑战。此前，京东一直是采用HDFS作为数据存储子系统，但是专为大文件而设计的HDFS显然无法有效处理大量小文件，同时还对hadoop的扩展性和性能造成了不良影响。

　　针对电商业务中海量小文件、大文件等数据分布式存储与管理的实际需求，京东从2013年7月便开始着手自主研发分布式文件系统JFS(即Jingdong Filesystem)，以及分布式的缓存与高速键值存储服务JIMDB，目前已经取得了阶段性的成果，JIMDB集群达到了千台以上，支持了公司的上千个业务。

皮皮（Q4）：传统的关系型数据库价格昂贵，没法按需扩容，只能定期删除数据，很麻烦。开源存储系统虽然便宜，但难以选型、定制和维护。坐拥几亿级数据的京东，面对几十亿商品图片所带来的存储压力，该如何应对？
桂创华（A4）：对，其实不仅仅是图片，还有商品订单、库存记录等等，这些数据有几个特点：第一、单条记录都不大，几k到几十k字节。第二、总量大，比如库房记录、商品订单等等，每天就可能产生数千万条。第三、在线数据为主，要求提供实时在线大并发访问。最初，各个业务使用的也不尽相同，有些使用结构化存储，有些则使用一些开源的文件系统。但随着京东业务的飞速发展，数据量成倍增长，之前的架构都遇上了各种各样的问题。所以我们决定研发自己的分布式存储平台JFS，JFS紧扣业务需要，针对这些小文件，我们设计了一套基于Paxos算法变体、强一致复制、高速、可靠的系统。

皮皮（Q5）：谈到小文件，很多人会觉得这是一个相对大文件的概念，像京东大量的商品订单、商品图片、库房记录等，这些数据都可以称之为小文件，原来是存放在HDFS的存储系统里，但后来京东自主研发了文件系统JFS，到底遇到了哪些瓶颈？这两种有啥不同呢？
桂创华（A5）：HDFS是很多公司离线大数据的首选，前面也提到过，京东有海量的小于1MB的在线数据，这些对HDFS的扩展性和性能会带来严重的影响。我们需要一个同时支持离线和在线大小文件的分布式存储平台，因而自主研发了JFS。JFS将用户上传的小文件合并成一个大文件存储，以避免海量的小碎文件给存储节点的系统带来沉重的负担。而对大文件才采取分块存储，提高大文件并行读取的性能。元数据存储方面，海量的小文件元数据很容易就把内存吃掉，所以我们设计了二级结构来存储元数据。在数据存放方面，不同HDFS需要记录每一个block位于哪几台机器上，我们将磁盘划分为若干个volume，同时固定volume复制关系，这样我们可以在block命名中编码存放的位置信息，避免了大量的block名到存放位置的映射存储。

皮皮（Q6）：在网络零售市场深耕近十年之后，京东也正式迈入了PB级数据管理的新时代，面对海量数据的压力，京东在IT架构上分布了多个集群，比如图片、订单、仓库流水、内部云存储、公有云存储系统集群，可能达到了千台规模以上了？能不能和我们讲讲这些分布式集群，从底层的硬件到上层的应用，如此庞大规模的集群是如何实现分布式集群管理的？
桂创华（A6）：其实是一个物理集群，只不过按照业务逻辑上划分出来了图片、订单、仓位流水等。JFS经过了持续两年、多个版本的迭代才达到今天的千台机器、PB级别数据规模。在底层硬件上，针对京东不用的应用场景，JFS管理了两种不同的设备。针对小文件实时、高并发、随机读较多的特点，我们选取了高转速的sas盘存储。而针对离线数据为主的大文件，则采取大硬盘sata盘节约成本。JFS主要由数据存储和元数据存储两部分构成。数据存储模块负责将用户的数据多备份均匀分布到集群中，并负责数据的存活检测、故障修复等。元数据存储模块则负责命名空间管理、文件映射关系管理、读写控制等等。在外围方面，我们还配套以完善的监控管理、自动升级和自动部署工具，通过这几个模块的紧密协作，完成整个集群的分布式管理。