這週蠻累的，但接觸到新東西，初次摸了覺得稍微有些想法，先記錄下來，不然只是藏在 Notion 日後還會被改了又改，發上來作為一個軌跡。
以後可能會推翻或是再延伸，也說不定，好像從來沒沿路紀錄自己慢慢成長的腳步。
使用的情境蠻明確的：要讓部署在 Kubernetes 當中同一服務的 Replications 間 Session 能夠同步，因此就朝著這個方向與目標前進。
我暫時以使用 Client/Server 模式部署為方向，探勘資料。
目前總結大略摘要：
- Server 端是 Kubernetes 中的 Hazelcast Cluster，使用 StatefulSet 部署 Hazelcast Pod 本身，藉由 Headless Service 暴露在 K8S 當中
- Client 端是 Spring Session 加上 Hazelcast 的 jar 作為 core dependency，但還需要多加入一個 Spring Session Hazelcast，才能夠配置 Configuration，將 Session 委託給 Hazelcast Cluster 管理
- Client 端需要對 Hazelcast 進行服務發現，有 DNS lookup 和 Kubernetes API 兩種方式，兩種都有優勢和限制，似乎 DNS lookup 需要 Headless Service，Kubernetes API 則一般的 Cluster IP Service 即可
- Springboot 2.7.9 相對應 Hazelcast dependency 版本為 1.5.1 作為 Client 端，因此 Hazelcast Server 版本若太高是無法相容的
2023/02/26 補充想法 #
在經過一天的查找資料與實際測試後，我理解到 Client/Server 模式部署對我們的案例而言，其實可能根本不是 Best Practice！
我認為的理由如下：
- 除了官方文件以外，網路上談到 Spring Session + Hazelcast 的配置方式大多是 Embeded，這樣的部署方式下，Hazelcast 本身既是 Client 也是 Server，可見若沒有其他用途，Embedded 是更為省麻煩且目標明確的
- 雖然是在 Spring Application 當中鑲嵌起來的服務，使用彈性不會這麼好。但所謂的使用彈性，前提是除了 session 還有想要拿來存其他東西
- Client/Server 方式部署，配置上除了更加麻煩，管理上甚至因為多部署一個 Hazelcast Server Cluster，多管一些 Pod、Service，又會吃到機器資源，可說是浪費資源又浪費人力
- 只存 session 的情況下，可用性我認為幾乎可以不用討論，反正這顆 Pod 服務死了，session 不存在也是理所當然的
Published