来自京东、宅急送对微服务编排、API网关、持续集成的实践分享(下)

标签: 京东 宅急送 微服务 | 发表时间:2017-02-07 11:25 | 作者:Myl123
出处:http://www.iteye.com
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享。

第三期:微服务。微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注。它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成。我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况。

嘉宾:京东章耿、宅急送石廷鑫、七牛陈爱珍
本文是对此次交流的整理,分了上下两篇文章。

第二轮:话题交流
主持人:API 网关是怎么设计的?
京东章耿:我们有个 HTTP 的网关,但不是一个对外网服务的一个网关。对外的话业务自己都有一些网关,例如无线有自己的网关,网站有自己的网关,而另外一个公共的开放的是一个叫京东开放平台的网关。然后我们的网关干嘛用的?主要做的就是一个跨语言支持用的,协议转发和限流。这个网关存在的意义,主要是为了让有的调用端不用杰夫协议,或者不依赖服务端的情况下,来调服务端的服务。

最主要就是刚才说那个 HTTP 转成内部协议的一个转发的功能,其次我们在上面做了一个接口级隔离,不要一个接口就把网关搞挂。还有一个就是限流,每分钟调多少次。还有授权,以前的网关转发的做法,一般是比如说类似于一个 VIP,然后前面挂个域名。然后那个虚 IP 后面挂的服务列表一般都是要手动维护上。而我们的网购自动就挂到这个网关上面,就是一个服务发现,还有就是我们的结果,统计方面,我们会统一包装一下,我们的网关主要是做这个功能,现在一天应该是几十亿的调用量,九十台,差不多这些。

服务发现是到数据库里面去读服务列表,从注册中心读出来以后会推给我们的网关。网关跟调用者是类似的。它其实也是一个调用者,只不过它是一个代理的调用者。它的服务列表,也是从我们的注册中心订阅的,不直接连数据库,可以认为自己是调用者。网关第一次去注册中心去读,后面的话我们可以推变化的部分。比如说你原来 1000 台,你要是加了一台,按以前拉的思路你会拉 1001 台,然后你自己比较一下,多了哪一台。但我们现在不是,我们现在是反向给他推加一台。这样的话,大量的减少那个,还有网络 IO 的推送。

京东章耿:我们想用 nginx+luaw 做一个 HTTP 转我们内部 JSF 协议的,但不是 worker 就是一个进程。会产生很多长链接,所以我们后来就放弃了,我们现在是基于 nitty 做了一个转发,就是对外是 HTTP,对内就 JSF 协议。也做了一些授权,限流,还有服务之间的线程隔离,服务发现,还有一个是结果的包装,包装成标准的 HTTP 的响应。因为像对外网的那些其实都是有自己的系统,不管你是无线,还是 PC 他都有自己的系统,那个不需要我们做。对第三方的话,它也有其中京东一个开发平台,还有更严格的那个验证,我们这个主要还是做协议转换的 API 网关。


主持人:你们怎么验证请求的合法性的,你们采用什么方法?就是就那种效率与安全性的这种平衡你们怎么做的?

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

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

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


主持人:你怎么划分,哪些用二进制的,那些用 restful 协议的呢?

京东章耿:那个我们没有强制要求,业务它自己想用什么用什么。

京东章耿:对我们来说,它一启动端线口它就支持这两种协议。启动同一个端口,两种协议都支撑的。

主持人:你们是怎么区分一种端口种协议的呢?

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


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

京东章耿:是,看效率要求,其实 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 是一个离线数据,其实我们还有一些简单例子,就是直接做一些统计,实时的,大概延迟在一分钟左右。

主持人:关于服务的 Docker 化有什么进展?

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

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

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

七牛陈爱珍:我们的数据处理系统系统上运行的都是 CPU 密集型的计算,获取一个原文件,进行数据处理算法的执行,比如对一个视频进行转码,而在转码的过程中需要大量的 CPU 资源来进行处理,处理完后就可以获得预设的文件样式。不同的数据处理对资源的需求是不一样的,比如获取一个文件的 hash 值,这个处理逻辑非常简单,也没有大量的运算,配置的资源就相对小一些,而视频转码则非常的复杂,配置的资源就会相对多一些。

现在在我们的平台上运行了数千种数据处理应用,每种处理的的请求量不一样,比如有些图片处理每秒可以达到数十万的请求量,而有一些则可能是每秒几万的请求量,几千种数据处理应用的高峰期也不一样,有些可能在早上,有些可能在晚上,并且每种处理都会存在突发流量的情况,比如一些电商型的客户,在做大促销时,就会导致图片处理的请求量突增,而一些音视频的客户在会在一些活动时会突然增长对音视频的处理。

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


主持人:关于服务测试、持续集成,大家分享一下实践经验吧。

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

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

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

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

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

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


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [京东 宅急送 微服务] 推荐:

来自京东、宅急送对微服务编排、API网关、持续集成的实践分享(下)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

来自京东、唯品会对微服务编排、API网关、持续集成的实践分享(上)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

京东京麦:微服务架构下的高可用网关与容错实践(有彩蛋)

- -
本文根据DBAplus社群第130期线上分享整理而成,. 从事京麦平台的架构设计与开发工作. 熟悉各种开源软件架构,在Web开发,架构优化上有较丰富的实战经历. 有多年在NIO领域的设计、开发经验,对HTTP、TCP长连接技术有深入研究与领悟,目前主要致力于移动与PC平台网关技术的优化与实现. 个人公众号:程序架道(xindongbook17).

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务拆分之道

- - DockOne.io
微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会. 在做微服务的路上,拆分服务是个很热的话题. 我们应该按照什么原则将现有的业务进行拆分. 接下来一起谈谈服务拆分的策略和坚持的原则.

微服务之saga模式

- -
你已经使用 database ber service 模式. 每个service拥有自己的database. 一些业务事务会跨越多个service,所以你需要来确保data consistency. 例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务.