apigateway-kong(五)集群搭建部署

  kong 集群将使得系统通过增加更多机器,从而实现水平扩展,承接更多的请求流量。它们将共享同样的配置且使用同一个数据库。kong 集群中的的所有节点都连接同一个数据库。

你需要在 kong 集群的上一层架设一个负载均衡的代理服务器,以便请求能够平均分散转发到 kong 的各个节点上。

    • 一.kong 集群能做什么和不能做什么
    • 二.单节点 kong 集群
    • 三.多节点 kong 集群
    • 四.什么是缓存
    • 五.如何配置数据库缓存 
      • 1.db_update_frequency
      • 2.db_update_propagation
      • 3.db_cache_ttl
      • 4.当使用 Cassandra 数据库
    • 六.通过Admin api 操作缓存 
      • 1.检查一个缓存值
      • 2.清理一个缓存值
      • 3.清理一个节点的缓存
    • 七.集群搭建

一.kong 集群能做什么和不能做什么

  拥有Kong群集并不意味着客户端流量将在开箱即用的Kong节点中实现负载平衡,仍然需要在Kong节点前面使用负载平衡器来分配流量。相反,Kong群集意味着这些节点将共享相同的配置。

出于性能原因,Kong在代理请求时避免数据库连接,并将数据库的内容缓存到内存中。cached实体包括services,routes,consumers,plugins,credentials等...由于这些值在内存中,因此通过其中一个节点的Admin API进行的任何更改都需要传播到其他节点。

  本文档将介绍,如何使得这些本地缓存失效,并且如何配置 kong 集群节点,以便支持更多的使用场景,从而在性能和数据强一致性两方面做出平衡的选择。

二.单节点kong 集群

  只有一个 kong 节点连接数据库(Cassandra或PostgreSQL)的单节点 kong 集群,任何通过 Admin api 的更改,都会立即全局生效。比如:

假设只有一个kong单节点A ,如果我们删除一个已经注册的Service:

$ curl -X DELETE http://127.0.0.1:8001/services/test-service

随后任何关于 kong节点A 请求都将会返回 “404 Not Found”,因为该节点已经在本地删除中清除了缓存。

$ curl -i http://127.0.0.1:8000/test-service

三.多节点kong 集群

  在一个多节点 kong 集群中,当我们通过A 节点的Admin api删除某条信息,其他节点虽然都连接同一个数据库,但由于本地缓存存在,所以并不会立即生效。虽然API 不再存储在数据库中(通过A 节点的Admin api 删除的),但它仍然存在 B以及其他节点的内存中。

所有节点将会周期性执行后台同步任务,同步其他节点触发的变化。该同步任务执行频率可以通过配置下面的配置项:

◦ db_update_frequency (默认: 5 秒)

每 db_update_frequency 秒,所有 kong 节点将从数据库中拉取所有更新,如果有同步到更新变化,将清理本地相关缓存。

如果我们通过 kong-A 节点删除一个 API,这个更新变化将不会立即在 B 节点生效,直到 B 节点下一次从数据库拉取变更,这将会是在db_update_frequency 秒后才会发生(也有可能会更早)。

这个过程将会使 kong 集群最终保持一致性。

四.什么是缓存

  所有核心实体(如服务,路由,插件,消费者,凭证)都由Kong存储在内存中,缓存失效则依赖后台任务同步更新。此外,kong 也会缓存数据库遗漏(数据库中有的数据,但本地不存在的)。这意味着如果你配置一个没有插件的服务,Kong会缓存这些信息。例:

在节点A上,我们添加一个Service和一个Route

# node A
$ curl -X POST http://127.0.0.1:8001/services \
    --data "name=example-service" \
    --data "url=http://example.com"

$ curl -X POST http://127.0.0.1:8001/services/example-service/routes \
    --data "paths[]=/example"

(请注意,我们使用/services/example-service/routes作为快捷方式:也可以使用/routes endpoint代替,但我们需要将service_id作为参数传递给新服务的UUID。)

对节点A和节点B的代理端口的请求将缓存该服务,并且没有在其上配置插件:

# node A
$ curl http://127.0.0.1:8000/example
HTTP 200 OK
...

# node B
$ curl http://127.0.0.2:8000/example
HTTP 200 OK
...


现在,假设我们通过节点A的管理API向该服务添加一个插件:

# node A
$ curl -X POST http://127.0.0.1:8001/services/example-service/plugins \
    --data "name=example-plugin"


由于此请求是通过节点A的Admin API发出的,因此节点A将在本地使其缓存无效,并在随后的请求中检测到此API配置了插件。

但是,kong-B 节点还没有执行数据库同步更新缓存任务,本地缓存的API信息并没有配置插件,直到 kong-B 节点执行数据库同步操作之后,API新增插件的功能才会生效。

结论:所有CRUD操作都会触发缓存失效。创建(POST,PUT)将使缓存的数据库未命中失效,更新/删除(PATCH,DELETE)将使缓存的数据库命中无效。

五.怎样配置DB缓存

  可以在Kong配置文件中配置3个属性,其中最重要的一个属性是db_update_frequency,它决定了Kong节点在性能与一致性之间的权衡。  

  kong 已经提供了默认的配置,为了让你权衡集群性能和数据一致性两个方面,避免意外的结果。你可以按照下面的配置步骤,改变配置的值,从而确保性能和数据一致性能够被接受。

  • 1.db_update_frequency (default: 5s)

该配置决定 kong 节点从数据库拉取缓存无效事件,同步任务执行的频率。一个更小的值意味着同步任务将会更频繁的执行,kong 节点的缓存数据将保持和数据库更强的一致性。一个更大的值,意味着你的 kong 节点花更少的时间去处理同步任务,从而更加将更多资源集中去处理请求。

Note:变更将会在db_update_frequency 秒后在整个集群节点中生效。

  • 2.db_update_propagation (default: 0s)

如果你的数据库也是集群的并且最终一致性的(比如:Cassandra),你必须配置该值。它将确保db_update_propagation秒后,数据库节点间的变化在整个数据库集群中所有节点生效。当配置了该值,kong 节点从同步任务中接收无效事件,清除本地缓存将会延迟 db_update_propagation 秒。

如果一个 kong 节点连接到最终一致性数据库上,且没有延迟事件需要处理,它可能会清除缓存,然后把没有更新的值再次缓存起来。(因为这个改变还没有传播到数据库集群的每一个节点,注释:数据库一致性还没有在数据库集群中达到一致,此时kong缓存到期了,但是没有更新到变化事件,此时会把没有更新的值再次缓存起来,导致kong也出现不一致,即便kong执行了同步任务。)。

你应该配置该值,通过评估数据库集群发生变更后,最终达到一致性所需要的时间。(确保数据库一致之后,才去执行 kong 同步任务处理变更事件,从而达到kong 数据一致性)

Note:当配置了该配置项,数据变更传播到 kong 集群的最大时间是 db_update_frequency + db_update_propagation 秒。

  • 3.db_cache_ttl (default: 3600s)

该配置项的时间(单位秒)是 kong 缓存数据库实体的时间(包括缓存命中或者穿透),该存活时间是一种保护措施,以防 kong 节点漏掉处理缓存无效事件,避免旧数据长时间没有被清理。当缓存生存时间到了,缓存值将会被清理掉,下一次将会从数据库读取数据并再次缓存起来。

  • 4.当使用 Cassandra 数据库

如果使用 Cassandra 作为 kong 的数据库,你必须配置 db_update_propagation 为一个非零值。由于 Cassandra 本身是最终一致性数据库,这将确保 kong 节点不会过早地使本地缓存失效,仅仅当再次获取到一个不是最新值的时候。如果你使用了 Cassandra 但你没有配置该值时,kong 将会输出一条警告日志。

此外,你可以配置 cassandra_consistency 的值为:比如 QUORUM 或者 LOCAL_QUORUM,确保被kong 缓存的值是数据库中最新的。 

六.通过Admin Api操作缓存

  由于某些原因,你希望通过 kong 查看缓存的值,或者手动清理缓存(当缓存被命中或者丢失),你可以通过使用 Admin api /cache 接口进行管理。

查看缓存值-Inspect a cached value

Endpoint

GET  /cache/{cache_key}

Response

返回值
当 key 被有效缓存:
HTTP 200 OK
...
{
    ...
}

否则:
HTTP 404 Not Found


注意:检索由Kong缓存的每个实体的cache_key目前是一个未公开的过程。 Admin API的未来版本将使此过程更加简单。

清除缓存值-Purge a cached value

Endpoint

DELETE  /cache/{cache_key}

Response

HTTP 204 No Content
...

清除节点缓存-Purge a node's cache

Endpoint

DELETE  /cache

Response

HTTP 204 No Content

注意:请谨慎在生产运行节点上使用此接口。如果节点接收到大量流量,同时清除其缓存将触发对数据库的许多请求,并可能导致DB请求堆积现象。

猜你喜欢

转载自www.cnblogs.com/zhoujie/p/kong5.html
今日推荐