京东商城丁俊:大流量下的基础技术架构

2017-06-13


 图片6.png


       5月27日上午,由工业和信息化部人才交流中心主办,蓝桥杯大赛组委会和拉勾网共同承办的“2017中国互联网青蓝峰会”在北京大学邱德拔体育馆隆重举行,京东商城基础平台部中间件与存储技术负责人丁俊先生在上午的主题演讲会上带来了分享,演讲全文如下:

 

      大家好!

   

       我今天讲的东西有一些偏技术,然后主办方一再跟我沟通,就是说现场有一些还是在读的大学生,我今天尽量讲的通俗易懂一点,然后简单介绍一下,不会太深入的去介绍我们产品的一些具体的架构是什么样子。另外,因为也有一些在校的学生,我也讲一讲我自己在职十多年的一点心得体会,包括这些年招聘人员的时候一些感受吧。

    

      其实我本人是学生物科学的,并不是学计算机的,但是我一毕业以后,就转行到计算机行业。我有一点忠告,你如果说不是本行业的科班出身,我觉得你可以考虑在校的时候,做一些,发一些技术类的博客,参加一些开源的项目,那你在面试的时候会大大加分。


      行,我们进入今天的主题。


      在介绍我的部分之前,我先说说京东这些年的一个情况,在这样大背景下,我们的技术是怎样进行改进的?2012年之前,其实每年增长都是两倍、三倍,甚至更快的时候有五倍、六倍这样子。后面随着体量的增大,增速一般是翻番的样子。有这么大一个增量的数据,系统技术是怎样支撑它的,我简单介绍一下整个京东的技术这些年的一些创新。


      我们从一个简单的商品流来看,商家需要上传一个商品的信息,包括图片,大家都知道,你上传的一些图片,有可能是某一些伪艺术的图片,你上传的商品描述里面可能有一些不合规的词语。如果每一张图片,每一个文字都通过人去审核,那这个人需要多少?我们京东可能有几十亿的商品信息,不可能每一个都能看的过来。就有比如说鉴定图片的,通过机器学习去识别这种黄图,通过自然语言的处理识别语义理解,来检测详情里面一些不合规的信息。


      我们接着往下,你浏览完信息以后,是不是要进行一个咨询,和商家聊。我们的JIMI会提供一个咨询服务,以前的话,JIMI后面跟的都是一些客服人员对你的问题进行具体的解答,随着客户量的增加,客服成本其实也挺高的,我们就想着怎样通过技术回答一些常见的问题?我们也会有一些语言的理解,通过机器人和你回答,当然大家如果说平时晚上无聊,也可以去调侃一下它。


      你咨询完了以后可能会下单,下完单你的信息就会进入到库存去生产,在库存生产里面,以前你会看到一个场景,在库存里面,一个捡货车一样疯的男子,奔跑在货架之间。现在我们通过一些技术,引入一些机器人,通过机器人自动的自己去捡货,它的速度、效率,包括准确率上都会大大提高。同时,在成本节约上也是会有很大的提升的。


      当我们下完单,库房生产完了以后,可能这个定单需要配送,配送的话,就以今天这个地点为例,可能我们京东在北大有一个配送的站点,在颐和园周边也有一个配送的站点。可能你很着急,你下了一个订单,你可能写的是北大某某某楼,也有人可能会写,比如我的地点是颐和园多少号,我想快递给我的朋友,我可能写的是颐和园。我把这个订单到底是分配给北大的配送站还是配送给颐和园的配送站呢?这里面就涉及到智能的地点匹配等相关的技术。


      大致说了这么多,我下面进入我自己部门负责的产品里面来。我的部门负责的产品就是提供现成系统的一些支撑服务。我今天重点讲一讲京JSF、JIMDB、JMQ。


      JSF是一个服务框架,举个例子,一开始一个公司比较小,一个人能负责很多很多的事情。当你的公司变大以后,部门之间会有一个接口人。这个JSF就相当于是系统之间的一个接口人,系统变大以后,它的一个系统与系统之间沟通的一个接口,中间一个联络的框架。


      中间这个是京东,JIMDB,也就是说它是一个内存的数据库,它会比传统的数据库性能上更高,速度更快。就好比说你以前开个拖拉机去运货,现在去用飞机运,速度有这种差距。


      JMQ是一个消息中间件,大家如果说有工作一两年的人,比如说你住在天通苑,每天早上挤地铁的时候,没有那个栏杆挤地铁,大家一窝蜂挤到站台里面,估计地铁要停运了,那怎么办?工作人员用栅栏把你们隔开。这个消息中间件就相当于这样一个功能,当大的流量来了以后,先放在我这里,减慢你的速度,让后端的系统能够处理。


      下面我们进入第一个产品大致研发路径的说明。这些产品其实它在我们内部都经历过这三个时期。第一时期,我们基于一些开源的主件进行改造,然后分装。当然随着流量的增大,和内部用户使用越来越多以后,它对新的一些特性的需求,你在原有产品上进行一个修改,很难达到你的预期。因为它改动起来也比较困难,越来越难以维护,大码越来越难看。后面我们所有的产品进入一个自研,全部自主研发。后面就是自主研发以后,我们慢慢的再去完善我们的系统。


      刚才讲了一个接口人的系统,就是我们内部叫RPC框架。当时在公司的内部有使用各种各样的框架,右手边这个就是RPC框架的一些名词,我不一一解释了。你想象一下,我有一个促销系统,它需要与用户系统对接,与商品系统对接,与价格系统对接,这些系统之间使用的都是不一样的技术。这个促销系统如果要对接这三个系统,就需要引入三个不同的框架。


      大家知道工业化就是想着怎样把它标准化?然后流水线的生产。如果每一个系统使用不同框架的话,一个开发效率上没法提升,因为你可能对某一个框架比较熟悉,你很难同时在很短的时间内对多个框架做到熟悉。初期的时候,由于房价都不一样,你也很难做一些统一的监控等等一些东西。经常面临一些问题,比如说某一个系统它变慢了,你怎么发现它?服务器当机了,你怎么把这个故障机箱的容量调到别的地方?还有,我们的版本需要不停的迭代、发布,白天用户在用,你只要一重启,对用户是有损的。


      这就很难,只能够让研发人员比较辛苦,到了凌晨去发布这些系统。怎样让我们的研发人员生活更美好一点?晚上可以回家陪女朋友对吧?陪陪家人,或者陪陪你的孩子,我们需要有所改变。后面比较偏技术上了,我就尽量跳过了。


      我们有这样一些痛苦存在,我们想着我们需要一个统一的RPC框架,同时我们得有一些服务治理的一个东西在,为什么需要它?你想一下,我一个接口发布以后,有上千或者上万个客户端,你不知道哪个系统访问你,如果你上线了,你哪个接口变动了,会影响到客户变动,你得一个一个通知客户,怎样做到让这些客户自己知道?怎样把这些客户的信息收集起来,我能够准确的知道我这些接口影响了哪些人?


      在我们自研当中,其实一开始也是因为经验不足,另外就是流量也特别的大。我们一些模块出现有瓶颈,其实在这种公司,系统的初期,往往有一个比较好用的方法,我系统有故障了,我重启一下行不行?但是这个系统它比较特殊,它所有的一些你的服务方、消费方,都要连接这个系统,我们叫它注册中心。这个系统与我们内部进行SOA以后,容量化以后,IP剧增,当有些系统重启以后,对这个服务压力特别大,导致它的接口频繁的重启。


      尤其一大促,我们当时真的非常紧张,我们就想着怎样把它尽快解决起来?发现这个服务慢了,我重启一下,最后发现你越重启,你一起来就会被打死,因为有成千上万的请求在那里等着你呢。你还没站好,它就把你打趴下了。基于这种经验教训,我们又对这一块进行了改造,具体怎么改造的我也不细说了。主要我们通过一些分布式的技术,通过缓存等等。我不细说了。


      这是我们那个系统做完以后的一张图,它会有一些特性,可能有更多经验的同学会有一些感受。我们后面怎样让它在白天也能够发布接口,更新接口?我们把它的流量进行分组,当我要发布这一组的时候,我把它的流量切到另一个地方去,我发布完了再切回来。还有监控系统监控这些接口的性能,你想我一个服务可能有上百台服务器,其中有一台性能低了,或者影响用户体验,TP999可能就会下降,我怎么尽快找到这台有问题的机器,我们需要对这些接口的性能进行一个监控。


      在这里说一下,我觉得监控系统对所有的在线服务是至关重要的,举个不是很恰当例子,就好象古代的皇帝,他需要设东厂西厂,他不知道那些大臣在做什么?做了些什么?他心里很慌,我们也一样,我不知道我服务器的运营状况我心里没底,但如果我把他们监控起来,那我一旦有问题就会给我报警发短信,我很快就能知道哪一个接口、哪一台服务器出了问题,就能很快解决。


     下面我讲一下第二个产品,分布式内存数据库。最初的时候,我们是这样的一个架构,就是我们使用了redis,布在不同的地方,让它访问不同的数据,因为你的数据放在一台物理机上可能是装不下的。当这些系统随着数据量的增大,它需要扩容,每次一说到扩容,宝宝心里很苦。因为你要扩容就要把数据搬家,你搬家当中,就会对用户进行一个体验的影响,你的系统就没法进行服务,只能凌晨来升级,来搬家。这样对用户尽可能的影响少一点,你们在睡觉,我们在搬数据。


      还有一个,有时系统有故障,一台机器坏了,有一些配置信息在客户端,然后运维说我帮你补了一个服务在另一个地方,我的系统怎么找到另一个系统?我需要我去系统里改一下配置,然后把它重启一下。你想想半夜,也有可能是后半夜你正和你女朋友看韩剧等等,然后一个电话过来了,说你给我重启一下系统,这个心情我觉得大家心里可能也不好受,想着怎样改变让我们的生活能更正常一些?


      另外,可能你部门组织一些集体活动,一个组都去了,你不能说留一个人,张三你在家里值班吧,我们去玩儿,好像也不好意思。但是你要是不留人,你们爬山爬的正高兴,一个电话过来了,说你的系统有问题,这个时候就傻了。我们怎么去改变这些现状?


      针对这些问题我们做了一系列的改造,让我们的系统更智能,能够自己进行故障的恢复,能够自动去扩容,不需要人的干预。然后系统之间进行一个隔离,让它们之间不会相互影响,我们做了大量的工作。现在基本上能够做到这一点,就是弹性扩容,自动的故障恢复,我们的开发、运维也没有像以前一样那么狼狈,那么的被动,生活也会正常一点。


      这是我们的一个系统图,我今天也不深入的讲解了。这是我们当时做这个系统的一些经验,就是你提前把一些配置下发下去,然后你怎么监控哪一个系统坏了?我给它安排几个哨兵在那里,在机房的一些角落里。大家进行投票说它死了它就死了,如果有一个人反对,那它就是活的。这是我们系统的一个数据,我们有10万个实例,有300T数据在内存里,高峰时期每秒的访问量5亿次。


      第三就是消息中间件,也是经历了前面相同的痛苦,经验都大同小异,这是当时碰到的一些问题,包括下面有一些系统功能特性等等。这是我们系统的一张图,我们MQ的消息每天大概有800亿条,有1.5万个队列,你可以认为是1.5万个通道,有600组的服务器,一组两台机器。


      因为在场也有工作了两年三年的人,我说说我自己的一些体会吧。就是你能够通过服务端动态下发的配置,尽量不要写的本地,因为本地可能很多很多实例,你要一个个去重启,你可以把它放在服务端,放在某一个配置中心里面,你改一个地方,它自己都知道。


      第二个,能用户认知的地方,就别强制用户配置,也有一些配置容易引起错误。


      第三个,减少一些升级,你想我们有几千台服务器,因为你的一个漏洞,我们陪你升级。


      第四个,在现实当中也是,我感受很深,办这种进京证,现在能自动办了,减少人工。


      第五个,监控数据尽量放在一起展示,很快能够挑出那个高个子来。还有就是监控一切你能监控的数据,尽可能加快你排查错误的效率。


     我认为架构是一个动态演变的一个过程,架构也需要小步快跑合时宜,什么叫合时宜,我用5年前的技术对付现在的可能不合适,用现在的架构技术放到5年前去,穿越回去,其实也不合适,可能代价很大。如果我是个大公司,一个人忙不过来。


      另外这是我们对系统的大致规划,比如某一个城市,某一个机房地震,自然灾害了,别的敌方能够正常工作,目前我们能做到同城多户。

   

       行,我今天就讲这么多,谢谢大家!

 


上一篇:【青蓝峰会演讲现场】星瀚资本杨歌:重构未来-产业升级与技术革命

下一篇:【青蓝峰会演讲现场】拉勾网鲍艾乐:在风口到来时迎风奔跑