基礎圖解之分佈式服務部署請求流程

今天,深層次和羣裏同窗討論關於分佈式系統問題

彙總以下:

單體應用,分佈式部署:保存會話信息(spring-session)

客戶端cookies + 服務端 redis  = 用戶信息

單機應用中，HttpSession是經過Servlet容器建立和管理的，servlet容器一旦中止服務，那麼session也隨之消失；但若是session被保存到redis中，只要redis服務沒停且session在有效期間內，那麼servlet容器中止服務了，session仍是存在的，這有什麼好處了，好處就是servlet容器出現閃停閃修復的狀況，用戶就不用從新登陸了。

使用redis存儲用戶會話信息,客戶端web請求每次攜帶cookies,在攔截器中,獲取經過cookies獲取redis中用戶信息

集羣部署時(3臺服務器部署3個tomcat, 其中tomcat部署同一個項目) ,其session是沒法共享的, 可使用spring-session 共享session;

分佈式應用:保存會話信息(sso單點登陸)

sso登陸

分佈式系統部署時, 多服務器, session是沒法共享的,這是公認的, 同時頂級域名下, 不一樣服務,前端請求是沒法跨域獲取cookie的,要想實現效果, 參考使用sso登陸 模式;

邏輯: 抽離登陸業務邏輯爲公共服務,統一驗證是否登陸未登陸,反饋cookies等參數; 

單點登陸參考: https://yq.aliyun.com/articles/636281 

A 訪問

1. 用戶訪問app系統，app系統是須要登陸的，但用戶如今沒有登陸。
2. 跳轉到CAS server，即SSO登陸系統，之後圖中的CAS Server咱們統一叫作SSO系統。 SSO系統也沒有登陸，彈出用戶登陸頁。
3. 用戶填寫用戶名、密碼，SSO系統進行認證後，將登陸狀態寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie。
4. SSO系統登陸完成後會生成一個ST（Service Ticket），而後跳轉到app系統，同時將ST做爲參數傳遞給app系統。
5. app系統拿到ST後，從後臺向SSO發送請求，驗證ST是否有效。
6. 驗證經過後，app系統將登陸狀態寫入session並設置app域下的Cookie。

A 訪問關聯app2系統

1. 用戶訪問app2系統，app2系統沒有登陸，跳轉到SSO。
2. 因爲SSO已經登陸了，不須要從新登陸認證。
3. SSO生成ST，瀏覽器跳轉到app2系統，並將ST做爲參數傳遞給app2。
4. app2拿到ST，後臺訪問SSO，驗證ST是否有效。
5. 驗證成功後，app2將登陸狀態寫入session，並在app2域下寫入Cookie。

 

分佈式模式模塊分層簡略模型

寫的問題, 請留言, 不慎感受;