Kong 與 API Gateway：該不該擺一個守門員，先數數你手上有幾隻服務

先回答一個問題：你手上現在跑著幾隻服務？

如果答案是一隻，或是兩三隻互相之間根本不太講話，那底下這篇你可以直接關掉，去做點別的。API Gateway 不是你現在該煩惱的東西，硬擺一個只會多養一個要顧的元件。真正需要它的人，通常是在某個下午突然發現：同一段「檢查這個 token 有沒有過期」的程式碼，已經被複製貼上到第七隻服務裡了。

那一刻你才會懂 Kong 這種東西為什麼存在。

重複的不是功能，是責任

想像一棟辦公大樓。裡面十幾間公司，每一間都要驗訪客身份、都要管誰能進誰不能進、都要記錄今天誰來過。你有兩種蓋法。

一種是每間辦公室門口各自裝一台門禁機、各請一個櫃檯小姐、各自記一本訪客簿。聽起來很獨立、很自主，但你只要站在一樓抬頭看，就知道哪裡不對——同一件事被幹了十幾遍，而且每一台門禁機的規則還都長得不太一樣。哪天公司規定「訪客一律要戴證」，你得跑十幾間去改。

另一種蓋法是：一樓擺一個大廳，所有人先過這關。驗證、放行、登記，全部在這裡做完，做完了再讓你上樓找對應的公司。

API Gateway 就是那個一樓大廳。你的每一隻後端服務是樓上的公司，Gateway 是那個誰都躲不掉的入口。它把「每隻服務本來都要自己做一遍」的那些雜事——驗身份、限流量、擋跨域、寫存取紀錄——從各個服務裡抽出來，集中在最前面做掉。

講白了，它解決的不是什麼高深的問題。它解決的是重複。而重複這件事的麻煩之處在於，它剛開始一點都不痛。第一隻服務寫驗證邏輯，很合理；第二隻複製過去，還好；等你發現痛的時候，通常已經散在十個地方、改一個要動十次了。

Kong 到底是什麼做的

Kong 底層其實沒有什麼魔法。它是架在 Nginx 上、用 OpenResty 讓你能塞 Lua 進去跑的一層東西。你可以粗暴地理解成：一台被程式化到牙齒的反向代理。請求進來，它先攔下來，按照你設定的規則處理一輪，再決定要不要、以及往哪一隻後端送。

它要你理解的概念也不多，就四個，而且是一路串下來的。

Service，是你那隻真正幹活的後端，比如你的訂單服務、會員服務。你先告訴 Kong「後面有這麼一隻服務，它住在這個位址」。Route，是通往這隻服務的路——什麼樣的網址、什麼樣的 method 進來，該被導到哪個 Service。Consumer，是誰在打你的 API，這樣你才有辦法對「不同的人」套不同規則。Plugin，才是重點，是你掛在上面的那些能力：要限流就掛 Rate Limiting，要驗 key 就掛 Key Auth，要用 JWT 就掛 JWT，前端喊 CORS 錯誤就掛個 CORS 外掛。

漂亮的地方在這：你想給某隻服務加上「每個 IP 每分鐘最多打 100 次」，你不用去改那隻服務一行程式碼，你只是在 Gateway 上對它掛一個 plugin。服務本身完全不知道自己被限流了，它只是安安靜靜地少收到一些請求而已。這就是把責任抽出來之後你換到的東西——後端可以回去專心做它該做的事。

兩種活法：要不要那個資料庫

Kong 有一個很值得先想清楚的選擇：要不要接資料庫。

傳統跑法是後面掛一個 PostgreSQL，你所有的 Service、Route、Plugin 設定都存進去，改設定是打 Admin API 動態改，即時生效。彈性很高，適合設定會一直變、要透過介面管的場景。代價是你多了一個資料庫要顧、要備份、要擔心它掛掉。

另一種叫 DB-less，沒有資料庫，你把所有設定寫成一份宣告式的 YAML，Kong 開機的時候把它讀進記憶體就跑。改設定？改檔案、重新載入。這種玩法跟現在大家熟悉的「基礎設施即程式碼」是同一個哲學——你的 Gateway 設定進 git、走 CI、可以 review、可以回滾。少一個 stateful 的元件，維運心智負擔小很多。

如果你是新專案、設定不會天天變、又已經習慣把東西丟進版控，我會直接建議你從 DB-less 開始。等哪天真的需要動態改設定改到受不了，再搬去有 DB 的版本也不遲。倒過來搬會痛得多。