BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

京东无线服务端架构演进历程

| 作者 赵云霄 关注 0 他的粉丝 发布于 2016年5月4日. 估计阅读时间: 34 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

在4月21~23日举行的QCon北京2016大会上,京东商城无线业务部、网关京东负责人赵云霄老师分享了题为《京东无线服务端架构演进历程》的主题演讲。在演讲中,赵云霄从三个方面介绍了京东无线服务端架构演进过程。第一,京东无线服务端。第二,京东无线服务端架构变迁。第三,京东无线服务端未来发展状况。本文根据其演讲整理而成,点此下载演讲PPT

我是2011年加入京东,当时无线部门叫手机端。加入京东无线以后一直被人问两个问题。懂行的人问我,你对无线互联网怎么看。还有不懂行的人问我,你买手机便宜吗。

开始讲京东无线服务端架构演进历程之前,先看看现在京东无线订单,已经超过了京东订单GMV的半壁江山,毫不怀疑,京东无线已经是京东最主力最核心的一条业务线,而且京东已经完全实现了无线化。

接下来我从三个方面介绍一下京东无线服务端架构演进过程。第一,京东无线服务端。第二,京东无线服务端架构变迁。第三,京东无线服务端未来发展状况。

京东无线服务端

首先,在大会上统计一下数据,不知道多少人的手机上安装了京东手机APP,从举手的比例来看,大家也能猜到。就像这个图画的一样,京东无线服务端的流量像这个瀑布一样,汹涌不绝。服务端就是APP后端默默支持它的亲密爱人,你可以使劲地消费,你可以随便地购买,我来承担你给我带来的流量。

这是我们服务端的一个进化历程,其实它也是随着我们京东无线整个业务在进化。我一直在强调,所谓技术驱动公司——这个词不能曲解——实际上是靠技术去辅助业务来演进的公司,京东作为电商,一个自营电商,它就是这种技术驱动的公司。

2011年2月,京东开始做无线。第一版苹果的客户端上线,从那时起,京东无线服务端的亲密爱人出现了,默默背后支持着。

2012年业务经历了小高峰。这个达成从2011年开始了,1月份应该是微信第一版也上线了。京东当时已经在PC端取得了比较大的进步,所以无线端我们是吃了一个红利,随着整个京东平台业务在不断的发展,无线端的业务也在发展。这时候原有初始架构的问题暴露出来了。我们一直撑着,一直到2013年这个矛盾非常突出的时候,进行了第一次的架构升级。这次架构升级的变化还是非常大的,用一句话来概括,这次架构升级,即大家通常说的SOA体系架构,让我们进入了一个服务化的时代,京东从2013年年初进入了这个时代。

2014年是无线发展非常迅猛的一年。当时无线互联网的大潮大局已定,大家都有一个共识,无线互联网应该是未来,在京东无论高层还是基层,对这个都有一致的认知,而且我们的很多资源也都在向无线端倾斜。

到了2015年,无线端通过多年的打磨,技术已经有了一定的积累,业务也比较平稳,比较成熟了,这时候我们开始思考无线端做成什么样,无线服务端做成什么样。经过了这么多年的积累,大家最后得出的一个结论就是,我们不能做一个系统,也不是一堆系统的集合,我们要做的应该是一个智能的生态。后面我会给大家详细地讲一下,我们如何来支撑这个生态。

京东无线服务端架构变迁

现在我们来看看京东服务端架构变迁,可分为初始架构、服务化架构、质能生态三个阶段。

关于初始架构,我对它的评价就是为了追赶PC股权业务,当时还是PC流量为王,为了把京东整个业务都给补全,把PC端能赶上它,把它的业务都能补上。第二阶段是,服务化架构,我们完成业务上的拆分,我们要服务化,因为业务的不断演进、流量的不断增加,带来必须要有这种变革。第三个阶段,当然它不是最后的阶段,现在我们一直在为之努力的,而且我认为已经初步达到的一个阶段,就是智能生态。大家看一下这个质,没有写错,就是质量的质,我们要为我们的用户提供一个全方位的、高质量的服务。这阶段的主题是,工匠之心不断打磨,技术趋于成熟的时候,不断演进我们的细节,一颗工匠之心对我们来讲是非常重要的。

初始架构

我们大致来看一下初始架构。其实任何一个架构,包括任何一件事,都有它形成的一个背景。2011年京东无线端初始架构的背景什么样呢?第一,无线互联网热潮已经兴起了,但是2011年,大家都在说无线互联网是未来,有可能它很牛,但是谁又能确定未来到底能不能取得成功呢?虽然京东在2011年的时候已经很强大了,但是它也是抱着一个试水的态度涉足无线。我们在无线端尝试做京东商城的APP,通过手机购物带来多少的流量,给用户解决什么样的问题。

还有一个背景。京东作为全国最大的自营电商,它的业务非常复杂,因为大家知道,我们大部分的商品是自买自卖。所以就像一个开商店的,为了让用户在这儿得到更好的体验,我们的采销、市场想出非常多的花样,让用户能得到实惠,又能有良好的购物体验,而且把这个东西能卖出去,大家能双赢。另外,提交结算的时候还有很多满减,购物车各种玩法,这些是特别复杂的。

基于这样一个背景,我们无线互联网及试水,业务比较复杂、比较多。所以第一版架构基本遵循了三个原则。第一,优先解决有无,开始的架构都是第一解决零和一的问题。第二,瞄准PC,把业务给股权,不可能说手机端,人家在PC端享受到的东西手机端不让玩儿,那更谈不上发展了。第三,快速响应产品的需求,产品指导研发,很多场景、很多的玩法必须帮助产品实现,而且速度要非常快,要快速迭代。当时整个无线端抱着一种创业的态度做这件事情。

后两个原则可以合到一块,因为它们有很大的关系,小团队开发快速部署。2011年的时候,京东的无线服务端只有三个研发,大家可能想不到当时京东的业务已经非常完备了,现在的研发只有三个,确实是这样的。所以我们要求在小团队的规模下可以部署得非常迅速,可以开发迭代得非常快,这就是我们遵循的几大原则。

总结一句,初始的架构就是一个简单的Web系统。中间的负载均衡没有画,业务系统通过代码模块的形式组织各种业务就是一个简单的Web系统,后面挂了数据库,比如交易、价格、库存、用户,等等。可以看到,我们这个基础的架构,内网的交互协议当时还是非常复杂的,我们有各种协议,也没有统一,对外就是HTTP。当时的管理系统其实是通过一个缓存跟业务系统交互的,这种方法回过头来看非常low。当时三个人的小团队开发各种业务,我们考虑只能用最简单、最粗暴的方式实现,能快速地股权业务。当时的流量真的不是第一重要的问题,也不是最主要的矛盾。

对于初创阶段,我总结了三点。第一,业务一直就是架构变迁的驱动力,不可能脱离业务去谈技术。第二,成熟简单的技术就是最合适的,这个理念一直贯穿始终。我经常跟我的团队说,不要把事情复杂的形态呈现给我,我的脑子非常简单,想不了那么复杂的事儿。第三,不要过分追求架构。大家看到初始的架构等于没有架构,但是这种形式在这时是最符合业务需求的一个,能快速迭代,能非常方便上线,而且人员这么少,能Hold住这个系统。

只说了初始架构的优点,其实还有很多的问题,所以到了流量越来越高的时候,就没有办法解决了,只能进行架构升级。但是更情愿这个老架构的光荣退休。

服务化的架构

下面看看第二阶段,服务化的架构。

2012年业务有一个小的增长,它带来了流量的增长。当时每天的日均接口访问速度突破了八千万,合并了很多接口以后,这个量其实在当时就已经不低了。到了当年6月18日,已经破亿了。这点对于我们来说变化真的非常大。我刚进无线的时候,如果订单上了一千都要吃饭庆祝一下,但是现在访问次数已经突破了这么多。无线端要发力了,我们要去股权我们的业务了,领导已经认识到无线端的重要性了,所以我们要扩大我们的团队。

我记得2012年的时候,无线端人员增长非常快,突然三个人变成无线端的老员工了,来了很多实习生还有社招引进的一些人才,他们组成了整个无线服务端,这会儿我们就要协同作战了。也就是说,我们把人分成若干个组,去开发不同的业务线条。因为随着业务的增长,提出的业务需求变更越来越多,可能一个小团队响应不过来了,人员要分开,一些去做库存,一些去做购物车,还有一个团队专门负责商品。我们的业务线划分从团队划分开始,并不是从系统开始。

还有一个大的背景。整个京东都在升级,从.NET升级到Java了。我们很早就已经在Java架构上摸爬滚打了,从2010年、2009年京东开始Java架构了。底层很多基础服务的架构有了非常大的改进,交互协议不断统一。

我们看一看,初始架构面临了一些问题。开始第一业务团队分离,系统并没有分离。比如这样一个例子,做商品的,今天有十个需求要上线,做购物车的有五个,结果做商品晚上五点开发完了,做购物车的到八点还没有做,今晚要上线,做商品的等着购物车,两个团队都等着,最终一块上线。还有就是做库存的把基础的服务类给改了,做商品提交代码的时候忘了,出现了冲突这怎么办?团队扩大了,系统没有隔离造成了开发上的问题。还有单一系统的流量,其实这个时候流量已经开始是问题了,我们希望能够随机地调配流量。最简单的,业务上提了一个新的需求,我希望北京的用户可以提前两天能看到这个,我希望把北京的IP切到单独的业务集群上,它有新的功能,而其他在老的业务集群上。这会儿给我们提出极大的挑战,没有办法,只能找运维,告诉他,我要在负载均衡这块去切,但是危险性非常大了。

我们经常说的系统肥胖病出现了。京东的业务非常复杂,是一个非常完整的自营体系的购物流程,整个流程做下来,代码量非常大。当时一个服务端的代码,涉及的人很多,很多人代码写得不一样,又缺少非常良好的代码管理,于是带来了代码质量问题。我记得当时一个纯代码包几十兆,加上它依赖的库,体量非常大,每次上线让人心惊胆战,往服务器传都是一个问题。

所以基于这些问题,服务化架构开始了。其实就是拆字决,大部分的公司遵循这种理念。系统越来越大,我们从两方面开始拆。第一,纵向的分层,独立出API网关,很多业务面临这种问题的时候也是这样,而且我在网关可以做很多的公共策略,比如,安全策略、公用策略等,都可以做在API网关,它的特点就是它可以理论上进行扩展的,它和内存有关。第二,做业务的拆分,这个是非常重要的,把业务给梳理了,给它拆成几大业务线条独立的部署,也就是我们说的服务化的架构,商品独立成商品系统,购物车一系列的接口都从这儿出,专门的团队运维它,去研发。这样大家的职责非常明确了,也不会有冲突,购物车想第二天凌晨上线都没有问题,商品可能头天晚上5点多上完线了。

大家看一下,这是比较简单的,描述了一下当时的服务化架构、API网关,我们通过一个HTTP协议,为什么中间没有自有的协议呢?我们开始服务化架构刚刚形成的时候,内部自有框架没有那么成熟,而且不断响应业务的变化,抽调出来做服务化改进的人非常少,我们只能是遵从原来一直在说的简单实用、能把控的一个技术,对我们来说是最合适的。所以我们还是采取了HTTP协议,我们把当时的Apache httpclient 升级了一下,到了四点几的版本。

大家知道,它有一个池化的功能,高并发下比较强的机制影响它的性能,基于这个,我们自己实现了一个连接池,可以把这个HTTP连接复用,这样对性能有比较大的提升。我们把配置管理整个升级了,现在看到的所谓的异步配置管理是推拉结合的,早期做了异步的版本,有一个严格的版本管理功能,拉取我们的配置。后来我们又上了一版来实时的推送我们的配置,这个配置管理系统是非常重要的。我知道,在线电商流量来的时候谁都挡不住,我们可做一些有损或者无损的降级,这种降级依赖很多配置的下发,一个开关,任何一个对资源类调用,我们抽象的,对后端服务接口的调用,严格规定对任何资源类调用必须要有开关,这个是不能妥协的。我们开关可以冗余,但是没有的时候关不掉,眼看着后端某一个服务把你拖死的时候很可怕了,我们改造了这个配置管理系统。

大家还可以看到,我在这里特意突出了缓存集群123,原来在初始架构的时候,所有的业务都用一个缓存的集群,我们用的是memcached,它的内存管理机制会导致一个问题,如果k-v键值对大小非常不一致,非常散的话,这个利用率非常成问题。基于这个,把所有应用而不是按应用来划分这个缓存,而是按应用的特点,来划分这个缓存,而且秉承最重要的理念,缓存如果没有特殊需求,我们要求小对多部署,一个片不能分得过大,如果流量来了,这个承受能力是不一样的。

总结一下,对于这个服务化架构的阶段有几点心得,可能是基于我们一些积累。第一,不要为了拆分而拆分。在开始的时候一个系统其实完全响应了我们的业务需求,在不同阶段需要做不同的事,如果没有必要去拆分这个东西,我也不会选择这个。我去过一些朋友的公司或者一些小公司,大家跟我谈这些,我们需要拆成多少个服务,我说你的业务量没有达到这个量级,你的流量、你服务之间的矛盾不是主要矛盾的时候,你没有必要去拆。因为大家知道,拆了以后,每个集群都要做冗灾,集群之间的交互,这些也是成本,都要考虑到。

适当的冗余,其实可以把这一条跟第四条结合一下,在一个服务化的架构来看,我们最头疼的是服务的治理,它之间调用关系的治理是非常难的。在起初吃到了很多亏,我们很多横向的调用,我们内部在用户这一块,我要展示用户买过哪些商品,开发商品业务的同事会说,我们能不能调内部的,跟他们沟通比较困难,没知会的你的情况下横向调,后来梳理的时候发现服务之间的调用就像一个蜘蛛网,大家已经没有办法去理清你调了谁,谁又调了你,这种对我们的伤害是非常大的。很难确定你的上游,你上游的上游是谁,可能就成为一个最脆弱的阶段,你挂了,可能这个环中所有的人都挂了,调用关系的梳理是非常重要的。

质能生态

接下来说说质能生态,这可能是我们要着力去讲的。前两个内容大致讲了一下,大家大致上能猜得出来高并发的后台系统,它的演进过程是什么。我没有刻意地跟大家突出流量达到多少了,才去做,因为没有一个现实的标准。大家可以根据自己的情况去定,哪个矛盾是最突出的,根据这个矛盾,要想一个什么策略,再去决定自己的系统架构什么样的。架构没有绝对。所谓系统架构就是一个权衡,如果你觉得这个是最主要的矛盾,OK,需要我改就改,这就是一个架构。

质能生态的背景是这样的。京东已经进入了完全的无线化,从2015年Q4,京东无线整个订单量完全超越了,非常迅猛的一个速度,我们对外发布的是220%的增长。大家可以想象,无线业务的发展,从原来基础的电商能力,比如说一个黄金的购物流程,首页、商品、购物车下单到结算,从基础的购物流程,京东其他的一些电商能力,我们也要开放,不光局限于让用户购买,可能其他一些大家印象非常深刻的仓配的能力、物流的能力,可能后面都需要去开放,我们怎么去开放这个东西。

无线服务端作为京东第一个去试水无线的,其实非常明显在这个中间起到的作用,我们是探路者,我们肩负着一个重要的职责,我们积累的这些知识、这些经验,我们希望把现有的京东无线服务端形成一个体系,打造一个服务的质能生态。

现在简单解释一下质能生态。其实质能是许总最早提出来,秉承了京东一直强调的“客户为先”的理念,给客户提供的服务应该是高质量的。从我一个技术人出身,我希望每台机器,我的服务达到几个九,但是从用户的角度,能不能顺利地购物,响应时间是多少,会不会经常提出网络开小差了,这是对我们基本的要求,是我们要贯穿始终的。

还有就是生态。这个词看着是炒概念,但确实经过我们这么多年的积累,京东无线服务端发展了五年,才走到了QCon这个讲台上给大家分享一些我们的心得。我觉得我们原来还只是在做一个系统,或者说的大一点系统的集合。回过头来看的时候,当我站在用户的角度看,站在我同行、同事、市场采销同事的角度去看这个问题,我发现我们应该建造一个生态,是一个能让我们所有的服务非常安全的一个环境。我总结了这样一个生态:它应该接入友好,监控应该非常到位,变更应该非常方便,数据应该非常完备。

我更喜欢把生态比喻成学校,我们开始就是在建立这么一所学校。

我觉得有三大利器,可以用来打造京东服务端的质能生态。第一,团队。第二,技术的支撑。第三,流程上的保证。人、技术还有规则,我们都要有。

团队

首先,重点给大家讲一下我们团队。我们无线服务端是非常小的团队,我们在业务快速迭代的过程中没有很多的精力重视技术、代码的质量、架构是什么样的,我们要用哪些先进的技术,但随着流量越来越大,业务发展越来越快,系统越来越复杂,我要求我们团队越来越应该具备一颗工匠的心。

有三个非常简单的要求,不是全部,我列举了一下。

第一,基本功一定要扎实。你可以不知道框架,但是不能不精通数据结构,因为我们用的是Java。大家应该有一个共识,现在在市场上招聘,你能招到程序员,80%都会跟你说,哪些框架用得非常好。但事实上在我们面试的时候,很少考这些东西,基本不会问,你用过哪些框架,希望你对基本的算法数据结构能够做到非常熟练,我都不求精通,但是一定要非常熟练。我认为这是一个程序员的灵魂,应该是一个基本素养。

第二,对自己的代码要有工匠之心,追求质量的极致。这可能是非常冠冕堂皇的话,但是确实需要这么做。我们的系统非常复杂,现在无线端后端光业务系统接入了好几十个,不下50个业务系统,这些系统需要怎么对待你的代码,态度是非常重要的。

第三,对开源项目要有钻研探索的精神,我要求团队对引入的任何一个开源的项目、开源的包、原代码,都有极致的了解,包括现在用的ZK、Netty,Apache其他的项目,我们引进的时候有严格的技术评审,到底能给我们带来什么收益,给我们带来什么不利的问题。因为任何一个东西,尤其是技术,都是双刃剑,能解决一些问题,但势必会带来一些问题。

比如,最初我们的架构,不能说它不好,它是非常优秀的框架,但是随着发展不再适合我们,我们毅然地去掉了它。为什么?几次在爆出它的漏洞、它的性能问题,我们经过横向对比。所以我要求对源码、框架都要有非常细致的研究,才能去使用它。否则它放在一个要求365×24小时不宕机复杂的在线交易系统中,实在不敢说,哪天宕机,一帮工程师在那儿要研究几个小时。可能几分钟的宕机带来的经济上的损失都是非常巨大的。

我一直在强调,我们不能站在工程师的角度去考虑问题,尤其是你的系统在演进,相信各位开发人员的能力也是不断在打怪升级,不断往上走。所以我认为我们的视角一定不能只局限于在工程师的视角考虑问题,不要为了技术而技术。我的团队经常跟我说,我们是不是要用这个东西,这个东西非常牛,是哪个公司推出的,它会给我们带来什么。事实上我基本上持否定的,持非常审慎的目光看待这件事,因为最先进的高精尖的技术不一定肯定能解决你的问题,反而带来使用上的成本。

团队目标一定要一致,要具有战斗精神,这是团队理念问题。我认为一个团队最重要的是目标的一致,如果目标不统一很难做成一件事。现在我们团队一直灌输的目标就是,我们的系统一定要是可持续运营的。这个概念非常重要。一个可持续运营的系统,它不是快,不是技术有多高精尖,不是有多先进,我们要求的系统目标是可持续的运营,我能非常好地监控它,可监控、可控制、可扩展,这就是一个可持续运营的系统。

战斗精神有多重要呢?精神食粮有时候非常重要。我们迭代的次数非常频繁,京东的迭代,一周标准是两次,但是我们的业务非常多,可能一周至少两次,也可能每天都在发布,每周又各种促销活动,大家经常去买一些现在有的超级品牌日。第一期,我记得好像是乐视,我不知道大家有没有买过乐视的电视。还有五粮液超级品牌日,基本上每天都有促销。还有一元秒杀,大家都感觉秒不上,确实秒的人太多了,我也没有秒上。这说明我们的业务都有非常多的玩法。

现在我们团队的工作是刀尖上的舞者。这种工作有很多形容:我们在给高速行驶的列车换轮子,我们在悬崖边跳舞。我用一个非常高大上的词,我们是刀尖上的舞者。我们既要保证海量访问的系统,它能正常地为用户提供服务,让用户无感知,保质保量,而且我们需要把非常复杂、非常多变的业务迭代上线。

技术支撑

第二点,我觉得除团队外,我们的技术是非常重要的,即技术支撑。作为电商公司不可能不谈技术。

首先,我一直在强调大到至简,一个简单的系统。任何系统能够做复杂太容易,如果把复杂的系统做简单,把复杂的业务用非常简单的系统展示出来,这真的需要功底。我对这个的理解是,技术选型不刻意追求高精尖,本着够用、合适的架构尽量简单,它很稳定不需要用很多的时间来开发、研究,但是它一直承担流量,能承担到几十亿级的流量,也可以用为数不多的服务器看你的流量。

其次,架构设计要简单,权衡才是架构的本质。我很少谈架构,架构不断在演进,到了这个地步了,我需要这么去做,到了另一个地步,又需要这么去做,不断解决问题。当我回过头来发现,原来我们这样是合理的,已经演进成这个样子了。在演进的过程中,我们可能把不合理的东西去掉了,或者我们认为失败踩过的坑,我们都给忽略掉了,最后能跟大家讲这个架构,其实过程中还是很辛酸的。不要为了设计模式而设计模式,也不要为了模式牺牲可读性。不要过于追求设计模式,那些设计模式往往造成一个代码的可读。我们对一个模式认知的不同,大家交互语言不同,跟一个坦桑尼亚人说汉语肯定不懂。所以我很少让大家说,你必须用什么设计模式。

我们需要学会把一个问题简化,提炼出来,这才是我们架构的本质。

可扩展,架构灵活的可扩展。比如,现在这个服务化的架构,说实话没有想过再去做一个更深入的服务化,我觉得它现在能达到我的一个要求。它可以横向扩展,我现在先要上一个业务直接上一个服务,从API网关接入,就没有问题了,我能很好地支撑这个业务。还有就是快速搭建服务,最简单的,我们有很多的模板,我们可以快速的生成一个工程,还有代码生成的工具,可以把公用的模板代码快速的生成,这只是其中的小工具。服务化架构最重要的就是接入要方便,接入方便最基本的就是协议要统一。统一并不代表单一协议,我们需要支持几种比较主流的协议,如 HTTP、JSF、SAF。

这个协议说的是对外协议。我们的API网关是对外统一的交互协议,移动端是一个过敏体质,大家一定要记住,它非常敏感,对流量敏感、对资费敏感、对用户信息安全也非常敏感。大家经常说你们这客户端特别费流量,那个客户端特别省流量,尤其在你用自己3G、4G的时候,这都是银子。对协议的要求,用户感知的速度,大家最直观的,我在2G网络下访问京东购物能不能购物,在3G、4G访问什么样的体验,在Wifi访问是什么样的体验,这个要求一定要流畅。对外交互协议有没有改进?其实并不是说对技术非常保守,我们只是要把一个技术用得非常成熟可以拿出来给大家用,不去误导大家。现在其实在用的跟客户端的交互还是HTTP 1.1,正在实施的是 HTTP 2.0。大家都是做互联网的,都有一个共识,一个是安全性,一个是在全站支持SSL的情况下,希望链接可复用的,而且现在spdy也在并入HTTP 2.0,我们想直接迈到这一步。

技术支撑最重要的一个就是基础的组件。我列举一下,类似于JimDB,基于Redis的缓存、持久化功能强大、完善的操作管理平台。还有ZK Cloud、Hermes、UDP,内部的数据收集如果没有非常强的精确性要求,我们内部的数据收集基本上都是走UDP,在内网UDP丢包率非常低,而且保证程序的性能。HttpDNS的目的是为了解决域名劫持的问题,现在更加发现,其实它能让流量调度功能更靠前,在前端进行非常好的流量监督。还有JvmDebuger,大家可以看看这些系统的截图。

(点击放大图像)

比如,这是ZK的管理工具、数据平台,可以实时配置,可以把数据展示在你面前。

(点击放大图像)

还有非常重要的是监控。我觉得监控对于互联网公司太重要了,基本是各个层面从操作系统到应用都是有监控的,而且我们的理念可以冗余,但不能没有,一个层面可以有多个监控。现在每个业务团队自己都开发很多的监控,但绝对不能冗余,对监控系统有要求的,要求监控的系统必须要有一个统一的协议,要接入简单,因为大家记住,我们要构建的是一个生态,这个生态里,学生入学了,想去实验室做实验,想去卫生间、去食堂,不知道路怎么走,不知道怎么去,何谈生态呢?

大家可以看看我们的监控,其中这是我们对于接口的监控,每天可能都能收到一些这样的短信,它可以通过短信、咚咚、京东内部的聊天工具,还有微信、邮件的方式展示给我们,还有一个图表,这个非常重要,可以看到流量的变化,能细化到接口甚至不同的版本,这是对HTTP连接池的平均,排队数、空闲数。

(点击放大图像)

容灾就是大致几个套路,快机房、数据备份的能力、流量的隔离要有不同的流量入口,入口之间可以切换,这是互联网冗灾最基本的常识。数据非常重要,一切的监控系统很多组件依托于数据,我们收集了全量的数据,通过实时计算平台,把这些数据变现,变成能对我们有利的一些图表、一些监控、一些安防系统,它的基础都是我们的数据。这个就是数据收集的一个过程,基本上通过UDP,我们有一个统一的UDP管理功能,通过界面来配置,这个数据定制到哪个系统,流程就是上线流程、发布流程、基础组件使用接入流程,来控制系统接入的风险。

流程保证

最后,基本上现在的流程都是通过工作流的过程,我们网关的接入流程审批,要把你的服务对外,走系统审批,要提交,而不是通过一个个邮件,这样非常原始了,现在基本上70%的系统都是采用工作流接入的方式去审批,需要团队的领导还有给你操作,比如说无线网关的审批,你的服务才能对外发布。而且我这里没有列举,我们接入的组件基本要求必须有全方位的监控接入,才能使用。

这个就是接入我们的ZK管理,使用ZK Cloud实现一个系统提交,形成一个工作流程的审批。这就是对于质能生态大致概括的图,我们有网关对外发布,我们的服务希望通过一个良好的协议上下非常好的交互,有很多的工具可以供你使用,可以有非常好的数据平台,有非常好的协议跟你交互,底层支撑有非常好的运营,可以冗灾、跨机房、数据备份。

(点击放大图像)

小结

总结一下,质量是我们永远考虑的第一要素,质量是一个综合体,我们说的速度、可用率都集成在这里,生态化的理念还在延续打造这个生态。我要再次强调,高精尖真的不一定能解决问题,不是我保守,但是希望你们能好好去考虑一下你们选型,团队风格非常重要,有风格的团队我相信能做好很多事。

京东无线服务端未来发展状况

我说一下非常简短的未来规划。大家知道4月22号开普勒的平台上线了,它就是京东把电商能力开放初期的里程碑,代表了京东开始把电商能力开放了。希望京东无线把所有强大能开放出去的电商能力,全都融入到我们的质能生态,为用户提供服务,你们的应用可以给京东下单,互惠互利,你能得到佣金,我们能得到开放给我们带来的流量,大家都能得到一个非常好的收益。

如果要开放,我们还有一些工作要做。首先,我们面向用户指标的分析。比如,接入我了,我要给你提供完备的数据分析平台,你接入,你的数据指标时间样,你的可用率多少,你的访问给我们带来了多少订单。其次,用户授权体系,这个不用深讲了,OAuth 2.0、还有更加实时的风控体系,现在也有风控,如果更开放了,我们的风控还要继续完善,对于这些恶意的流量对于用户合规、对于反作弊都需要有更深层次的加固。

嘉宾介绍

赵云霄,2006年毕业于河北工业大学,毕业后一直从事银行系统的开发与设计。2011年加入京东进入无线团队,负责服务端的开发与架构设计工作。见证并参与了京东无线从小到大,由弱到强的整个过程。五年间,带领团队完成了无线服务端的两次重大架构升级,无线服务端从一个简单的 Web 应用进化成为支撑每天几十亿级访问的分布式系统。目前负责京东无线网关系统的研发工作。专注于网络编程和后端基础系统的产品化平台化建设。一直坚信实践中才能得到真理,认为系统的发展的最终目标应该是可持续运营。业余时间喜欢旅行,喜欢看书,喜欢动物,尤其是猫,是个不折不扣的猫奴。


感谢陈兴璐对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

关于设计模式的评论比较有意思 by 孙 庚泽

记得设计模式推出的初衷就是为了让大家在讨论架构时有一个统一的名称,方便交流,结果现在设计模式反而变成交流的障碍了。。

一周上线两次,不觉得的恐怖吗 by Guan Seven

RT,这么频繁的发布,不能说明业务复杂,只能说明扩展性和配置能力远远不足。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT