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的原創文章，請關注公衆號"汪子熙":