当前位置:首页 > 云和虚拟化 > 正文

京东私有云三大技术方向解析

2015-04-03 CSDN 编辑:郭雪梅

  去年11.11时,曾有数家媒体对京东的云基础架构服务进行过采访。当时京东云平台首席架构师、系统技术部负责人刘海锋就京东文件系统、分布式缓存与高速KV服务、新消息队列、新服务框架等进行了阐述。几个月后,3月30日,在华为ICT北京站巡展时,CSDN云计算有机会与刘海锋深入沟通,看看这个70多人的团队如何实现从开源到自研的技术跨越,如何利用OpenStack+Docker技术实现容器管理,又将如何在今年底实现对京东所有机器实现自动化运维的目标。

  京东云平台首席架构师、系统技术部负责人 刘海锋

  要强调的是,刘海锋和他的团队所负责的是京东私有云项目(京东基础云服务)。不是对外提供云服务的京东公有云。而这种共存的状态,在亚马逊、阿里、腾讯以及其他多家互联网企业中都存在。

  京东的发展速度有目共睹。反应到业务与产品上,就是国际化、拍拍、广告、商城、金融、智能硬件、新业务的齐头并进。而底层,自然需要稳固的,能够实现“IT资源云化”的基础平台。刘海锋和他的团队从2013年开始,就聚焦在存储服务、中间件、弹性计算三大方面,通过API为京东业务提供服务支持。

  存储:JFS,JIMDB和统一存储

  千万/天的商品图片,千万/天的交易订单,千万/天的电子签收,亿/天的库房记录.......越来越多的非结构化数据给京东的存储带来了巨大挑战。使用过商用产品,使用过开源产品,但无一能跟上京东业务的发展速度。为此,2013年8月,刘海锋的团队开始自主研发大规模分布式存储系统——京东文件系统(JFS)。

  京东大规模分布式文件系统(JFS)

  JFS技术点:

  Paxos replication

  Unified Storage of BLOBs/files/blocks

  Append-only storage engine

  Reed-Solomon coding

  Scalable metadata management

  Hadoop Integration

  如今JFS已经是3.0版本。图片服务,订单履约、物流数据交换、电子签收、内部云存储服务和虚拟机与容器卷存储都已在JFS上。刘海锋说:“京东的每一张图片都存在JFS平台上。自研的系统通过主动复制策略,保证绝对的强一致性,而复制算法,能够保证在机器故障、磁盘故障、甚至文件误删除等问题存在时,数据都不会丢失。”

  与数据暴增相对应的是缓存必然越来越多。正如数据库天才Jim Gray曾说:“Memory is new disk.”而Redis和Memcache面对大内存业务的挑战也已不够。在Redis基础上做出技术“质变”,京东自研了分布式缓存与高速NoSQL——JIMDB。

 JIMDB技术点:

  精确故障检测与自动切换;

  RAM/SSD混合存储;

  在线横向扩容;

  异步、同步、局部复制;

  全自动化接入与管理。

  通过细粒度部署,大幅降低了维护成本,目前已经扩展到3000+台机器,并广泛支持了商品详情页、搜索、推荐和广告等应用。

  如果说JFS和JIMDB是已经完成的技术,代表了分布式存储和缓存与高速NoSQL。那么京东下一步自然是统一存储服务:支持文件/对象/大表的多数据模型和多IDC复制存储、单IDC缓存加速。而且根据业务需求,将引入SQL与事务支持。

  中间件:消息队列与服务框架

  支撑的业务模型越复杂,彼此的消息传递就越重要。而由于京东在仓储物流持续发力,全国各地有数百个库房。这些库房里面会部署10-20台服务器。由此,消息队列(MQ)在京东的订单管道、核心机房、仓储库房中就更加重要。刘海锋将之形容为:“MQ for the datacenter is like the pipes for Unix/Linux.”

  京东的MQ有三个阶段:JQ ->AMQ ->JMQ。前两者都是开源软件。面对“日均消息数过百亿”的挑战,AMQ已完全无法应对。比如有的大队列可能是1个发送者,有100个消费者,很多开源系统可能会存100份,但这几乎没有必要。通过完全的自主研发JMQ,只要存一份,消费者可以通过偏移量或指针去访问。JMQ更好地实现了:机房断电不丢消息;组提交技术;透明压缩;灵活复制。刘海锋如此评价:“JMQ在去年双十一中表现完美。”

  除此以外,越来越多的在线服务,需要统一编程、统一协议、统一接入、统一监控和统一治理。但面对数万服务接口和数万台服务器(很多服务器还分布在不同区域),如何使各模块可降级、可监控、可分解等,能够真正在内部API化、对外接口开放,需要更适宜的服务框架——JSF。

  弹性计算:软件定义数据中心与容器集群调度

  如果打开京东应用图谱,搜索、图片、广告、订单、Hadoop、Spark、MPI等都占据了不同的机器资源。实际上,不止是京东,几乎所有互联网或分支较多的传统企业都面临资源被划分的“七零八落”的现状。每一种应用都会占用不同机器资源。但随着机器的增加,要实现资源云化以及自动化运维,这一挑战,必须面对。

  京东弹性计算云规划

  刘海峰称之为:“弹性计算云。”一方面,将业务与机器解耦,全自动化维护;另一方面,高资源利用率+高服务质量+高效生产。在IDC资源上,通过OpenStack、Docker和JFS实现基础服务,以及部署集成、弹性伸缩的平台服务,最终实现应用系统。

  举个例子,商品详情页能够实现按照流量访问自动调度资源,比如利用OpenStack+Docker实现缓存容器化,在流量控制、快速部署、版本管理方面做的更好。

  对Docker的尝试从什么时候开始?有哪些收获?

  刘海锋:我们对Docker的应用从2014年8月份开始的。最终目标是希望能够为研发人员、数据中心技术工程师和业务系统之间搭建一个桥梁,使工作更简洁、高效,数据中心服务器利用率大幅提高。所以京东底层基础架构分两层:软件定义数据中心(基础服务),将机器做成虚拟化的,容器化的,虚拟网络IP,共享存储等;平台服务,顺畅将京东应用和平台融合。这是一个复杂的系统工程,而Docker在平台服务层面,能够发挥很好的作用。我们将其作为京东私有云的轻量级应用,主要是用的引擎、实例,并和Openstack“嫁接”,用OpenStack去管理Docker,如给它分配一个独立的IP等。针对Docker我们还稍微做了些改造,比如网络方面,以及存储方面。这样,每个容器或者每个虚拟机和原来物理机区别不大,很容易接受。比如用在邮件申请服务,一些特殊场景下的虚拟机提供(京东内部对安全性已有保证)。而在其上层,则是完全自研的系统进行调度、控制、监控、管理和部署。效果很好。举个例子,之前部署是部署界面选择、打包、机器分配、部署、检查、成功。但现在一个程序要上线,直接点部署,成功后直接通知你。中间环节,包含审批、申请等全部取消。再如,双十一加机器之后,很少假期后有人会选择减机器。这样无形中有很大浪费。而现在,直接部署,平台实现统一控制,随流量自动扩容,自动缩减。如此下来,资源利用率大幅提升,成本却会明显降低。

  除了管理Docker外,OpenStack还有哪些应用?

  刘海锋:京东弹性云的基础服务就是Docker+OpenStack+JFS。OpenStack变化很快,很难有那么多精力来追随。所以我们找到稳定版本,经过调整后进行了很多开发,比如Jing dong Data Center OS就是其中的一个分支。另外是管理Docker和应对故障。如当物理机故障、容器故障出现后,如何通过OpenStack快速检测、快速报警、快速响应。而这些开发,我们计划在年底或者明年初反馈给社区。

  开源软件基础上进行研发,大部分都会走向完全自研?

  刘海锋:有可能。无论是OpenStack还是Docker,作为通用型平台,都是越来越庞大和臃肿。很多功能都是我们不需要的。所以依照发展的需求,我们现在有工程师在自己写。

  旧有资源云化会面临很多挑战。哪些是你们遇到的?

  刘海锋:业务需要应用支持。很多老应用最初使用的都是物理机,而且非常空闲,有可能一个小程序占了128MB的一台服务器。所以这些应用需要从物理机迁移到云上。但如何迁移,比较困难。这不是技术问题。所以京东是有专门的项目经理在推动的。而我们来提供简单、易于使用的迁移工具。现在,京东几乎所有应用都在分批迁移,涉及各个部门,各个业务线。

  曾提到Hadoop应用。JFS和Hadoop有集成么?

  刘海锋:是,我们团队不用Hadoop。但JFS会实现对Hadoop的集成。这样在线和离线数据统一存储就很容易实现,作为整套方案也更能扩展元数据,降低成本。

  京东弹性计算云项目的主要挑战与最终愿景是?

  刘海锋:求规模和零事故的矛盾。如何在保持稳定的情况下扩大规模,因为只有规模大了,收益才大。我们每天都很谨慎小心来做,希望尽快实现万台规模的控制。 现在我们内部的弹性云项目仅仅进行到1/5左右。后面会更快速地展开。最终弹性云将管理所有机器资源,生产虚拟机或容器或物理机,托管调度各类业务包括应用与存储、在线与离线,成为业务的基石,让研发生活更美好。

大家都爱看
查看更多热点新闻