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请求堆积现象。

 7、集群搭建

cluster来世此生

　　在kong v0.11版本去除了cluster这个命令和api的管理，我也是吭哧吭哧花了好长时间找到了以下珍贵的文档（upgrade to 0.11.x这一节）：

kong 0.11 changeLog节选：
Due to the removal of Serf, Kong is now entirely stateless. As such, the /cluster endpoint has for now disappeared. This endpoint, in previous versions of Kong, retrieved the state of the Serf agent running on other nodes to ensure they were part of the same cluster. Starting from 0.11, all Kong nodes connected to the same datastore are guaranteed to be part of the same cluster without requiring additional channels of communication.

The Admin API /status endpoint does not return a count of the database entities anymore. Instead, it now returns a database.reachable boolean value, which reflects the state of the connection between Kong and the underlying database. Please note that this flag does not reflect the health of the database itself.

　　意思是说在kong 0.11以前的版本有cluster命令和/cluster接口来管理kong集群（难怪在0.13中死活提示cluster命令不存在），默认配置文件中有相关cluster参数（网上能搜到不少此类的文档，不过都是0.10以前的版本），也会有个数据库表来存储kong 集群节点相关信息。

可是0.11版本后去除了这个cluster管理这个功能，kong变成彻底无状态的，只要是链接到同一个kong数据库的节点都认为是同一个kong集群而不须要额外的通讯机制。所以也不须要在kong.conf中配置cluster相关参数了。

集群实践

　　在0.10以前的版本集群配置也很简单，参考官方文档经过cluster命令便可，配置文件默认也是生成好的。相关可参考：http://blog.100dos.com/2016/08/01/kong-cluster-introduction/

　　接下来我来尝试一下部署将两个kong节点链接到同一个pg数据库，并验证是否在一个集群。

node1 :  172.18.18.1

node2：172.18.18.2

首先部署好两个kong节点，而且配置文件链接到同一postgres数据库。便于测试， 将两个kong节点的配置文件下面两个参数为：

proxy_listen = 0.0.0.0:8000

admin_listen = 0.0.0.0:8001

链接相同的数据库，在kong.conf中设置posgres的链接参数：

pg_host = 172.1.1.2             # The PostgreSQL host to connect to.
pg_port = 5432                  # The port to connect to.
pg_user = kong                  # The username to authenticate if required.
pg_password = kong               # The password to authenticate if required.
pg_database = kong              # The database name to connect to.

注意：数据库部署的配置文件须要设置容许外部链接，详见centeos部署pg和kong

配置好后重启两个节点的kong服务。

curl 172.18.18.1:8001/status 和curl 172.18.18.2:8001/status 的数据库链接均为true

{
    "database": {
        "reachable": true
    },
    "server": {
        "connections_writing": 1,
        "total_requests": 5,
        "connections_handled": 4,
        "connections_accepted": 4,
        "connections_reading": 0,
        "connections_active": 1,
        "connections_waiting": 0
    }
}

经过node1来注册一个服务：

curl -i -X POST \
  --url  http://172.18.18.1:8001/services/ \
  --data 'name=service-stock' \
  --data 'url=http://hq.sinajs.cn'

显示注册成功：

HTTP/1.1 201 Created
Date: Sun, 10 Jun 2018 09:43:49 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/0.13.1

{
    "host": "hq.sinajs.cn",
    "created_at": 1528595029,
    "connect_timeout": 60000,
    "id": "0032fa88-c457-4d35-b1e7-b5b6f872e2fe",
    "protocol": "http",
    "name": "service-stock",
    "read_timeout": 60000,
    "port": 80,
    "path": null,
    "updated_at": 1528595029,
    "retries": 5,
    "write_timeout": 60000
}

 

经过node2来查询这个Service:

$  curl -i -X GET   --url  http://172.18.18.2:8001/services/service-stock
HTTP/1.1 200 OK
Date: Sun, 10 Jun 2018 09:47:05 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/0.13.1

{"host":"hq.sinajs.cn","created_at":1528595029,"connect_timeout":60000,"id":"0032fa88-c457-4d35-b1e7-b5b6f872e2fe","protocol":"http","name":"service-stock","read_timeout":60000,"port":80,"path":null,"updated_at":1528595029,"retries":5,"write_timeout":60000}

由于两者是共享同一数据库的，因此这显然没有问题。

如今则能够横向扩展任意多个node节点，只要它们链接的是同一个数据库(或集群)便可，若是kong对外但愿是一个入口，则能够将这些kong节点做为反向代理的上游，经过nginx转发便可。