原文地址：https://609518.kuaizhan.com/86/70/p4108366952248f

刘璟宇Leo

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

　　内容解析

　　1. 为什么引入网关

　　

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

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

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

　　在引入API网关前，我们在外部app、浏览器和内部服务之间会做一层webapp，起到两个作用：

　　一个是从外部的http协议，适配到内部的二进制协议。

　　另一个是对数据进行聚合。

　　另外这些webapp里面还集成了如oauth等的一些公共服务。

　　

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

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

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

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

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

　　

　　我们对架构进行了优化，引入了网关。网关的主要作用有三个：

　　一个是协议适配

　　另一个是公共服务接入

　　最后是公共接入技术优化

　　在外网和内网中间有了网关，网关本身和业务程序分离，就可以独立的对这些技术进行集成和升级。

　　

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

　　

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

　　2. 选型和设计

　　

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

　　基于nginx平台的网关有：

　　KONG

　　API Umbrella

　　自研的网关有：

　　apigee

　　StrongLoop

　　Zuul

　　Tyk

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

　　

　　基于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网关。

　　

　　唯品会网关参考各种开源网关的实现，和业内各大电商网站的成熟经验，网关逻辑上可以分为四层；

　　第一层是接入层，负责接入技术的优化。

　　第二层是业务层，负责实现网关本身的一些业务实现。

　　第三层是网关依赖的基于netty实现的各种公共组件。

　　最底层是netty负责NIO、内存管理、提供各种基础库、异步化框架等。

　　

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

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

　　一方面，是流程的组织。

　　另一方面，网关需要依赖外部服务，需要考虑怎样异步化的调用外部服务。

　　最后，网关需要考虑高可用，高可用在程序设计方面主要是不停机发布。唯品会网关的所有业务配置，都可以通过管理界面动态管理、动态下发、动态生效，并且支持灰度。

　　

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

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

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

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

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

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

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

　　

　　

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

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

　　为什么唯品网关没有引入异步框架呢。

　　一方面是引入异步框架后，网关的抖动增加。

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

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

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

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

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

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

　　

　　

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

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

　　

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

　　

　　连接池的异步化，在连接池使用的所有阶段都应该异步化。我们在设计网关的连接池时，考虑了以下几个方面：

　　获取连接的异步化。从连接池获取连接，一般情况被认为是个没有block的动作，实际上分解来看，获取连接池，可能需要锁连接池对象所在的队列，操作连接池计数器时，可能会遇到锁、超时等问题。后面我会跟大家分享我们怎样去做的优化。

　　连接使用就是说实际用连接去调用其他服务，这块的异步化，大家基本都会考虑到。

　　归还连接的异步化。归还连接时，也会操作连接池中的连接队列，有时连接已经异常还会执行关闭连接等动作，所以也会产生锁的问题。和获取连接时类似，我们也把操作封装为task，交由netty做cpu亲缘性路由。

　　

　　3. 实践经验

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

　　

　　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中释放这些对象。

　　

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