Kong API Gateway 簡介

圖　3-1 Kong API Gateway

前一天的復盤

好啦，工程師上班了，回頭思考一下昨天經歷了甚麼？昨天在API服務上線時，被告知API的網路服務器，不能夠直接被Internet 連線。突然被告知這件事情一定非常驚愕，但是這件事情對於企業的要求來說非常的合理。

企業會為了保護自己的資產或是服務，在服務之前總是會擺上非常多道的防護措施。一開始的出發點可能是風險考量前提思考安全性，後來漸漸地許多的產品是為了可以降低維運或是開發的成本，逐漸的各項圍繞在軟體工程的產品逐漸萌芽。

圖　3-2 Client->Kong->API

圖3-2可以看到，筆者將Client(通常是瀏覽器或是APP)與API之間用Kong API Gateway形成了一道中間層。這種目的通常是希望開發者可以專注在開發與發佈的本質上，降低開發者在商業邏輯API以外的項目，進而提高開發者的關注度，這聽起來好像也很DevOps？

不過不論如何，既然筆者打算從Kong API Gateway與開發者的故事說起，不免的要來介紹一下，就從範例程式一段段開始說起，請讀者關注到範例程式：ironman2025\case_1\1.Kong_declarative\declarative\kong.yml。

簡介案例中的Kong

Service

_format_version: "3.0"
services:
- name: example-service
  url: http://case_1_onlyapi:8080

先來說明Service的簡單觀念，Service 代表 Kong 需要代理的後端服務（Upstream Service） 的設定。它包含了後端的位址、通訊協定、連接埠等資訊，讓 Kong 知道要把請求轉發到哪裡。

因此，在這裡範例的Service 定義如下：

• Service
  • name: example-service → 給這個後端服務取一個識別名稱
  • url: http://case_1_onlyapi:8080 → 後端服務的位置（Kong 轉發的目標）
  • 協定： http
  • 主機名： case_1_onlyapi（Docker Compose 中定義的服務名稱）
  • Port： 8080

Route

  routes:
  - name: example-route
    paths:
    - /my-service

接下來要談的是Route，Route 是 請求進入 Kong 後的匹配條件，決定這個請求要交給哪個 Service。
你可以用多種條件匹配，例如路徑、方法、Host、Header 等。

基本上一個 Service 可對應多個 Route（同一後端多種入口規則），這樣可以靈活地運用不同的條件來存取同一個Service。

因此，在這段Route的定義如下：

• Route 定義（掛在 Service example-service下）
  • name: example-route → Route 名稱
  • paths: /my-service → 任何請求的路徑 以 /my-service 開頭 時，就會匹配這個 Route，並轉發到 example-service（也就是 http://case_1_onlyapi:8080）

預設情況下，這個匹配是「前綴匹配」（prefix match），也支援精確匹配（exact match）

Plugin

    plugins:
    - name: file-log
      config:
        path: /tmp/kong-file.log

在 Kong API Gateway 裡，Plugin 就是功能擴充模組(插件)，用來攔截 API 請求與回應，在進入或離開後端服務之前做一些額外處理。

它的設計目的是讓開發者不用修改後端服務的程式碼，就能增加驗證、安全性、轉換、監控等功能。

因此，上述的conf設定大概如下：

• Plugin（掛在Route 層級下）
  • file-log： 將所有匹配到 /my-service 的請求與回應資訊，記錄到 /tmp/kong-file.log

中間層實踐了甚麼？

在上述最簡單的介紹後，範例中呈現了透過Kong API Gateway 作為轉發到後端API 的中間層，這可以帶來哪些優點？

以上述這個案例，實踐了進出Kong API Gateway 時，將Request /Response 透過Plugin 將Log以file log的形式被記錄下來，如果讀者有實作，可以關注到ironman2025\case_1\1.Kong_declarative\tmp_volume\kong-file.log這個檔案。

{
  "request": {
    "size": 788,
    "headers": {

      "host": "localhost:8000",
      // ...其餘內容...
    },
    "method": "GET",
    "id": "dc63186674f850446bacca259f76aa4b",
    "uri": "/my-service/weatherforecast",
    "url": "http://localhost:8000/my-service/weatherforecast"
  },
  // ...其餘內容...
  },
  "service": {
    "host": "case_1_onlyapi",
    // ...其餘內容...
  },
  "client_ip": "172.20.0.1",
  "latencies": {
    "request": 28,
    "proxy": 27,
    // ...其餘內容...
  },
  "route": {
    // ...其餘內容...
    "paths": [
      "/my-service"
    ],
    // ...其餘內容...
}

可以看到，上面的Log其實細節很多(多到不隱藏部分很難把文章寫下去），一般實務上就可能會透過file log 搭配ELK 的filebeats，將Kong 產出的Log源源不斷地送到Elastic Search。接著就可以透過Kibana來追蹤Kong所產出的Log，藉由排查所有經過Kong Request的問題。

這個案例僅透過file log來處理Log的儲存，藉以容易查找進出Kong的所有問題。但既然是Plugin，那就表示可以根據各種場景與需求，增加各式各樣功能擴充模組來完成不同的任務。

因此，後續我們將會針對筆者認為常見好用且免費的 功能擴充模組(Plugin) 來進行一些介紹。

今天工程師已經頭昏腦脹，明天見～