Cloud Foundry Session Affinity(Sticky Session)的實現

會話保持(Session Affinity),有時又稱粘滯會話(Sticky Sessions), 是負載均衡領域設計需要著力解決的重要問題之一，也是一個相對比較複雜的問題。

會話保持是指在負載均衡器上的一種機制，在完成負載均衡任務的同時，還負責一系列相關連的訪問請求會分配到一臺伺服器上｡

當使用者向伺服器發起請求，伺服器建立一個session，並把session id以cookie的形式寫回給客戶。

看一個例子：當我訪問SAP UI5應用時，

在http請求的頭部觀察到客戶端要求伺服器返回以cookie的形式返回session id的請求欄位：

在伺服器響應的頭部欄位果然返回了session id：

這些cookie資訊能夠在Chrome開發者工具的Application標籤頁裡的Cookies區域檢視：

如此一來，只要客戶的瀏覽器不關，再去訪問伺服器時，訪問請求會自動附上session id去，伺服器端檢測到這個session id後，就會使用記憶體中維持的與這個id對應的session為客戶端服務。

再回到我們討論的會話保持這個話題。什麼時候需要會話保持？舉個大家每天都會遇到的例子，大家在淘寶或者京東上購物時，從完成使用者身份認證到瀏覽店鋪，選擇心儀商品加入購物車，一直到最後下單完成支付，需要經過很多次和伺服器的互動過程才能完成整個交易。由於這幾次互動過程從順序上和邏輯上是密切相關的，伺服器在進行這些互動過程的某一個互動步驟時需要一個上下文(Context)，即上一次互動過程的輸出，因此要求這些相關的互動過程都由一臺伺服器完成。

在這種情況下，假設負載均衡器仍然把這些相關互動session分散到不同的伺服器例項上，就會帶來很糟糕的使用者體驗，比如客戶在瀏覽器上每點選一次，都會彈出登入頁面。或者即使使用者輸入了正確的驗證碼，卻仍然提示驗證碼錯誤。由於伺服器處理例項不一樣，也有可能造成客戶放入購物車的物品丟失。

這就是會話保持機制引入的原因：確保把來自同一客戶的一個完整會話的請求轉發至後臺同一臺伺服器進行處理。

那麼Cloud Foundry的Session Affinity是怎麼實現的呢？

官方文件有介紹：

https://docs.cloudfoundry.org/concepts/http-routing.html#sessions

(1) To support sticky sessions, configure your app to return a JSESSIONID cookie in responses. The app generates a JSESSIONID as a long hash in the following format:

您的應用在響應結果裡需要加上一個JSESSIONID欄位，長度如下：

1A530637289A03B07199A44E8D531427

(2) If an app returns a JSESSIONID cookie to a client request, the CF routing tier generates a unique VCAP_ID for the app instance based on its GUID in the following format:

CF routing tier基於app生成的JSESSIONID生成一個VCAP_ID: 323f211e-fea3-4161-9bd1-615392327913

(3) 接下來客戶每次發起請求，必須同時提供JSESSIONID和VCAP_ID。JSESSION_ID交給應用，用於實現session粘連。而VCAP_ID用於標識服務的應用例項，如果應用掛了，gorouter會把請求路由到另一個應用例項上。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2285127/，如需轉載，請註明出處，否則將追究法律責任。