构建企业级网关的时候与构建微服务网关的主要区别在于,往往需要将API网关用作统一网关,也就是意味着除了要接管微服务网关的限流和认证功能,从而达到给微服务网关瘦身的效果以外,还要能对接企业传统应用服务的集成平台中间件,例如ESB、PI等,当然零散的API接口对接会更多。所以作为一个统一网关,最容易被诟病的实际就是性能问题,并发问题等。今天我们不谈如何保障统一网关的可靠性、和高性能问题,今天主要谈一谈API网关的附加功能-缓存之道,尤其是对企业级网关,更是不能少了的一个重要组件。
API网关缓存之道
其一API网关的缓存是有效降低真正的API提供方的压力,从而一步步减少API服务提供者的应用容器、应用缓存和数据库的的压力。
其二API网关的缓存可以有效降低后台API的访问时间,从API网关直接访问缓存,如果命中缓存,那么就无需请求真正的API提供方,大大降低访问时间。
基于缓存的统一API网关工作步骤:
1、统一网关通过加载缓存模块,根据请求URL和参数解析,从网关缓存查询
2、如果缓存命中(缓存有效期内),那么直接返回统一网关
3、如果缓存未命中(缓存失效或者未缓存),那么请求真正的API服务提供者
4、请求结果返回网关
5、统一网关将请求结果缓存之网关缓存
API网关缓存之术
基于Nginx的Kong网关作为统一网关的定位之时,可以使用两种方式来构建网关缓存。
Proxy Caching
Kong网关提供了默认的Proxy caching功能,Proxy caching既可以以API为单位缓存也可以以服务消费方来进行缓存。
启用服务缓存
curl -X POST http://kong:8001/services/{service}/plugins \
--data "name=proxy-cache" \
--data "config.cache_ttl=300" \
--data "config.strategy=memory"
启用路由缓存
curl -X POST http://kong:8001/routes/{route}/plugins \
--data "name=proxy-cache" \
--data "config.cache_ttl=300" \
--data "config.strategy=memory"
启用消费者缓存
curl -X POST http://kong:8001/consumers/{consumer}/plugins \
--data "name=proxy-cache" \
--data "config.cache_ttl=300" \
--data "config.strategy=memory"
测试一下效果,可以看到缓存已经被Hit了,这里顺便补充一下缓存的状态:
Miss:请求满足走缓存条件(Method、content_type、vary_headers 、vary_query_params 满足了插件配置),但是这个资源在缓存中不存在。一般首次请求的时候返回Miss状态。
Hit:请求满足走缓存的条件同时缓存命中。
Refresh:请求走缓存满足条件,但是资源过期了或者Cache-Control的策略导致(例如请求设置了no-cache),从而导致必须走后端服务。
Bypass:不满足走缓存条件。
Redis Caching
使用Redis用作缓存,最好是使用Redis Cluster模式,OpenRestry提供的Redis模块是单机版的,要想使用Cluster模式就必须要先解决Redis Slot问题,github上目前已经有人贡献过了,具体可以参考https://github.com/steve0511/resty-redis-cluster,里面有详细的安装、配置指南以及简单样例代码。启用Redis Caching大致有一下几个步骤:
1、编写Redis的配置脚本
local config = {
name = "redisCluster", --rediscluster
name serv_list = { --redis cluster node list(host and port),
{ ip = "127.0.0.1", port = 7001 },
{ ip = "127.0.0.1", port = 7002 },
{ ip = "127.0.0.1", port = 7003 },
{ ip = "127.0.0.1", port = 7004 },
{ ip = "127.0.0.1", port = 7005 },
{ ip = "127.0.0.1", port = 7006 }
},
keepalive_timeout = 60000, --redis connection pool idle timeout
keepalive_cons = 1000, --redis connection pool size
connection_timout = 1000, --timeout while connecting
max_redirection = 5, --maximum retry attempts for redirection,
max_connection_attempts = 1, --maximum retry attempts for connection
auth = "pass" --set password while setting auth
}
2、编写url request的缓存脚本
由于代码量较大,这里将仅仅会把部分核心代码做分享,部分函数response、read_http、close_redis、validToken和auth未分享。
local redisCluster = require "resty.rediscluster"
-- 连接redis,失败转后端处理
local ok, err = redisCluster:new(config)
if not ok then
ngx_log(ngx_ERR, "connect to redis error : ", err)
read_http(ngx_var.request_uri)
end
-- 获取client_id,结合request_uri组成redis缓存key
client_id = token.client_id
-- cache_key,request_uri md5 key
local cache_key = 'api_clientid_'..client_id..'_request_uri_'..ngx.md5(ngx_var.request_uri)
-- 从nginx的共享内存中取数据(减少redis的tcp连接)
local content = ngx_shared_data:get(cache_key)
-- nginx共享内存有数据,直接返回
if content then
response(content,status,header)
end
-- nginx共享内存没有数据,则请求redis缓存
if not content or content == ngx.null then
ngx_log(ngx_ERR, "nginx shared memory not found content, back to reids, id : ", cache_key)
content = red:get(cache_key)
end
-- redis 没有数据,将请求转发到后端
if not content or content == ngx.null then
ngx_log(ngx_ERR, "redis not found content, back to http, request_uri : ", ngx_var.request_uri)
read_http(ngx_var.request_uri)
else
close_redis(red) -- 加入nginx共享缓存,worker共享
ngx_shared_data:set(cache_key,content,config.nginx.ngx_shared_timeout)
response(content,status,header)
end
3、配置Nginx启用Redis 缓存
这里也仅以示例表示,具体配置要结合响应的业务场景。
server{
location /api {
content_by_lua_file /app/webroot/luascript/content.lua;
}
}
API网关缓存之忌
1、简单缓存使用Proxy Caching,大量缓存建议Redis Caching。
2、使用Redis Caching要避免缓存穿透,这对应对恶意攻击的时候Redis自我保护很重要,否则会引起雪崩效应,具体解决方案可以cache null,但是这样会消耗更多的内存,对ttl设置的时间更加有要求。
3、如第2点所述,如果Redis Caching被缓存击穿,下一步就是缓存雪崩,这时候我们可以通过API消费者和服务者熔断的组合方式来保障Redis缓存本身的可用性,不至于把压力直接传导至真正的后台服务。
4、如果很不幸前两步都没有防住,那么事故就演变成了缓存击穿,对照图1,其实就是所有的请求不再经过步骤(1)和(2),而后台服务习惯性在API网关保护之下,大部分场景是没有做防击穿措施的,而此时API网关的缓存已经躺倒,但是向upstream转发应该不受影响,所以需要在API接入之前,就需要对核心API的开发方告知,如何做防击穿设计,这里不做赘述,可以使用互斥锁或者设置ttl=0即永不失效来解决,但是两者都有一些缺陷。
写在最后
API网关的核心功能并不是缓存,但是在实际应用中,往往是新旧系统和服务都逐步接入到统一网关,除了加强安全认证、提供限流和熔断之外,我们还可以在后端并发和处理能力不够的情况下,将缓存前置来提供更好的服务,而且是从网关层统一处理,大大简化了后端服务处理的复杂度,因此在一些企业的实际应用中往往会发挥它独特的作用。