upan / cheat-sheet

常用工具和开源项目链接收藏
33 stars 17 forks source link

Leo|20页PPT剖析唯品会API网关设计与实践 #20

Open upan opened 4 years ago

upan commented 4 years ago

https://mp.weixin.qq.com/s/gREMe-G7nqNJJLzbZ3ed3A 刘璟宇Leo

唯品会资深研发工程师,在大型高性能分布式系统设计和开发方面有丰富的经验。目前在唯品会平台与架构部负责唯品会API网关和服务安全方面的设计、开发、运营工作。

1. 为什么引入网关

img

唯品会是一家专门做特卖的网站,唯品会网站是一个巨大型的网站,每张页面背后,都有多个服务提供静态资源和动态数据。

这是唯品会网站上一张商品详情页面,内容是一款女式针织衫。页面里,除去静态页面、图片之外,有些动态内容:商品价格、促销提示语、产品介绍、商品库存等。每个部分都会从后端的一个或几个服务拉取数据。

在唯品会公司内部,已经采用服务化的方式把服务进行了拆分,内部服务之间采用基于thrift的二进制协议通讯。这些服务不能直接对外部提供服务。

在引入API网关前,我们在外部app、浏览器和内部服务之间会做一层webapp,起到两个作用:一个是从外部的http协议,适配到内部的二进制协议。另一个是对数据进行聚合。另外这些webapp里面还集成了如oauth等的一些公共服务。

img

由于唯品会网站的业务众多、业务量也非常大,这种webapp的数量有数百个,实例数量数千个。

在数量达到这种规模后,产生了一些问题,我们设想一个场景,比如某种安全防护技术需要升级一下,那么安全开发组需要先跟业务开发团队协商开发时间,等排期开发,然后需要测试,再排期发版。这样几十个业务开发团队升级下来,几个月可能就过去了。

再设想一个场景,例如,我可能想app支持一下二进制协议,可以提升数据交换效率。

一般我们做webapp,都是tomcat+springmvc这种结构进行开发,支持二进制协议就很困难。

所以,目前这种webapp的架构,对于公共服务集成升级和公共技术的升级不是很友好。

img

我们对架构进行了优化,引入了网关。网关的主要作用有三个:一个是协议适配;另一个是公共服务接入;最后是公共接入技术优化。在外网和内网中间有了网关,网关本身和业务程序分离,就可以独立的对这些技术进行集成和升级。

img

http://microservices.io/ 总结的微服务模式中,网关已经成为服务化中的一种标准模式。http://microservices.io/patterns/apigateway.html

img

网关模式,被一些大型的互联网公司采用。国内主要有唯品会、百度、阿里、京东、携程、有赞等,国外主要有Netflix, Amazon, Mashape等。

2. 选型和设计

img

开源网关按照平台可以分为基于nginx平台的网关和自研网关

基于nginx平台的网关有:KONG、API Umbrella

自研的网关有:apigee、StrongLoop、Zuul、Tyk

按照语言分类,可以见上图,有基于lua(nginx平台), nodejs, java, go等语言的网关。

img

基于nginx平台的网关和自研网关的优势和劣势如下:

基于nginx 自研
优势 1. nginx有完善的处理http协议的能力2. 全异步高性能基础处理能力3. http处理过程中多个扩展点可进行扩展4. 开箱即用,基于openresty开发相对简单 1. 可以完全掌控对http协议的处理过程2. 可以完全掌控异步化业务处理过程3. 对内部协议支持可以较好掌控4. 和内部的配置中心、注册中心结合较好
劣势 1. nginx工作流程复杂对大多数人来说,只能当作黑盒子用,出问题难以真正在代码级理解根本原因,扩展核心功能较为困难。2. 基于openresty扩展,本身有性能开销,对java、erlang、go的性能优势不明显3. 对内部协议和基础组件支持不方便 1. 对http协议处理有较多的坑需要踩2. 需要大量的性能优化过程,不像nginx经过大量实践,本身有较好的性能基础

唯品会网关是基于netty自研的API网关。

img

唯品会网关参考各种开源网关的实现,和业内各大电商网站的成熟经验,网关逻辑上可以分为四层:第一层是接入层,负责接入技术的优化。第二层是业务层,负责实现网关本身的一些业务实现。第三层是网关依赖的基于netty实现的各种公共组件最底层是netty负责NIO、内存管理、提供各种基础库、异步化框架等。

img

业务层前面跟大家分享过,主要包括路由、协议转换、安全、认证验签、加密解密等,大家一看估计就可以看出,这些业务逻辑已经划分的比较独立,可以按照模块进行划分。实际上我们也是这样做的。

业务层设计需要考虑哪些方面呢?

一方面,是流程的组织。另一方面,网关需要依赖外部服务,需要考虑怎样异步化的调用外部服务。最后,网关需要考虑高可用,高可用在程序设计方面主要是不停机发布。唯品会网关的所有业务配置,都可以通过管理界面动态管理、动态下发、动态生效,并且支持灰度。

img

业务层实现,最重要的一点,是将逻辑和数据分离,我们的实现方式,是业务逻辑实现在模块里,数据通过context传递,context通过模块之间相互调用时,通过接口传递。在异步化调用其他服务时,context保存在Channel的AttributeMap里,在异步完成时,回调,取出context。

有了最基本的模块设计,我们再来看唯品网关怎样设计把这些流程串在一起。

大家看一下上面的图,在执行业务逻辑时,有些业务逻辑需要串行,比如,路由校验、参数校验、IP黑白名单、WAF等,由于性能方面考虑,一般情况下,我们会先执行黑白名单模块,因为这块是cpu消耗最小、能拦掉部分请求的模块。

后面再执行路由、参数等的校验。这部分是内存运算,效率也比较高,也能拦掉一些非法请求,所以先执行。

然后进入outh、风控、设备指纹等的外部服务调用,这些调用将会并发的执行。

执行后,将进行结果合并校验,如果在认证验签或风控等校验未通过的情况下,将会直接返回,如果校验通过,再进入后续的服务调用。

服务调用过程,又进行了多选一的流程,可能用二进制协议也可能用HTTP协议等。最终进行后处理。

img

img

大家可能会想,这些模块看上去可以使用actor模式进行封装,为何没有使用开源异步框架呢?我们也对开源的异步框架进行了详细的调研。在将异步框架结合进网关时发现对网关的性能产生了一些影响。

目前较为流行的异步框架,主要有akka和quasar fibers。他们的实现形式不同,但原理基本差不多。

为什么唯品网关没有引入异步框架呢?一方面是引入异步框架后,网关的抖动增加。一方面是成熟度问题,quasar fibiers quasar fibers的模式,更加友好一些,可以以接近同步编程的模式实现异步编程。但最新的release是0.7.6,没有大规模的验证过,我们也在实际使用踩了一些坑,例如,注解的问题、代码织入冲突问题、长时间运行突然响应变慢问题,强烈建议大家如果生产使用,需要慎重再慎重。

我们总结了一下异步化框架适用于,大量依赖其他服务,经常被block的情况。

网关的瓶颈在cpu运算,因为有验签、加解密、协议转换等cpu密集运算,其他的调用已经是全异步的,所以,引入异步框架的收益并不明显。

上面分享了业务层的设计,下面分享一下公共组件的设计。

网关不论调用依赖的服务还是后端的服务,都会遇到大量并发调用的情况。如果对连接不加以复用和控制,将造成大量的资源消耗和性能问题。因此,唯品网关自己设计优化了连接池。

下面就分享一下唯品网关在连接池方面的设计。

img

img

连接复用主要是指,一个连接可以被多个使用者同时使用,且互相之间不受影响,可以并发的发送多个请求,而应答是异步的,可复用的连接一般用于私有协议的连接,因为可复用的连接,请求可以一直发送,应答也不一定是按照请求顺序进行应答,就带来了一个问题,应答怎样才能和请求对应上。私有协议就比较容易在协议包内,增加sequence id,所以能达到连接复用的要求。唯品会网关调用唯品会内部的私有协议服务时,就采用的这种连接复用模式。

连接复用还有一种实现模式,是spymemcache的模式,memcached本身不支持sequenceid,但同一个连接上的操作会保证顺序性,所以,spymemcache通过把请求缓存在queue中的形式,顺序匹配返回结果,达到连接复用。

img

独占的连接模式,主要是指,一个连接同一时间只能被一个使用者使用,在一个连接上,发送完一个请求后,必须等待应答后,才能发送第二个请求。一般使用HTTP协议时,比较多使用这种独占的模式。因为如果HTTP协议需要支持连接复用,需要在HTTP协议头上增加sequence id,一般的服务端都不支持这种扩展,所以,我们针对HTTP协议,使用的是独占连接模式。

img

连接池的异步化,在连接池使用的所有阶段都应该异步化。我们在设计网关的连接池时,考虑了以下几个方面:获取连接的异步化。从连接池获取连接,一般情况被认为是个没有block的动作,实际上分解来看,获取连接池,可能需要锁连接池对象所在的队列,操作连接池计数器时,可能会遇到锁、超时等问题。后面我会跟大家分享我们怎样去做的优化。连接使用就是说实际用连接去调用其他服务,这块的异步化,大家基本都会考虑到。归还连接的异步化。归还连接时,也会操作连接池中的连接队列,有时连接已经异常还会执行关闭连接等动作,所以也会产生锁的问题。和获取连接时类似,我们也把操作封装为task,交由netty做cpu亲缘性路由。

img

3. 实践经验

上面是给大家分享了我们在连接池设计中的几个关键点,接下来跟大家分享一下我们在实践过程中实际进行的优化。

img

jvm启动后,会在/tmp下建立一个文件,是一个内存映射文件,JVM用来导出状态数据给其它进程使用,比如jstat,jconsole等。当到达安全点时,JVM会把安全点的相关信息写入到这个文件中去。安全点是说,jvm会在这个点上,把所有其他线程都停下来,自己安全的做一些事情,GC是一种安全点,还有其他种类的安全点。而gc log和这种监控数据的写入,就是在安全点上进行写入。当IO频发且负载均重时,可能写数据动作刚好赶上操作系统将磁盘缓存刷到磁盘的过程,此时写性能数据文件的操作就会被block。最终表现为jvm暂停。解决方法,是将这些性能数据写到内存文件中,避免和其他操作抢占磁盘io。

StringBuffer在写日志等处理字符串拼接的场景下经常用到,大多数情况下,我们会new一个StringBuffer,向里面追加字符串,在高并发场景,这个过程会产生大量的内存重新分配并拷贝内容的动作,造成cpu热点。我们的优化方法是,在threadlocal缓存使用过的stringbuffer,在下次使用时,直接复用。

我们在初期实际使用网关时观察到,网关的OLD区使用会缓慢上升,大概两天会产生一次FGC,经过仔细的分析,发现,java NIO的server socket类由finalize最后进行释放。而GC过程是第一次GC先将没有引用的对象放入finalize队列,下次GC的时候,调用finalize,并将对象释放。而在高并发的情况下,server socket的finalize并不保证被调用,所以存活时间可能超过了升级阈值,就会有对象不断进入old区。

即使ref queue很快被执行,也可能跨两次ygc,比如创建后接着一次ygc1,然后用完后在下一次ygc2中添加到ref queue,ref queue没有堆积的情况下,需要在ygc3中释放这些对象。

img

由于网关会并发接受大量的请求,所以写日志的量非常大。我们实际压测的时候发现,写日志的IO操作,会周期性的被block,从而产生抖动。经过分析发现,被block的时候,操作系统在刷磁盘缓存。linux默认是脏数据超过10%,或5s刷一次缓存,而这时可能会有大量数据在缓存里等待写入磁盘,操作系统再去刷盘的时候,就会消耗比较多的时间,而这些时间内,应用无法将数据写入磁盘缓存,发生block。有两个参数可以调整,一个是脏数据占比,一个是脏数据两个取较小值生效。我们通过调小脏数据比率,让刷盘动作在数据量较小的时候就开始,减小了毛刺率。