橫看成嶺側成峯，遠近高低各不同。
不識廬山真面目，只緣身在此山中。
讓你用最輕鬆的方式，不說學會，至少能懂什麼叫springcloud及其組件： SpringCloud版本Hoxton SR5 --- 第一講：認識
接下來，就好好剖析剖析Session：
先說一些小結論，再慢慢分析：其實在我看來Session不僅僅是服務器(tomcat)生成的Session ID，我認爲所有的可以建立： 瀏覽器端/App 與 服務器 之間的一對一的交互，都可以被稱爲Session。比如：app與服務器之間就是用token，其實就改了個名字，還是模仿的Session原理。
所以在我看來，Seesion是一種抽象的概念，沒有具體實現，他是一種思想。
在實際項目，基本就分兩種架構：
1. 單體服務器部署項目
2. 多臺服務器的微服務架構（微服務解決方案不只springcloud，double也是可以的）
首先要知道Session是什麼時候產生的 ?
當我們用瀏覽器第一次訪問服務器(tomcat)之前，首先瀏覽器端是沒有session ID的，當瀏覽器訪問到tomcat的時候，這時候tomcat要回復瀏覽器數據的過程其實就是：服務器端的tomcat自己生成了一個session ID，並返回給了瀏覽器端，這時候瀏覽器端把session ID保存到Cookie中，這時候瀏覽器端就有了session ID，以後再不關閉瀏覽器的前提下，每次訪問這個tomcat服務器，都會把這個session ID自動帶上來訪問我們的tocmat，而我們後端程序員就是依靠這個session ID進行用戶確認的。
傳統情況下， 我們是這樣使用的：當用戶訪問我們的網站後，tomcat服務器自動生成一個SeesionID，然後返回給瀏覽器，後面在不關閉瀏覽器的情況下，每次訪問我們這個網站，都會帶上tomcat返回給瀏覽器的SeesionID，當用戶登錄成功後，我們把這個SeesionID 和 用戶信息，以鍵值對的數據結構保存在redis中，然後每次訪問的時候，我們都獲取瀏覽器傳給服務器的SeesionID去redis查，沒找到提示登錄，找到了程序繼續。
那麼這個一個過程，其實就是對SessionID的應用。還有些人，會禁用瀏覽器端的Cookie，這時候瀏覽器端就不能保存SessionID了，比如你禁用Cookie後，淘寶就不能登錄了，淘寶就不能正常使用了。再比如你用手機App使用淘寶，App沒有Cookie這一說法，是不是就不能登錄淘寶使用了呢 ？
所以我上面說，Session宏觀上來說是一種抽象的概念。
瀏覽器端禁用了Seesion也可以用其他方法,其實就是要將SessionId就是保存在用戶端。比如瀏覽器http請求的headers裏面保存SessionID，每次訪問tomat服務器，把header中的SessionID傳到tomcat服務器中。程序員通過header的SessionID也可以確認訪問者的身份、再比如App裏沒有seesion、header、cookie，可以保存到文件中呀，然後通過訪問http的網站後面跟一段SessionID數據、或者在請求參數中，帶上SessionID，tomcat服務器端攔截所有請求，先分析參數，通過的繼續訪問，沒通過的提示登錄。
所以可以先總結一下：
Seesion在微觀上，就是瀏覽器訪問tomcat，然後tomcat自己會生成一個SessionID返回給瀏覽器端保存起來，再訪問其他tomcat又會生成一個sessionID繼續保存在瀏覽器端。
宏觀上，就是用戶端訪問服務器端，登錄成功後，服務器端通過程序員設置一個ID，返回給用戶端保存起來，然後用戶再訪問服務器，就帶上這個ID，以此來確認用戶的身份。
而對Session的應用很多網站都是微觀上的使用，比如淘寶，你禁用了cookie就不能登錄了。
對session技術使用的發展歷程 及 使用解釋：
1. 單體服務（一臺tomcat服務器）
對於我國的互聯網技術發展過程，以前主流的都是一臺服務器，然後tomcat服務器生成session，登錄成功後將session與個人信息以map的數據結構保存起來，後面每次訪問都去查詢出個人信息，再執行後面的程序，但是一臺服務器肯定不能夠滿足日益發展的互聯網大國。
2. 初具形態的微服務架構 (3臺服務器)
這時候有了一項技術，就是tomcat支持多臺tomcat之間的session共享。只需要在tomcat的配置中修改一下，然後幾臺服務器就會session共享，再使用nginx做轉發。這種方式有個缺點：tomcat服務器越多，那tomcat需要將所有tomcat的session都保持一致，非常浪費資源和時間，面對訪問量日益增加不得不使用其他方式。
3. 解決服務器數量限制的微服務架構
使用nginx的ip-hash，什麼意思呢 ？就是說，一個nginx做轉發連接多臺tomcat服務器，nginx有個功能，就是說將訪問ip與tomcat綁定，比如成都某區的電信ip爲125.70.56開頭 。這個地區用戶訪問nginx，然後nginx就指定ip爲125.70.56開頭的用戶訪問A tomcat，其他ip訪問B tomcat，用這種方法來固定session訪問。缺點：第一，這個配置工作大大增加了運維的工作量 。第二：如果這個區域訪問人數突然增多這個tomcat也會宕機。
4. 用redis保存session 微觀上使用session (適用於大型項目 與 第5個方案差不多，還是有點區別)
比如用10臺服務器做登錄的項目，不管訪問到哪臺服務器登錄成功後，我們都將該請求的sessionid和用戶信息保存到redis中，然後訪問其他服務器功能的時候，我們瀏覽器端拿到這個sessionid給服務器，服務器去redis中查詢出用戶信息，就完成了session的校驗。
5. 宏觀上的使用Session（可以用於：springcloud 或者 double架構的大型微服務分佈式架構）
隨着電子產品的發展。App成爲了互聯網主流，上面也說了，App這種客戶端沒有cookie、session這一說法，他只能把數據保存到文件中。所以把session通過http的方式，自動上傳到服務器就不現實了。App中把這種類似Session的東西，叫做token。使用原理其實也都差不多，比如app登錄成功之後，服務器返回一個類似uuid東西，然後app保存到本地文件中，再訪問服務器的時候，就把token傳上來，通常token裏面是有當前手機的唯一標識和一些用戶信息的，這樣服務器端直接解析確認用戶就好了，還可以判斷用戶是否換手機登錄以保證用戶的安全，還可以獲取用戶平時登錄的ip地址來做安全校驗，不過這都是一些衍生品。
上面說app，下面就說說瀏覽器端，當做一個大型的項目的時候，比如淘寶，你在瀏覽器端登錄淘寶之後，你再去訪問天貓，你會發現不用登錄。再比如說，你登錄了百度文庫，你再去訪問百度地圖、百度音樂、百度貼吧也都不用再登錄這就叫單點登錄(SSO)，而實現這個功能，其實依然可以用第4中方式，爲什麼這裏說宏觀上使用session呢 ？因爲在微觀上session是tomcat自己生成的，而我們可以按照我們的規則生成我們想要的sessionID (暫時稱爲UUID，便於區分)，完全脫離tomcat的session，比如我們自己生成的UUID中可以帶有很多信息。然後再保存到redis，返回給瀏覽器端保存起來（這裏還有一個問題就是：返回給瀏覽器端基本都是保存在cookie中，爲了其他域名的地址，可以訪問到這個cookie，所以瀏覽器在返回這個數據的時候，要設置cookie的訪問域），然後訪問其他跨域的網站時，就會把我們返回給瀏覽器的UUID，再傳入服務器，服務器端查詢redis做驗證就好了。
這也是技術發展到今天，最好的一種方式。
另外在使用springcloud的時候，很可能使用zuul組件。當zuul路由多個微服務的時候，瀏覽器端是將session交給了zuul，所以我們需要在zuul的過濾器中獲取到session，然後再由zuul傳給調用的微服務 ，比如將session放在header裏面，再調用微服務。