會話保持(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會把請求路由到另一個應用執行個體上。
本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。