构建企业级网关的时候与构建微服务网关的主要区别在于，往往需要将API网关用作统一网关，也就是意味着除了要接管微服务网关的限流和认证功能，从而达到给微服务网关瘦身的效果以外，还要能对接企业传统应用服务的集成平台中间件，例如ESB、PI等，当然零散的API接口对接会更多。所以作为一个统一网关，最容易被诟病的实际就是性能问题，并发问题等。今天我们不谈如何保障统一网关的可靠性、和高性能问题，今天主要谈一谈API网关的附加功能-缓存之道，尤其是对企业级网关，更是不能少了的一个重要组件。
API网关缓存之道
其一API网关的缓存是有效降低真正的API提供方的压力，从而一步步减少API服务提供者的应用容器、应用缓存和数据库的的压力。
其二API网关的缓存可以有效降低后台API的访问时间，从API网关直接访问缓存，如果命中缓存，那么就无需请求真正的API提供方，大大降低访问时间。
Figure-1-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：不满足走缓存条件。
Figure-2-API网关ProxyCaching
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网关的核心功能并不是缓存，但是在实际应用中，往往是新旧系统和服务都逐步接入到统一网关，除了加强安全认证、提供限流和熔断之外，我们还可以在后端并发和处理能力不够的情况下，将缓存前置来提供更好的服务，而且是从网关层统一处理，大大简化了后端服务处理的复杂度，因此在一些企业的实际应用中往往会发挥它独特的作用。
网友评论