The architect group exchange meeting is a technical exchange meeting attended by technical experts from well-known domestic companies. Each issue selects one of the most popular technical topics for practical experience sharing.
Phase 1: Docker practice sharing from architects from Hujiang, Didi, Mogujie and Scallop
The second phase: Practical sharing of high availability architecture from Didi, Weibo, Vipshop, Meizu, and Comments
Phase 3: Microservice Practice Sharing of JD.com and Home Delivery (Part 1) The third group exchange meeting invited domestic e-commerce leaders JD.com and the technical person in charge of Z-Express . They introduced the microservice practices of their respective products, and this time they discussed specific topics such as API gateway design, Dockerization of services, service testing, and continuous integration.
topic exchange
Q: How is the API Gateway designed?
Jingdong Zhang Geng: We have an HTTP gateway, but not a gateway for external network services. For external business, there are some gateways. For example, wireless has its own gateway, website has its own gateway, and another public gateway is a gateway called Jingdong Open Platform. Then what is our gateway used for? The main thing is a cross-language support, protocol forwarding and current limiting. The significance of the existence of this gateway is mainly to allow some callers to adjust the services of the server without using the Jeff protocol, or without relying on the server. The most important thing is the forwarding function of converting HTTP into an internal protocol. Secondly, we have made an interface-level isolation on it, so that you don't want to hang up the gateway with just one interface. Another is the current limit, how many times per minute. There is also authorization. The previous practice of gateway forwarding is generally similar to a VIP, and then a domain name is attached to the front. Then the list of services hanging behind the virtual IP is generally maintained manually. And our online shopping is automatically linked to this gateway, which is a service discovery, and our results. In terms of statistics, we will package it uniformly. Our gateway mainly does this function, and now it should be billions of dollars a day. The number of calls, 90 units, is about the same.
Service discovery is to read the service list in the database, and after reading it from the registry, it will be pushed to our gateway. Gateways are similar to callers. It's actually a caller, but it's a proxy caller. Its service list is also subscribed from our registry. It is not directly connected to the database and can be considered as the caller. The gateway goes to the registration center to read it for the first time, and we can push the changed part later. For example, if you have 1000 units originally, if you add one, you will pull 1001 units according to the idea of pulling before, and then you can compare it yourself and see which one is more. But we are not now, we are now adding one to him in reverse. In this case, reduce that by a large amount, as well as the push of network IO. Jingdong Zhang Geng: We want to use nginx+luaw to do a HTTP transfer to our internal JSF protocol, but it is not a worker or a process. There will be a lot of long links, so we gave up later. We are now doing a forwarding based on nitty, which is HTTP externally, and JSF protocol internally. It also does some authorization, current limiting, and thread isolation between services, service discovery, and one is the packaging of the result, which is packaged into a standard HTTP response. Because those on the Internet actually have their own systems, whether you are wireless or PC, they all have their own systems, and we don't need to do that. For the third party, it also has a development platform of JD.com, as well as a more stringent verification. Our API gateway is mainly for protocol conversion.
Q: How do you verify the legitimacy of the request, and what method do you use? Just how do you do that balance of efficiency and security?
JD. Zhang Geng: We have an authorization, that is, an application ID. JD.com has an application ID for each startup. If you come with that application ID, we can also support the token on your head. The kind that JD.com is open to is relatively strict to the outside world. We don’t need to be so strict. Anyway, it depends on who you are and who your gateway is used for.
Q: You now have two types, one is for internal calls, and the other is for external calls and internal calls to your system.
JD Zhang Geng: That is an open service. Some suppliers have internal systems. If you want to adjust JD's system, that is JD's open service, which requires Oauth authentication.
京东章耿：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 上。