從單機應用到微服務，用戶認證走幾步？

用戶認證指在用戶訪問服務的時候確認用戶的身份，受限於HTTP無狀態的特性，應用開發者須要自行實現用戶認證相關功能。

一般是用戶登陸時服務端生成通行證返回給客戶端，客戶端在接下來的請求中攜帶通行證，而後服務端經過校驗該通行證明現用戶認證。

無論具體的業務是什麼，若是用戶認證失敗，那麼全部的後續操做都沒法執行，須要返回給客戶端用戶認證失敗，對應到HTTP Status Code是401。

本文闡述隨着流量和規模增加，服務從單機應用發展到微服務架構的過程當中，用戶認證功能的實現方式變遷。

單機應用

這個階段只有一臺服務器，應用將session維護在本機的內存/磁盤，而後生成一個session id告之客戶端便可。不少Web框架有內置的實現，開箱即用，有時間簡單到你都沒注意到用戶認證的存在。

可是一臺應用服務器每每不夠用，有多個理由：流量太大一臺扛不住、機器一掛服務就掛可用性過低...

負載均衡

由於有多臺服務器，因此無法再簡單地將session維護在本機上，由於用戶在一臺機器上登陸後，下次訪問可能就到了另外一臺機器。

• 方案A：認證令牌

在登陸的時候將一些用戶的信息編碼到一個字符串裏返回給客戶端，客戶端在隨後的操做中攜帶此字符串操做，服務端驗證這個字符串，字符串合法則認證經過並從字符串中讀取用戶身份信息。

這樣就不須要服務端再存儲session信息，輕鬆支持多臺服務器。而這個用來認證的字符串，就跟軍隊的通關令牌同樣，咱們管它叫認證令牌。

認證令牌的格式須要仔細設計，要能防篡改、具有有效期、要能放到URL中使用、還要可擴展等等。已經有人設計了好了一種令牌格式，還造成了標準叫JWT，能夠直接拿來用，固然要是嫌JWT很差用，從新設計一個也是能夠的。

這裏有一份JWT的簡明介紹。

認證令牌這個方案的缺點是，難以實現登陸態的雲端管理。一般一個令牌生成後，只能等它過時或者encode在其中的某些用戶身份信息發生變化的時候纔會生效。像用戶退登就失效、用戶的在線設備管理、用戶的登陸態管控等功能，沒有辦法實現。

• 方案B：分佈式Session

還有一種方案，將session從應用服務器拿出來單獨維護，造成一個分佈式session，這樣每一臺應用服務器都能訪問獲得。

具體到實現，分佈式Session能夠是Redis、MySQL等。但無論用什麼樣的存儲系統，用戶認證服務的可用性都強依賴它，相比認證令牌不須要服務端存儲的方案，可用性確定相對要低一些。

• 方案A+B

認證令牌有功能缺失，分佈式Session可用性相對不足，把二者結合起來就成了順利成章的方案。

將認證令牌當作session id，正常服務時，用戶認證都作分佈式session校驗，而當分佈式session依賴的存儲系統偶爾出現故障時，則服務降級，改成只校驗認證令牌。這樣可用性有保障，功能也齊全。

若是須要保證登陸服務時，分佈式Session也是高可用的，還能夠在令牌裏面增長一個字段用來區分有session和無session的類型。

微服務

業務規模愈來愈大，團隊人數愈來愈多。一塊兒維護同一個服務愈來愈難了，須要服務拆分，但無論怎麼拆，用戶認證是每一個面向終端用戶的服務都須要的。

用戶認證都須要，只要在拆分的時候把相關代碼都拷貝走，而後各個服務都要依賴用戶信息和分佈式session。

這樣維護起來困難太大，只好將用戶認證相關的功能拆分出來，造成一個獨立的用戶認證服務。這個服務幾乎每個大點的互聯網公司都有，名字不太同樣，有的叫Passport，有的叫Account，有的叫User，但總歸功能是差很少的。

這樣登陸、註冊、用戶認證相關的代碼、數據、線上部署，徹底獨立出來，造成一個用戶認證服務。而後隨着業務增加，服務會繼續拆分，愈來愈多。服務之間可能有依賴，而後大部分服務尤爲是面向終端用戶的服務都會依賴用戶認證服務。

依賴用戶認證服務的獨立微服務愈來愈多，重複的對接工做須要進行不少次，另外在用戶的一次請求中每每涉及多個微服務，在各個微服務單獨對接用戶認證的狀況下，不免會進行屢次用戶認證，形成重複請求，資源浪費。

API網關

經過外網API網關，將公司全部的對外接口的簽名和用戶身份認證收攏到一塊兒。API網關收到用戶的認證令牌以後，先去用戶認證服務換取用戶id，而後使用用戶id訪問其它微服務。這樣各個微服務都根據用戶uid提供服務，再也不須要關心終端用戶的身份認證，而用戶認證服務也只須要對接API網關便可，各自的工做量都大大減少。

Reference

https://www.slideshare.net/opencredo/authentication-in-microservice-systems-david-borsos