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在代理請求時避免資料庫連接配接，并将資料庫的内容緩存到記憶體中。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 節點漏掉處理緩存無效事件，避免舊資料長時間沒有被清理。當緩存生存時間到了，緩存值将會被清理掉，下一次将會從資料庫讀取資料并再次緩存起來。

如果使用 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

DELETE  /cache/{cache_key}      

HTTP 204 No Content
...      

清除節點緩存-Purge a node's cache

DELETE  /cache      

HTTP 204 No Content      

注意：請謹慎在生産運作節點上使用此接口。如果節點接收到大量流量，同時清除其緩存将觸發對資料庫的許多請求，并可能導緻DB請求堆積現象。

 七、叢集搭建

cluster來世今生

　　在kong v0.11版本去除了cluster這個指令和api的管理，我也是吭哧吭哧花了好長時間找到了如下

珍貴的文檔

（upgrade to 0.11.x這一節）：

作者：

zhoujie

出處：

http://www.cnblogs.com/zhoujie/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，不然我擔心部落格園找你算賬

如果您覺得本文對你有幫助，請豎起您的大拇指右下角點推薦，也可以關注我