- 前言：多賬戶登陸
- 1 創(chuàng)業(yè)初期
- 用戶名密碼注冊登陸
- 手機號注冊登陸
- 2 數(shù)據(jù)庫設(shè)計
- 3 引入第三方賬戶方案
- 4 數(shù)據(jù)庫設(shè)計
- 總結(jié)
前言：多賬戶登陸
互聯(lián)網(wǎng)應(yīng)用當(dāng)中竿滨，我們的應(yīng)用會使用多個第三方賬號進(jìn)行登錄佳恬，比如：網(wǎng)易、微信于游、QQ等毁葱，我們把此稱為多賬戶統(tǒng)一登陸。通過這篇文章曙砂， 我想闡釋多賬戶登陸的技術(shù)方案細(xì)節(jié)头谜，以及相應(yīng)的表設(shè)計，流程設(shè)計鸠澈。我這里不會有具體代碼實現(xiàn)細(xì)節(jié)柱告，只要方案做的對，有思路笑陈，代碼咋寫都不會太爛际度。
- 創(chuàng)業(yè)初期
歸結(jié)為創(chuàng)業(yè)初期是因為這個時候用戶量比較少，甚至還沒有接入上面所說的其他第三方的賬戶系統(tǒng)涵妥，只是自建的體系就可以滿足乖菱，自建體系的話，目前常用的有如下解決方案:
用戶名密碼注冊登陸
這種方式在很多初期網(wǎng)站建設(shè)會使用，先注冊窒所，再進(jìn)行登錄鹉勒，在老一點的cms中都能找到這個影子。流程圖如下：
流程說明：
前端將用戶名吵取、密碼發(fā)送到服務(wù)器禽额，服務(wù)器進(jìn)行常規(guī)的判斷，判斷用戶名皮官、密碼長度是否滿足脯倒，用戶名是否重復(fù)等條件，條件不通過直接返回對應(yīng)錯誤碼給到前端捺氢，這里密碼字段藻丢，為了防止傳輸過程中被截胡，建議加密再上傳摄乒，我們的傳輸密碼默認(rèn)都是會進(jìn)行一個md5加密悠反，然后記錄到數(shù)據(jù)庫再進(jìn)行一層加密，就算是脫庫也沒事馍佑，密碼不要明文存儲问慎。
校驗通過后，就將用戶名密碼寫入數(shù)據(jù)庫挤茄，并進(jìn)行后面積分發(fā)放等操作，這里不展開冰木。
現(xiàn)在進(jìn)行登錄穷劈，前端將用戶名，密碼發(fā)送給到服務(wù)端踊沸，服務(wù)端首先會校驗登錄次數(shù)是否超過設(shè)置的閾值歇终，如果超過只能繼續(xù)等待被關(guān)小黑屋。
如果未超過繼續(xù)登錄邏輯逼龟，判斷用戶名评凝、密碼是否正確，不正確密碼則進(jìn)行閾值的判斷腺律，如果超過則關(guān)小黑屋奕短，記住小黑屋必須設(shè)置過期時間，要不然就會永久關(guān)上了匀钧，這個可以用redis的過期來做翎碑。
登錄成功后進(jìn)行后續(xù)的一切后置邏輯，比如加積分等操作之斯。
手機號注冊登陸
短信業(yè)務(wù)非常成熟日杈，使用手機號注冊方便快捷。其流程如下：
流程說明：
首先輸入手機號，然后發(fā)送到服務(wù)端莉擒，服務(wù)端將手機號記錄在我們數(shù)據(jù)庫中酿炸，然后生成隨機驗證碼，并將手機號和驗證碼綁定到一個redis里面涨冀，然后記錄過期時間填硕，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期蝇裤。
手機接收到手機短信后廷支，那么就在界面填寫驗證碼發(fā)送服務(wù)端，服務(wù)端收到驗證碼后就會在redis里面查詢到這個手機號對應(yīng)的驗證碼栓辜，失敗就返回錯誤碼恋拍。
成功后就進(jìn)行登錄操作。
這里看起來沒有明確的注冊登錄操作藕甩，其實在發(fā)送手機號碼就可以認(rèn)為是一個常規(guī)的注冊施敢，然后后面的驗證碼輸入就是一個登陸操作，
問： 那我要密碼咋辦狭莱？
答： 在后續(xù)產(chǎn)品里面增加一個手機號碼密碼補錄的功能即可僵娃，這也是現(xiàn)在很常規(guī)的手法，但是現(xiàn)在移動互聯(lián)網(wǎng)大爆炸時代腋妙，密碼已經(jīng)顯得不是那么重要了默怨，反正我從來記不住密碼，如果手機號碼能操作的app骤素，絕對不用密碼來操作匙睹。
- 數(shù)據(jù)庫設(shè)計
表結(jié)構(gòu)
說明: 這里只是單純說明需要用到的數(shù)據(jù)，沒有擴展具體場景,這個表結(jié)構(gòu)能夠滿足上面兩個方案的設(shè)計济竹。
- 引入第三方賬戶方案
這里是以QQ-SDK的登錄邏輯痕檬， 我們先來一波時序圖:
實現(xiàn)思路：
1.客戶端自己調(diào)起登錄的界面，進(jìn)行輸入用戶名送浊、密碼梦谜，這里的是第三方的用戶名，密碼袭景，登錄成功后唁桩，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk里面進(jìn)行內(nèi)置回調(diào)獲取了浴讯，后面我們會說明我們自身實現(xiàn)的oauth2.0
2.客戶端拿到access_token朵夏、openid、login_type（qq榆纽、wechat…）請求應(yīng)用服務(wù)器仰猖，應(yīng)用服務(wù)器拿到這些數(shù)據(jù)后就會根據(jù)對應(yīng)的login_type去對應(yīng)的用戶中心進(jìn)行access_token和openid進(jìn)行校驗捏肢。
校驗不通過則返回對應(yīng)錯誤碼
1.校驗通過后就會判斷本地是否有這個login_type和openid是否存在，不存在則進(jìn)行獲取遠(yuǎn)程的用戶名饥侵、頭像等基礎(chǔ)信息來作為本地基礎(chǔ)數(shù)據(jù)鸵赫，并且返回code值
2.如果已經(jīng)存在，那就是進(jìn)行登錄操作躏升，返回code值辩棒。
3.客戶端拿到code值后進(jìn)行token值的換取，這個完全遵照oauth2.0的協(xié)議來走的膨疏，后續(xù)每次請求必須帶上token一睁，token值在服務(wù)端的時間比較久，因為我們想要做的是那種永不下線的操作佃却，所以每次請求我們都將token過期時間進(jìn)行累加者吁。
- 數(shù)據(jù)庫設(shè)計
表結(jié)構(gòu)
數(shù)據(jù)庫的整理 用戶基礎(chǔ)表（users）:
用戶驗證關(guān)聯(lián)表（user_auth_rel）
本地用戶表（user_local_auth）
第三方用戶表（user_third_auth）
說明
users表只是單純針對我們業(yè)務(wù)側(cè)的登錄，主要是做自身業(yè)務(wù)的oauth2.0業(yè)務(wù)饲帅，
user_local_auth是做自己用戶名复凳、密碼登錄，手機號碼登錄信息記錄灶泵，
user_third_auth是我們第三方用戶體系的數(shù)據(jù)記錄育八，
user_auth_rel是用來關(guān)聯(lián)我們users表與user_local_auth、user_third_auth赦邻。
整個設(shè)計理念就是將自建用戶與第三方在存儲上區(qū)分髓棋，這在架構(gòu)演進(jìn)上也是合乎情理的，開始用戶體系大多自建惶洲，而后才是對外接入仲锄。
5.總結(jié)
總的來講，第三方用戶的接入技術(shù)上來講是比較簡單的湃鹊，這里設(shè)計多一個user_thirds是可以支持足夠多的第三方接入，當(dāng)然一般我們也就兩三個登錄就好镣奋，太多登錄方不僅自身維護(hù)成本币呵，界面擺盤也不好看不是。
希望大家能夠通過以上學(xué)習(xí)侨颈，能夠?qū)τ谖覀兌噘~戶登錄有一個比較好的認(rèn)知余赢，這里設(shè)計方案不包含分表分庫、沒有服務(wù)化哈垢，就是簡單直接的設(shè)計妻柒，當(dāng)然用戶量和需要的不一樣，在這個基礎(chǔ)上還要加很多東西耘分，謝謝大家閱讀举塔，喜歡文章歡迎各位朋友點贊绑警，讓更多的人看到該文章。
另外央渣，小編最近將收集的Java程序員進(jìn)階架構(gòu)師和面試的資料做了一些整理计盒，免費分享給每一位學(xué)習(xí)Java的朋友，需要的可以進(jìn)群：751827870芽丹，歡迎大家進(jìn)群和我一起交流北启。
_______________end__________________
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！
