我們用Kubernetes網關解決了大促429報錯，還省了30%服務器成本
上個月黑五我們團隊差點崩了：13%的用戶地址解析請求直接報429被拒，後台查了半天才發現是之前給每個微服務單獨配的限流規則太死，物流查詢模塊流量翻了3倍，其他空出來的資源根本沒法調過去用。
之前我們總覺得Kubernetes網關是大公司才用的複雜組件，直到踩了這個坑才被逼著上線，前後花了不到一周，效果比我們預想的好太多。
Kubernetes網關到底是甚麼？
說白了就是你整個Kubernetes集群的統一流量入口，所有外部請求先到它這兒，再轉發給對應的後端服務，我們用的開源版本單實例就能扛每秒1.2萬次請求，小團隊根本不用糾結性能瓶頸。
我們實打實拿到的3個好處
第一個最直觀：限流規則終於不用每個服務單獨配了。之前大促我們要改七八個微服務的限流閾值，改漏一個就出問題，現在直接在網關層做動態限流，空出來的服務器資源能自動傾斜給流量高的模塊，這次聖誕大促我們的429報錯直接降到了0。
第二個是省成本。之前為了扛峰值我們給3個核心服務各多配了2台冗余服務器，大部分時間資源利用率只有20%，現在網關能自動做負載均衡，我們直接縮容了6台服務器，算了下每個月雲成本降了30%。
第三個是不用讓後端反復改跨域、認證這些通用邏輯。之前每個新服務上線，後端都要寫一遍JWT校驗的代碼，現在直接在網關層配個規則就搞定，我們後端3個人每周能多出來至少半天時間寫業務代碼。
別光聽好處，這2個坑我們踩得結結實實
第一個坑是默認的超時設置太坑。剛上線第一天我們就發現有5%的地址解析請求超時，查了半天才發現網關默認的超時時間是30s，但我們的地址解析服務本身最長就要跑40s，改完規則立刻就恢復了，上線前一定要對著自己的業務接口挨個核對超時閾值。
第二個坑是不要一開始就堆所有功能。我們一開始想把日誌、限流、WAF、灰度發佈所有功能一次性全開，結果配置寫錯了導致整個集群入口斷了20分鐘，後來我們先只開了路由和限流，跑了3天穩定了再慢慢加其他功能，就再也沒出過問題。
到底要不要用？我們給的判斷標準很簡單
適合用的情況：
- 你的微服務數量已經超過5個，每次改通用配置要來回改好幾個地方
- 經常遇到流量峰值，不同服務之間資源沒法靈活調度
- 後端團隊小於5人，不想把時間浪費在重復寫通用邏輯上
別折騰的情況：
- 你就2個微服務，流量常年穩定，現在用的NGINX轉發一點問題都沒有
- 整個團隊沒人懂Kubernetes基礎，別為了追新技術硬上
給第一次上手的小團隊2個實在建議
不用糾結選型，小團隊直接用開源的APISIX或者Kong就行，配套文檔全，遇到問題搜一下基本都有解決方案，不用買商業版，免費版的功能完全夠用。
上線前先切10%的流量跑24小時，重點看有沒有超時、請求被誤攔截的情況，沒問題再全量切，別一上來就把所有流量都導過去。
最後說個大家常問的：我們3個後端之前沒人專門研究過網關，對著官方文檔花了2天就搭完了，真的沒你想的那麼複雜。
有用嗎？