京东、宅急送的微服务实践分享（下）| 架构师小组交流会

架构师小组交流会是由国内知名公司技术专家参与的技术交流会，每期选择一个时下最热门的技术话题进行实践经验分享。

第三期小组交流会邀请到了国内电商领头羊京东、宅急送技术负责人，在上篇京东、宅急送的微服务实践分享（上）中他们介绍了各自产品的微服务实践，本次他们就 API 网关的设计、服务的 Docker 化、服务测试、持续集成等具体话题展开了讨论。

话题交流

Q ： API 网关是怎么设计的？

京东章耿：我们有个 HTTP 的网关，但不是一个对外网服务的一个网关。对外的话业务自己都有一些网关，例如无线有自己的网关，网站有自己的网关，而另外一个公共的开放的是一个叫京东开放平台的网关。然后我们的网关干嘛用的？主要做的就是一个跨语言支持用的，协议转发和限流。这个网关存在的意义，主要是为了让有的调用端不用杰夫协议，或者不依赖服务端的情况下，来调服务端的服务。最主要就是刚才说那个 HTTP 转成内部协议的一个转发的功能，其次我们在上面做了一个接口级隔离，不要一个接口就把网关搞挂。还有一个就是限流，每分钟调多少次。还有授权，以前的网关转发的做法，一般是比如说类似于一个 VIP ，然后前面挂个域名。然后那个虚 IP 后面挂的服务列表一般都是要手动维护上。而我们的网购自动就挂到这个网关上面，就是一个服务发现，还有就是我们的结果，统计方面，我们会统一包装一下，我们的网关主要是做这个功能，现在一天应该是几十亿的调用量，九十台，差不多这些。

服务发现是到数据库里面去读服务列表，从注册中心读出来以后会推给我们的网关。网关跟调用者是类似的。它其实也是一个调用者，只不过它是一个代理的调用者。它的服务列表，也是从我们的注册中心订阅的，不直接连数据库，可以认为自己是调用者。网关第一次去注册中心去读，后面的话我们可以推变化的部分。比如说你原来 1000 台，你要是加了一台，按以前拉的思路你会拉 1001 台，然后你自己比较一下，多了哪一台。但我们现在不是，我们现在是反向给他推加一台。这样的话，大量的减少那个，还有网络 IO 的推送。京东章耿：我们想用 nginx+luaw 做一个 HTTP 转我们内部 JSF 协议的，但不是 worker 就是一个进程。会产生很多长链接，所以我们后来就放弃了，我们现在是基于 nitty 做了一个转发，就是对外是 HTTP ，对内就 JSF 协议。也做了一些授权，限流，还有服务之间的线程隔离，服务发现，还有一个是结果的包装，包装成标准的 HTTP 的响应。因为像对外网的那些其实都是有自己的系统，不管你是无线，还是 PC 他都有自己的系统，那个不需要我们做。对第三方的话，它也有其中京东一个开发平台，还有更严格的那个验证，我们这个主要还是做协议转换的 API 网关。

Q ：你们怎么验证请求的合法性的，你们采用什么方法？就是就那种效率与安全性的这种平衡你们怎么做的？

京东章耿：我们是有个授权，就是有个应用 ID ，京东是每个启动的都有个应用 ID ，带着那个应用 ID 过来，我们也可以支持头上带 token 。京东开放的那种是对外比较严格，我们这个不需要那么严格，反正就看你对象，就看你的网关给谁用了。

Q ：你们现在有两种类型，一种是内部之间调用的，另外一部分是外部调用内部的调用你们系统。 京东章耿：那个是开放服务，有些供应商内部的系统，想要调京东的系统，那种就是京东开放服务，是需要 Oauth 认证。

京东章耿：HTTP+keepalive 也挺快的，因为它无非就是头上大一点， HTTP 的头大了一点。但如果后台是调 redis 那就比较明显的感觉，那如果后台是一个有个几百毫秒的，那你感觉不到那么明显。如果后台，你这就是读不取一下，读一下 redis ，你感觉比较明显。我们这边是用 netty 做的 HTTP 跟二进制都是在同一个端口支持的。

Q ：你怎么划分，哪些用二进制的，那些用 restful 协议的呢？

京东章耿：那个我们没有强制要求，业务它自己想用什么用什么。 京东章耿：对我们来说，它一启动端线口它就支持这两种协议。启动同一个端口，两种协议都支撑的。

Q ：你们是怎么区分一种端口种协议的呢？

京东章耿：每个数据包括头上前两位不是模数位吗？它们都有自己的模数位。然后我们自己协议有自己的模数位，你 HTTP 就是那几个打头的 H ，然后我们的 decode 是自动装载的，它不是说你可以一开始装载一个什么那是适配器 decode 。当你请求来的时候，你再自动装载量，因为我们是超链接，不管你是 HTTP ，我们一般都默认开启 keepalive 也是个超链接。其实，你可以知道这个长链接对应的是什么协议。

Q ：它一般保持稳定的一个超链接，肯定是一种协议持续下去，不可能说动态的变质。

京东章耿：是，看效率要求，其实 HTTP keepalive 也还可以，性能也还可以，如果不是那种调量特别特别大的话，它效率也还是可以的。然后 debug 的时候可能可读性会好一点。二进制最大问题还是比较麻烦，特别是，我们现在用 message pack ，然后会生成一堆的代理类，模板类，反正问题也比较麻烦。

宅急送石廷鑫：我们都用 Spring cloud 的那一套，然后自个改了一部分东西。像 Consul 好像也和 Zookeeper 一样的问题，所以说后边都改造数据库了。我现在用的是开源的 eureka ，只是后边从属变了。目前来说还没发现问题，因为我没有跨机房的问题。如果是跨机房的话，基本上都是数据库同步，两个数据之间同步的问题。

京东章耿：一般我们是有一个功能服务降级，其实最主要还是业务部门自己的代码实现，那我们其实有提供一个 mok 功能，就是那在我们配置这边直接配上一个，如果这个接口不可用返回的什么东西有没有开关，这也是可以。但是这个用起来比较少，一般他们自己在业务代码上也是容错的，就是没有说从平台这种角度去搞，一般都是自己考虑。然后如果是有一个目视跟踪系统的话，就一般的也可以跟踪整个调用链，就会看出来这个。比如说这个接口它依赖其他的接口，然后京东其实是没有投资这么细，因为目前我们分公司跟踪还没有上，我们现在主要是依赖我们内部的一个应用管理系统，我们叫 JOne ，有点像自动部署。我们每个进程启动的时候都会带上这个应用 ID ，在我们管理端是能看到这个接口是属于哪个应用的，我们只能看到应用级别的，这个应用调了哪些接口？哪些接口依赖？调的那些接口还被谁调用了？到这个级别。

宅急送石廷鑫：我们用 Springcloud ，熔断机制的降级处理的话,它有一个统计的接口，基本上按那个规则来做。调用关系的话，一个是我们做了一个 trace ID ，就是 google zipkin ，它本身有自带的工具。还有一部分就是服务的排层，我们现在就是用 camel 来做的，把这个业务整个来排层次做，大体是这样。目前来说，大的情况就是监控时会有一些出经常会出现一些抖动。就比方说 trace ID 那部分，不能用它自带的 stream 的模式。我们现在还是用 elk 来做，然后把 trace ID 打出来，然后做了一套简单的监控，类似于模仿它整个 trace 的路径。当然不要用 google 自带的监控，我们发现机器多了自带的监控不太可靠。我们都是做到日志里面，然后用 elk 收集起来。说起来自个做一个监控的调用量，这个就是稍微有点延迟。

京东章耿：我们这边最近正在做，然后我们的思路是这样的。有个包放在应用里面，它会输出日志，然后我们有一个日志收集，原来就有日志收集的我们只是扩展了一下。在每台机子上把它收到一个 kafka 里面，然后后面是用一个 storm 去把它读出来，写到 H base 里做分析，然后我们是有个采样率的一个概念，比如说一千次，才写一次，或者是一万次才写一次，做个采样率。然后最终我们现在是分两部分，刚才说写 H base 是一个离线数据，其实我们还有一些简单例子，就是直接做一些统计，实时的，大概延迟在一分钟左右。

Q ：关于服务的 Docker 化有什么进展？

京东章耿：我们主要还是应用级别的 Docker 。现在只是说，可能这种发布模式会改一下。现在是基于一个 Docker VM ，比如说你起来以后，其实整个镜像文件都在那里。然后你弹的时候其实还是比较慢的。比如我要扩的话，得先创建一个 Docker 的 VM ，再把那些东西复制进去，才能有个装机的过程。就是比较慢一点，可能得分钟级别才能把它给提起来。但是未来我们希望把它改用镜像的那种形式，就你上线完成以后，生成一个镜像。每次上线，你只需要布一台机器，后面全是复制的一个过程。未来会改成这样，估计今年开发，明年推。现在相当于要布 20 个节点，那相当于是给你 20 个 Docker VM ，你上线发布 20 次，未来是希望给你一个，然后你发布一次以后，系统自动给你复制 19 个。而且反正后面服务发现什么这些都是原生的，都是无所谓的。

京东章耿：京东的 Docker 主要解决资源调度的问题。就相当于现在部物理机，你可能自己要需要部署机器。但 Docker 可以把资源分配均匀一点，用算法给算出来，在分配时不会分到同一个机架上，不会分到同一个主机上，还有不会分到很繁忙的机器上。这些都会帮你考虑一下。

京东章耿：京东这边是自己有一套部署系统，虽然他没有像你说就镜像这样发布，虽然没这么快，但对于我们开发人员上线来说，其实是一样的，他只需要配一下，然后一点，他 24 台自动就上去了，就是有一套工具，也很快。只不过，他需要提前创建好，比如说你刚才说 20 个，你要提前创建 20 个 VM 。就比镜像的话肯定是要慢在这一步，你镜像的话，你直接拉下来一起，然后可以调度到哪台机子上到个 Docker API 一调，他直接就提起来了，那也是我们未来的改变方向。

七牛陈爱珍：我们的数据处理系统系统上运行的都是 CPU 密集型的计算，获取一个原文件，进行数据处理算法的执行，比如对一个视频进行转码，而在转码的过程中需要大量的 CPU 资源来进行处理，处理完后就可以获得预设的文件样式。不同的数据处理对资源的需求是不一样的，比如获取一个文件的 hash 值，这个处理逻辑非常简单，也没有大量的运算，配置的资源就相对小一些，而视频转码则非常的复杂，配置的资源就会相对多一些。现在在我们的平台上运行了数千种数据处理应用，每种处理的的请求量不一样，比如有些图片处理每秒可以达到数十万的请求量，而有一些则可能是每秒几万的请求量，几千种数据处理应用的高峰期也不一样，有些可能在早上，有些可能在晚上，并且每种处理都会存在突发流量的情况，比如一些电商型的客户，在做大促销时，就会导致图片处理的请求量突增，而一些音视频的客户在会在一些活动时会突然增长对音视频的处理。

这个系统的核心问题是如何把硬件资源对每一种应用不同高峰期的请求量和突发流量做合理的资源分配，不合理的资源分配就可能会造成资源的浪费，或导致负载过重的机器会宕机，不能及时响应用户的需求。原有的系统架构的资源是静态规划的，也就是把指定的资源给指定的应用使用，而这种资源的分配往往是按照每个应用的业务高峰进行规划的，为了应对突发的流量并会预设一定的冗余，那么这样就会需要准备很多的资源。后来我们使用容器，因为容器可以封装环境，动态迁移，底层使用 Mesos 做资源的调度，这就可以对整个环境按需动态分配，很好的解决了资源利用率的问题。

Q ：关于服务测试、持续集成，大家分享一下实践经验吧。

京东章耿：持续集成我们这边其实在编译环节就做了，上线我们这边是有一个灰度上线功能。我们有一个预发布环节，它可以直接把它标记为预发，然后有个测试平台可以对它进行一个服务的测试。那如果是正式环境的话，那就他就得自己想办法，因为我们现在这个环节是不能随便测试的，因为我无法判断你这个是读还是写，我不能让你随便测。

Q ：因为你们是把一个业务系统拆成了很多这种服务化的服务去跑，那肯定是要涉及到这种单元测试、集成测试和业务流的这种测试，那这种测试的话你们都是怎么做的呢？

京东章耿：这边都是提前测的，就是你测都没测，那你根本就提不到上线这一步。你上线的时候必须有一个测试审批通过，其实他其实就是已经在线下就测过了。

七牛陈爱珍：我们是基于 Jenkins 做的持续集成，把代码上传到 Github 后，会做自动的代码静态检查和单元测试，再做自动的集成测试。这样的好处是开发只需要开发代码，不需要构建环境，都是自动完成的，而且反馈的速度也会非常快速。

宅急送石廷鑫：测试环境是由开发人员去部署，线上正式环节，是从这个测试环境把报测试通过去的，直接拷贝过去。我觉得 Docker 是解决整个配置的问题，因为生产环境测试环境和开发环境不一样。配置环境这个东西很难很麻烦做的，尽可能就是 UAT 的环境和测试环境，就是用户测试的环境和线上的环境尽量是一样。现在不是有配置管理吗？这三个环境能来回切换。比方说 spring boot 这种，实际上就是一个 Jar 包命令。 Jar 包命令唯一不同的就是它的配置问题，你只要一上线，那边一监控就可以看到。因为你启动时候他有注册，注册基本上他要调哪些东西就能看到他注册的配置。

京东章耿：京东测试环境，预发，线上都是从源码库里编译为准。主干编译为准，所以说代码应该是一样的。线上配置我们是管理在配置中心，但是目前我们测试环境就没有这个东西。预发，线上有配置中心，这个配置中心也集成到我们那个发布平台 JOne 上。