前言
今天聊下遇到過的兩次問題，頁面通過CDN加速，同時附帶聊網站頁面登錄加速的場景，在這兩個事件中我看到了，類似與共性的原因。
背景
案例一：
某大型網絡學院，全球範圍CDN加速，但是遇到一個現象，登錄經常登錄不上，登錄上後狀態不穩定，刷新幾次後會變成無狀態，或者logout的時候，無法退出。
案例二：
某大型企業，通過CDN加速網上商城業務靜態頁面時，把登錄業務也放到了CDN進行加速，這個時候同樣出現了案例一中的情況，但是這裡有一個比較特殊的問題是他有驗證碼環節，經常出現驗證失敗，或者能登錄，但是JS或者CSS文件無法加載，通過詳細的頁面檢查發現錯誤提示為驗證碼驗證失敗的情況，這種情況下造成業務不可用。
分析過程
分析之前，先小聲抱怨兩句哈（），在核對這兩個案例的時候真心的消耗腦細胞，在我還是CDN剛入門的時候，其中的分析過程是比較淚奔的。
1、客戶上報使用故障，故障現象如背景說說的情況；
2、採用常規手段對比異常情況和正常情況下的response header 訪問路徑文件大小，緩存規則，初步分析均為發現明顯異常；
3、詳細瞭解客戶業務流程，可能用或者經過哪些組件或者系統；
4、經過了解和進一步分析，我們發現了兩個現象（4層的會話保持功能也有相關影響）：
a.同一個接入點，相同的URL在後端回源的設備上使用的不同的出口；
b.分析瀏覽器中能提供的詳細數據，發現登錄異常的時候，兩次請求的cookie，value不相同，類似於重新註冊校驗，這就導致無法登錄，或者無法退出現象；
5、瞭解源站架構，分析兩次cookie不一致是由什麼引起的；
6、在分析過程中發現，CDN的源站是一個負載均衡的VIP，後端存儲中很多的RS，但是問題來了登錄這種問題需要後端設備共享cookie或者session，這樣能保持登錄狀態。
解決方案
1.源站負載均衡設備使用的算法是ip hash這種算法，保證cookie或者session的連續行，同時session或者cookie在後端設備是共享的。
2.CDN節點放開回源節點數，因為CDN一般都是回源收斂，匯聚到一組節點回源，這樣就導致回源節點比較單一，源站負載均衡如果使用一般的算法，會導致只是回到後端一臺RS上，導致負載不均等情況，或者校驗失敗，方案：放開回源收斂，使用區域中心或者邊緣中心直接回源，這樣的化會對源站的性能有一定的挑戰。
總結
通過整個分析的過程，建議用戶登錄類的功能，一般不要使用CDN加速，如果要使用，就必須做好後端cookie或者session這類回話保持的共享機制。
