作者 :低調的碼農 鏈接 :http://1t.click/QaF
前言：
多賬戶登陸
互聯(lián)網(wǎng)應用當中气嫁，我們的應用會使用多個第三方賬號進行登錄，比如：網(wǎng)易溜嗜、微信、QQ等，我們把此稱為多賬戶統(tǒng)一登陸澎灸。通過這篇文章， 我想闡釋多賬戶登陸的技術方案細節(jié)遮晚，以及相應的表設計性昭，流程設計。我這里不會有具體代碼實現(xiàn)細節(jié)鹏漆，只要方案做的對巩梢，有思路，代碼咋寫都不會太爛艺玲。
創(chuàng)業(yè)初期
歸結為創(chuàng)業(yè)初期是因為這個時候用戶量比較少括蝠，甚至還沒有接入上面所說的其他第三方的賬戶系統(tǒng)，只是自建的體系就可以滿足饭聚，自建體系的話忌警，目前常用的有如下解決方案:
用戶名密碼注冊登陸
這種方式在很多初期網(wǎng)站建設會使用，先注冊，再進行登錄法绵，在老一點的cms中都能找到這個影子箕速。流程圖如下：
流程說明：
1. 前端將用戶名、密碼發(fā)送到服務器朋譬，服務器進行常規(guī)的判斷盐茎，判斷用戶名、密碼長度是否滿足徙赢，用戶名是否重復等條件字柠，條件不通過直接返回對應錯誤碼給到前端，這里密碼字段狡赐，為了防止傳輸過程中被截胡窑业，建議加密再上傳，我們的傳輸密碼默認都是會進行一個md5加密枕屉，然后記錄到數(shù)據(jù)庫再進行一層加密常柄，就算是脫庫也沒事，密碼不要明文存儲搀擂。
2. 校驗通過后西潘，就將用戶名密碼寫入數(shù)據(jù)庫，并進行后面積分發(fā)放等操作哥倔，這里不展開秸架。
3. 現(xiàn)在進行登錄，前端將用戶名咆蒿，密碼發(fā)送給到服務端东抹，服務端首先會校驗登錄次數(shù)是否超過設置的閾值，如果超過只能繼續(xù)等待被關小黑屋沃测。
4. 如果未超過繼續(xù)登錄邏輯缭黔，判斷用戶名、密碼是否正確蒂破，不正確密碼則進行閾值的判斷馏谨，如果超過則關小黑屋，記住小黑屋必須設置過期時間附迷，要不然就會永久關上了惧互，這個可以用redis的過期來做。
5. 登錄成功后進行后續(xù)的一切后置邏輯喇伯，比如加積分等操作喊儡。
手機號注冊登陸
短信業(yè)務非常成熟，使用手機號注冊方便快捷稻据。其流程如下：
流程說明：
1. 首先輸入手機號艾猜，然后發(fā)送到服務端，服務端將手機號記錄在我們數(shù)據(jù)庫中，然后生成隨機驗證碼匆赃，并將手機號和驗證碼綁定到一個redis里面淤毛，然后記錄過期時間，這個過期時間一般是10分鐘左右算柳，這就是我們一般手機驗證碼的有效期低淡。
2. 手機接收到手機短信后，那么就在界面填寫驗證碼發(fā)送服務端瞬项，服務端收到驗證碼后就會在redis里面查詢到這個手機號對應的驗證碼查牌，失敗就返回錯誤碼。
3. 成功后就進行登錄操作滥壕。
這里看起來沒有明確的注冊登錄操作，其實在發(fā)送手機號碼就可以認為是一個常規(guī)的注冊兽泣，然后后面的驗證碼輸入就是一個登陸操作绎橘，
問： 那我要密碼咋辦？
答： 在后續(xù)產品里面增加一個手機號碼密碼補錄的功能即可唠倦，這也是現(xiàn)在很常規(guī)的手法称鳞，但是現(xiàn)在移動互聯(lián)網(wǎng)大爆炸時代，密碼已經顯得不是那么重要了稠鼻，反正我從來記不住密碼冈止，如果手機號碼能操作的app，絕對不用密碼來操作候齿。
數(shù)據(jù)庫設計
表結構
說明:這里只是單純說明需要用到的數(shù)據(jù)熙暴，沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。
引入第三方賬戶方案
這里是以QQ-SDK的登錄邏輯慌盯， 我們先來一波時序圖:
實現(xiàn)思路：
1. 客戶端自己調起登錄的界面周霉，進行輸入用戶名、密碼亚皂，這里的是第三方的用戶名俱箱，密碼，登錄成功后灭必，會返回access_token openid expire_in,這過程會使用到oauth2.0狞谱，不過在sdk里面進行內置回調獲取了，后面我們會說明我們自身實現(xiàn)的oauth2.0
2. 客戶端拿到access_token禁漓、openid跟衅、login_type（qq、wechat...）請求應用服務器璃饱，應用服務器拿到這些數(shù)據(jù)后就會根據(jù)對應的login_type去對應的用戶中心進行access_token和openid進行校驗与斤。
校驗不通過則返回對應錯誤碼
1. 校驗通過后就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎信息來作為本地基礎數(shù)據(jù)撩穿，并且返回code值
2. 如果已經存在磷支，那就是進行登錄操作，返回code值食寡。
3. 客戶端拿到code值后進行token值的換取雾狈，這個完全遵照oauth2.0的協(xié)議來走的，后續(xù)每次請求必須帶上token抵皱，token值在服務端的時間比較久善榛，因為我們想要做的是那種永不下線的操作，所以每次請求我們都將token過期時間進行累加呻畸。
數(shù)據(jù)庫設計
表結構
數(shù)據(jù)庫的整理 用戶基礎表（users）:
用戶驗證關聯(lián)表（user_auth_rel）
本地用戶表（user_local_auth）
第三方用戶表（user_third_auth）
說明
1. users表只是單純針對我們業(yè)務側的登錄移盆，主要是做自身業(yè)務的oauth2.0業(yè)務，
2. user_local_auth是做自己用戶名伤为、密碼登錄咒循，手機號碼登錄信息記錄，
3. user_third_auth是我們第三方用戶體系的數(shù)據(jù)記錄绞愚，
4. user_auth_rel是用來關聯(lián)我們users表與user_local_auth叙甸、user_third_auth。
5. 整個設計理念就是將自建用戶與第三方在存儲上區(qū)分位衩，這在架構演進上也是合乎情理的裆蒸，開始用戶體系大多自建，而后才是對外接入糖驴。
總結
總的來講僚祷，第三方用戶的接入技術上來講是比較簡單的，這里設計多一個user_thirds是可以支持足夠多的第三方接入遂赠，當然一般我們也就兩三個登錄就好久妆，太多登錄方不僅自身維護成本，界面擺盤也不好看不是跷睦。
希望大家能夠通過以上學習筷弦，能夠對于我們多賬戶登錄有一個比較好的認知，這里設計方案不包含分表分庫抑诸、沒有服務化烂琴，就是簡單直接的設計，當然用戶量和需要的不一樣蜕乡，在這個基礎上還要加很多東西奸绷，謝謝大家閱讀，喜歡文章歡迎轉發(fā)层玲，點贊号醉。
