本系列文章於2025年，已在iT邦幫忙：【與雲原生精靈共舞：APISIX使用者的兩年旅程】發布過。

從Keycloak建立SSO服務開始 (When)

上一次參加iT鐵人賽是2022年，也就是有兩年沒參賽。
但這次的主題緣起，其實可以從2021年的參賽主題「用Keycloak學習身份驗證與授權」開始說起。

在寫完該主題後，便在公司開始引進Keycloak作爲單點登入服務(Single Sign-On，SSO)。也就是說，開始在公司維運使用Keycloak也就3年多了，從最開始的16.1.1版本，分四個區域建立四組服務，到跳板升級到22.0.5，並合併四個資料區域提供一組服務。到現在最新版本都已經到26版，並且Keycloak也早已進入的雲原生計算基金會(Cloud Native Computing Foundation，CNCF)的孵化項目。

除了資料區的合併，還有一項變化是：將原本在前方作為負載平衡，反向代理Keycloak的Nginx換成了APISIX。

DoS服務阻斷到APISIX (What & Why)

爲什麼會選APISIX？ 其實也沒什麼太大理由。

公司內另一項服務，因爲客戶端的錯誤設置，導致該服務最終資料庫無法負荷交易，造成類似DoS問題。

因此開始和同仁討論與尋找其他監控服務與防範做法。在此前，曾經聽過微服務概念中API Gateway提供的斷路器功能，也就是當服務開始發生問題後，不再接受新的請求，好讓服務有時間好好消化處理原本已接受的請求。

APISIX並不是唯一一個提供這樣服務的，起初也有考慮過Traefik、Kong、Tyk甚至envoy。不過Kong、Tyk屬於免費增值；envoy有點太過複雜；Traefik很有意思，單當時資源不太多。而APISIX已經是Apache基金會下的頂級項目(Top-Level Project)，使用友善Apache授權。不管是個人興趣和學習上容易性，還是當時相對豐富的中文資源(貢獻至Apache前，項目有華人發起)，最開始嘗試API網關就直接從APISIX開始，也就沒有進一步嘗試其他備選項目。

總之，這次的主題會圍繞著APISIX的應用情境與功能進行分享，同樣也是做為一種個人學習記錄。