主流移動端帳號登陸方式的原理及設計思路

一、引言

在即時通信網常常能看到各類高大上的高併發、分佈式、高性能架構設計方面的文章，平時你們參加的衆多開發者大會，主題也都是各類高大上的話題——什麼5G啦、AI人工智能啦、什麼阿里雙11分分鐘多少萬QPS高併發等等。

但實際上，對於普通的開發者（包括IM開發人員）來講，多數公司、多數團隊也都是幹着默默無聞、平淡無奇的產品開發，並無那麼多高併發、高大上的事情能夠作。

就拿一個IM系統來講，不管你的架構設計考慮了多少分佈式、高吞吐、高可用，全部這些事情只要落地，那編碼的第一件事情就是要實現幾乎全部信息系統都要面對的任務——如何設計帳號登陸功能？

本文將分享幾種典型的移動端帳號登錄方式的技術原理，以及設計思路，理解後，徹底能夠快速實施於你的各類應用系統（並不限於IM系統）中。本文閱讀對像主要爲剛入門的開發人員，請程序老司機們嘴下留情哦。

經過本篇文章， 你能夠學到：

1）主流帳號登陋技術方案細節；

2）相應的表設計；

3）相應的流程設計。

經過本篇文章， 你沒法學到：

與其餘原理性的文章同樣，本篇不涉及具體代碼實現細節（對於程序員來講，只要思路搞通，代碼咋寫都不會太爛，你們應該都有體會）。

二、最經典的用戶名密碼註冊登錄方式

一個典型的用戶名密碼註冊登錄功能相似於下面這樣：

 

這種帳號登錄方式很經典也很經常使用，先註冊、再進行登陸，尤爲在老一點的CMS系統、網站系統、聊天應用中都能找到這個影子。

它的技術原理流程圖以下：

 

 

如上圖所示，詳細的流程說明以下：

• 1）前端將用戶名、密碼發送到服務器，服務器進行常規的判斷，判斷用戶名、密碼長度是否知足，用戶名是否重複等條件，條件不經過直接返回對應錯誤碼給到前端，這裏密碼字段，爲了防止傳輸過程當中被截胡，建議加密再上傳，咱們的傳輸密碼默認都是會進行一個md5加密，而後記錄到數據庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。
• 2）校驗經過後，就將用戶名密碼寫入數據庫，並進行後面積分發放等操做，這裏不展開。
• 3）如今進行登陸，前端將用戶名，密碼發送給到服務端，服務端首先會校驗登陸次數是否超過設置的閾值，若是超過只能繼續等待被關小黑屋。
• 4）若是未超過繼續登陸邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，若是超過則關小黑屋，記住小黑屋必須設置過時時間，要否則就會永久關上了，這個能夠用redis的過時來作。
• 5）登陸成功後進行後續的一切後置邏輯，好比加積分。。。等操做。

這種經典的註冊登錄方式，具體怎麼設計就不在這裏贅述了，誰都懂。

三、現今最主流的手機號註冊登錄方式

3.1 基本原理

典型的手機號註冊登錄功能相似於下圖：

 

典型的手機號註冊技術原理流程圖以下：

 

 

如上圖所示，詳細的流程說明以下：

• 1）首先輸入手機號：而後發送到服務端，服務端將手機號記錄在咱們數據庫中，而後生成隨機驗證碼，並將手機號和驗證碼綁定到一個redis裏面，而後記錄過時時間，這個過時時間通常是10分鐘左右，這就是咱們通常手機驗證碼的有效期；
• 2）手機接收到手機短信後：那麼就在界面填寫驗證碼發送服務端，服務端收到驗證碼後就會在redis裏面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。
• 3）成功後：就進行登陸操做。

這裏看起來沒有明確的註冊登陸操做，其實在發送手機號碼就能夠認爲是一個常規的註冊，而後後面的驗證碼輸入就是一個登錄操做。

但這種區別於常見的用戶名密碼註冊方式，是沒有密碼的的。

問： 那我要密碼咋辦？

答： 在後續產品裏面增長一個手機號碼密碼補錄的功能便可，這也是如今很常規的手法，可是如今移動互聯網大爆炸時代，密碼已經顯得不是那麼重要了，反正我歷來記不住密碼，若是手機號碼能操做的app，絕對不用密碼來操做。

3.2 具體的數據庫設計

表結構： 

說明：

這裏只是單純說明須要用到的數據，沒有擴展具體場景,這個表結構可以知足上面兩個方案的設計。

四、一種輔助的登錄方式：第3方帳號登錄

4.1 基本原理

如今不少應用爲了下降新用戶的使用門檻，都會對接第3方帳號進行登錄（好比：用微信號登錄、QQ號登錄、微博帳號登錄等）。

這裏我以QQ的開放平臺登陸邏輯爲例進行講解。

某團外賣的QQ帳號登錄功能以下圖：

 

咱們先來一波時序圖：

 

 

時序流程詳細說明：

• 1）客戶端本身調起登陸的界面，進行輸入用戶名、密碼，這裏的是第三方的用戶名，密碼，登陸成功後，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk裏面進行內置回調獲取了，後面咱們會說明咱們自身實現的oauth2.0；
• 2）客戶端拿到access_token、openid、login_type（qq、wechat...）請求應用服務器，應用服務器拿到這些數據後就會根據對應的login_type去對應的用戶中心進行access_token和openid進行校驗。校驗不經過則返回對應錯誤碼；
• 3）校驗經過後就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎信息來做爲本地基礎數據，而且返回code值；
• 4）若是已經存在，那就是進行登陸操做，返回code值；
• 5）客戶端拿到code值後進行token值的換取，這個徹底遵守oauth2.0的協議來走的，後續每次請求必須帶上token，token值在服務端的時間比較久，由於咱們想要作的是那種永不下線的操做，因此每次請求咱們都將token過時時間進行累加。

想要深刻了解第3方帳號登錄，能夠讀讀這兩篇：《第三方登陸：QQ登陸接入指南》、《第三方帳號登陸功能接入徹底流程》。

4.2 具體的數據庫設計

表結構：

對於讀者的建議，我這裏作一下數據庫的整理。

 

用戶基礎表（users）：

 

用戶驗證關聯表（user_auth_rel）： 

 

本地用戶表（user_local_auth）：

 

第三方用戶表（user_third_auth）： 

 

表結說明：

• 1）users表只是單純針對咱們業務側的登陸，主要是作自身業務的oauth2.0業務；
• 2）user_local_auth是作本身用戶名、密碼登陸，手機號碼登陸信息記錄；
• 3）user_third_auth是咱們第三方用戶體系的數據記錄；
• 4）user_auth_rel是用來關聯咱們users表與user_local_auth、user_third_auth；
• 5）整個設計理念就是將自建用戶與第三方在存儲上區分，這在架構演進上也是合乎情理的，開始用戶體系大多自建，然後纔是對外接入。

五、本文小結

總的來說，帳號註冊登陸功能在通常的系統裏都是入口功能，通常狀況下都不會太複雜。

對於第三方用戶的接入技術，也一樣比較簡單，我文章裏設計多一個user_thirds是能夠支持足夠多的第三方接入，固然通常咱們也就兩三個登陸就好，太多登陸方不只自身維護成本，界面擺盤也很差看不是。

但願你們可以經過以上學習，可以對於帳戶註冊登陸有一個比較好的認知，文章裏設計方案不包含分表分庫、沒有服務化，就是簡單直接的設計，固然用戶量和須要的不同，在這個基礎上還要加不少東西，謝謝你們閱讀。（本文同步發佈於：http://www.52im.net/thread-2863-1-1.html）