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