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

在 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 ）关注我们。