隨手扎
序幕 - Keycloak實際部署架構
本系列文章於2025年，已在iT邦幫忙：【與雲原生精靈共舞：APISIX使用者的兩年旅程】發布過。
Keycloak並不是完全無狀態的服務，實際上內嵌了一個記憶體型資料庫–Infinispan。
可以透過設定Infinispan同步不同節點的資料。一般來說，在同一個網路區段下，節點會自己透過多播(Multicast/MPING)的機制，自行探索發現其他節點，因此不需要額外設定。
自己手動設定的好處是：可以自己決定最低的同步保留數量。比如一共有4個節點，可以設定2個owner數量。意思是至少有兩個節點保留同一份資料，並且只有這兩份資料都已經確定保存才完成交易。
除此之外，對於無法使用多播自行發現的網路環境，也可以採用其他方式設定。特別對於跨區域的節點，可以另外設定BACKUP。在我經驗上的使用例子，將其他資料區域的節點視作另一組群集，並將兩個群集以非同步(Async)的方式進行連線。
Keycloak有可能優先使用另一種策略–
JDBC_PING。也就是通過寫入節點資料到資料庫的方式，發現群集節點。在尚未將四個區域節點合併前，我們是這麼做的。但可能需要先爲Keycloak準備寫入的DB及DBSchema。
在臺灣南北一共可以分成四個辦公區塊。在每個辦公區塊都有一個小keycloak群集：
使用的資料庫是同一組。
實際上資料庫是使用由MariaDB組成的Galera群集，並配合APISIX進行反向代理Keycloak服務：
如果再進一步全部展開來，APISIX服務同樣有一個備用節點，兩者透過Keepalived設定VIP相互資源。理想上，當客戶端需要使用Keycloak服務時，會先詢問DNS伺服器，DNS伺服器會在依據客戶端所在的位置，提供較近的VIP位置。
