今天跟大家聊一個(gè)比較基礎(chǔ)的話題，就是實(shí)現(xiàn)登錄的方式有哪些?適合剛?cè)胄械呐笥选?/p>

華山之 Session 絕學(xué)

Session 我們稱之為會(huì)話控制, 是一種在服務(wù)器端保持會(huì)話狀態(tài)的解決方案。通俗點(diǎn)來講就是客戶端訪問服務(wù)端的時(shí)候，會(huì)在服務(wù)端存儲(chǔ)對(duì)應(yīng)的信息，生成一個(gè) Session ID 返回給客戶端，客戶端下次過來的時(shí)候帶上 Session ID，這樣就能識(shí)別訪問者的身份。

請(qǐng)求中帶上 Session ID 最常見的方式就是通過 Cookie 來承載了，Cookie 是客戶端保存用戶信息的一種機(jī)制，在瀏覽器環(huán)境中，請(qǐng)求會(huì)自動(dòng)帶上 Cookie 信息，服務(wù)端也就能獲取到 Session ID。

在后端實(shí)現(xiàn)登錄邏輯的時(shí)候，先獲取 HttpSession 對(duì)象，然后通過 setAttribute()來設(shè)置登錄的用戶信息，比如用戶 ID。驗(yàn)證有沒有登錄的時(shí)候通過 getAttribute()來獲取對(duì)應(yīng)的 Session 信息，如果沒有獲取到，則證明沒有登錄過或者會(huì)話失效了。

對(duì)于 Tomcat, Jetty 這些容器而言，Session 就是是一塊在服務(wù)器開辟的內(nèi)存空間，存儲(chǔ)結(jié)構(gòu)就是 Map。

Tomcat 的 Session 實(shí)現(xiàn)類似 StandardSession。

分布式 Session 解決方案

如果你的應(yīng)用是單節(jié)點(diǎn)部署，這種場(chǎng)景使用web容器實(shí)現(xiàn)的 Session 機(jī)制沒有問題。一旦壓力過大，需要多節(jié)點(diǎn)部署的時(shí)候，Session 就需要進(jìn)行分布式的支持。

看下圖，當(dāng)部署了兩個(gè) Tomcat 的時(shí)候，通過 Nginx 進(jìn)行負(fù)載均衡，第一次請(qǐng)求轉(zhuǎn)發(fā)到了 Tomcat1, Session 信息存儲(chǔ)在 Tomcat1 上面。第二次請(qǐng)求轉(zhuǎn)發(fā)到了 Tomcat2 上面，但是 Tomcat2 上面是沒有剛才的 Session 信息，這就是多節(jié)點(diǎn)下 Session 會(huì)出現(xiàn)的問題。

Session 復(fù)制

Tomcat 內(nèi)置了 Session 復(fù)制的功能，也就是你的 Session 是在 Tomcat1 中產(chǎn)生的，Tomcat1 會(huì)將你的 Session 同步給 Tomcat2, 這樣當(dāng)你的請(qǐng)求到了 Tomcat2 的時(shí)候，就能知道你的身份信息。

這種方案在其他的框架中也經(jīng)常能見到，比如 Spring Cloud 體系中的 Eureka 注冊(cè)中心，也是采用復(fù)制的方式來同步注冊(cè)表的信息。

關(guān)于 Tomcat Session 復(fù)制相關(guān)配置請(qǐng)參考官方文檔：https://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html

黏性會(huì)話

黏性會(huì)話指的是對(duì)于同一個(gè)用戶的請(qǐng)求，永遠(yuǎn)都只轉(zhuǎn)發(fā)到某一個(gè) Tocmat 的實(shí)例上，這樣即使沒有做 Session 復(fù)制，也不會(huì)出現(xiàn)問題。如果有節(jié)點(diǎn)掛掉了就會(huì)訪問失敗。

常見的方式有對(duì) IP 做 Hash 進(jìn)行轉(zhuǎn)發(fā)，IP 不太可靠，因?yàn)闀?huì)變。在 Nginx 中有一個(gè) nginx-sticky-module 這個(gè)第三方模塊用于添加一個(gè)粘性 Cookie，該粘性 cookie 始終轉(zhuǎn)發(fā)到同一服務(wù)器。

nginx-sticky-module 會(huì)在 Cookie 中記錄一個(gè)值來標(biāo)識(shí)當(dāng)前請(qǐng)求需要被轉(zhuǎn)發(fā)到哪個(gè)節(jié)點(diǎn)，第一次沒有的時(shí)候會(huì)先轉(zhuǎn)發(fā)，然后在響應(yīng)給客戶端之前寫入 Cookie。后面的請(qǐng)求都會(huì)在 Cookie 找到對(duì)應(yīng)的標(biāo)識(shí)，然后進(jìn)行轉(zhuǎn)發(fā)到固定的節(jié)點(diǎn)。

Session 集中存儲(chǔ)

Session 復(fù)制會(huì)占用服務(wù)器資源，影響性能。黏性會(huì)話存在單點(diǎn)故障風(fēng)險(xiǎn)。更好的分布式 Session 方式就是集中式存儲(chǔ)。

所謂集中式存儲(chǔ)就是將會(huì)話信息統(tǒng)一存儲(chǔ)在某個(gè)地方，像 Tomcat 之類的 Web 服務(wù)器本身不存儲(chǔ)會(huì)話信息，這樣后端服務(wù)也就是無狀態(tài)的，方便隨時(shí)擴(kuò)容。

至于實(shí)現(xiàn)方案的話有很多，大家可以自己去實(shí)現(xiàn) HttpSession 做對(duì)應(yīng)的存儲(chǔ)讀取邏輯，也可以采用開源的方案。比如 Spring Session 就是一個(gè)很好的開源方案，上手簡(jiǎn)單，支持多種存儲(chǔ)方式，比如 Redis, Mysql 等。

如果對(duì)手寫 Spring Session 原理感興趣的，也可以參考我之前的這套課程：http://cxytiandi.com/course/5

少林之 Token 絕學(xué)

Token 認(rèn)證是目前主流的認(rèn)證方式之一，Token 最大的優(yōu)勢(shì)在于無狀態(tài)，并且不用存儲(chǔ)會(huì)話信息。也就是說通過 Token 就可以知道當(dāng)前訪問的用戶是誰，不需要去 Web 容器的內(nèi)存中獲取，不需要去集中管理會(huì)話的存儲(chǔ)中去獲取。

Token 的生成方式有多種，可以自己定義固定的格式，比如里面包含了用戶 ID,用戶名等信息。也可以使用目前主流的 JWT 方式。

JWT(JSON Web Token)是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境中傳遞聲明而執(zhí)行的一種基于 JSON 的開放標(biāo)準(zhǔn)。JWT 的聲明一般被用在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息， 以便從資源服務(wù)器獲取資源。

比如在用戶登錄時(shí)，基本思路就是用戶提供用戶名和密碼給認(rèn)證服務(wù)器，服務(wù)器驗(yàn)證用戶提交信息的合法性;如果驗(yàn)證成功，會(huì)產(chǎn)生并返回一個(gè) Token，后續(xù)請(qǐng)求用戶帶上這個(gè) Token ，服務(wù)端就可以識(shí)別這個(gè)請(qǐng)求的身份信息。

JWT 由三部分構(gòu)成，

• 第一部分是頭部(Header);
• 第二部分是消息體(Payload);
• 第三部分是簽名(Signature)。

一個(gè) JWT 生成的 Token 格式為：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) 

頭部的信息通常由兩部分內(nèi)容組成，令牌的類型和使用的簽名算法，比如下面的代碼：

{ "alg": "HS256", "typ": "JWT" } 

消息體中可以攜帶一些應(yīng)用需要的信息，比如用戶 ID，代碼如下：

{ "id": "1001", "name": "yinjihuan"} 

簽名是用來判斷消息在傳遞的路徑上是否被篡改的，從而保證數(shù)據(jù)的安全性，格式如下：

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 

通過這三部分就組成了我們的 JSON Web Token。

如何使用請(qǐng)參考 Github：https://github.com/jwtk/jjwt

如上圖所示：請(qǐng)求到達(dá) Tomcat 后，可以調(diào)用單獨(dú)的 Token 服務(wù)進(jìn)行 Token 的生成，也可以將 Token 的生成邏輯封裝成一個(gè) jar 包來使用。需要注意的是如果用內(nèi)嵌的方式，對(duì)應(yīng) Token 的加密配置要一致，否則會(huì)出現(xiàn)驗(yàn)證失敗的情況。

Token 有點(diǎn)不好的地方在于無法主動(dòng)讓它失效，比如我們用 Session 的場(chǎng)景，用戶退出登錄，直接將 Session 信息在服務(wù)端刪除即可，即使后面用相同的 Session 信息去請(qǐng)求，服務(wù)端也找不到對(duì)應(yīng)的信息了。

Token 是一個(gè)加密的字符串，里面包含了用戶的信息，加密算法，過期時(shí)間。如果過期時(shí)間設(shè)置的比較長，也就意味著在過期時(shí)間之前都可以使用。

如果要實(shí)現(xiàn)退出登錄的功能，既然不能對(duì) Token 本身的過期時(shí)間進(jìn)行改造，那么可以使用一個(gè)黑名單的機(jī)制來進(jìn)行過濾即可。將退出登錄的 Token 存儲(chǔ)起來，使用的地方去匹配是否注銷了，然后進(jìn)行攔截即可。

關(guān)于作者：尹吉?dú)g，簡(jiǎn)單的技術(shù)愛好者，《Spring Cloud 微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud 微服務(wù) 入門 實(shí)戰(zhàn)與進(jìn)階》作者, 公眾號(hào)猿天地發(fā)起人。