面試官問我：如何設(shè)計 QQ、微信等第三方賬號登陸 ？還要我說出數(shù)據(jù)庫表設(shè)計！
低調(diào)的碼農(nóng)|https://sourl.cn/tzZUzN
多賬戶的統(tǒng)一登錄
名稱解釋
這里的多賬戶區(qū)別于系統(tǒng)級別的，我們講的多賬戶系統(tǒng)是指，在我們互聯(lián)網(wǎng)應(yīng)用當(dāng)中，我們的應(yīng)用會使用多個第三方賬號進行登錄，比如現(xiàn)在常用的APP：網(wǎng)易、微信、QQ等等。
內(nèi)容
通過這一篇文章：
-
可以學(xué)到：多用戶下面的技術(shù)方案細節(jié)，以及相應(yīng)的表設(shè)計，流程設(shè)計。 -
不可以學(xué)到：與其他文章一樣，我這里不會有具體代碼實現(xiàn)細節(jié)，方案做的對，代碼咋寫都不會太爛。
架構(gòu)演進
創(chuàng)業(yè)初期
歸結(jié)為創(chuàng)業(yè)初期是因為這個時候用戶量比較少，甚至還沒有接入上面所說的其他第三方的賬戶系統(tǒng)，只是自建的體系就可以滿足，自建體系的話，目前常用的有
用戶名密碼注冊登陸
這種方式在很多初期網(wǎng)站建設(shè)會使用，先注冊，再進行登錄，在老一點的cms中都能找到這個影子。
流程圖：
流程說明：
-
前端將用戶名、密碼發(fā)送到服務(wù)器，服務(wù)器進行常規(guī)的判斷，判斷用戶名、密碼長度是否滿足，用戶名是否重復(fù)等條件，條件不通過直接返回對應(yīng)錯誤碼給到前端，這里密碼字段，為了防止傳輸過程中被截胡，建議加密再上傳，我們的傳輸密碼默認都是會進行一個md5加密，然后記錄到數(shù)據(jù)庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。 -
校驗通過后，就將用戶名密碼寫入數(shù)據(jù)庫，并進行后面積分發(fā)放等操作，這里不展開。 -
現(xiàn)在進行登錄，前端將用戶名，密碼發(fā)送給到服務(wù)端，服務(wù)端首先會校驗登錄次數(shù)是否超過設(shè)置的閾值，如果超過只能繼續(xù)等待被關(guān)小黑屋。 -
如果未超過繼續(xù)登錄邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，如果超過則關(guān)小黑屋，記住小黑屋必須設(shè)置過期時間，要不然就會永久關(guān)上了，這個可以用redis的過期來做。 -
登錄成功后進行后續(xù)的一切后置邏輯，比如加積分。。。等操作。
手機號注冊登陸
流程圖：
流程說明：
-
首先輸入手機號，然后發(fā)送到服務(wù)端，服務(wù)端將手機號記錄在我們數(shù)據(jù)庫中，然后生成隨機驗證碼，并將手機號和驗證碼綁定到一個redis里面，然后記錄過期時間，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期。 -
手機接收到手機短信后，那么就在界面填寫驗證碼發(fā)送服務(wù)端，服務(wù)端收到驗證碼后就會在redis里面查詢到這個手機號對應(yīng)的驗證碼，失敗就返回錯誤碼。 -
成功后就進行登錄操作。
這里看起來沒有明確的注冊登錄操作，其實在發(fā)送手機號碼就可以認為是一個常規(guī)的注冊，然后后面的驗證碼輸入就是一個登陸操作，
問： 那我要密碼咋辦？
答： 在后續(xù)產(chǎn)品里面增加一個 手機號碼密碼補錄的功能 即可，這也是現(xiàn)在很常規(guī)的手法，但是現(xiàn)在移動互聯(lián)網(wǎng)大爆炸時代，密碼已經(jīng)顯得不是那么重要了，反正我從來記不住密碼，如果手機號碼能操作的app，絕對不用密碼來操作。
數(shù)據(jù)庫設(shè)計
表結(jié)構(gòu) ：
| 自增id | 用戶名 | 密碼 | 手機號 | 錯誤次數(shù) |
|---|---|---|---|---|
| 1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
| 2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
說明 ：
這里只是單純說明需要用到的數(shù)據(jù)，沒有擴展具體場景,這個表結(jié)構(gòu)能夠滿足上面兩個方案的設(shè)計。
引入第三方賬戶方案
這里是以QQ-SDK的登錄邏輯， 我們先來一波時序圖
說明：
-
客戶端自己調(diào)起登錄的界面，進行輸入用戶名、密碼，這里的是第三方的用戶名，密碼，登錄成功后，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk里面進行內(nèi)置回調(diào)獲取了，后面我們會說明我們自身實現(xiàn)的oauth2.0 -
客戶端拿到access_token、openid、login_type（qq、wechat...）請求應(yīng)用服務(wù)器，應(yīng)用服務(wù)器拿到這些數(shù)據(jù)后就會根據(jù)對應(yīng)的login_type去對應(yīng)的用戶中心進行access_token和openid進行校驗。校驗不通過則返回對應(yīng)錯誤碼 -
校驗通過后就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎(chǔ)信息來作為本地基礎(chǔ)數(shù)據(jù)，并且返回code值 -
如果已經(jīng)存在，那就是進行登錄操作，返回code值。 -
客戶端拿到code值后進行token值的換取，這個完全遵照oauth2.0的協(xié)議來走的，后續(xù)每次請求必須帶上token，token值在服務(wù)端的時間比較久，因為我們想要做的是那種永不下線的操作，所以每次請求我們都將token過期時間進行累加。
數(shù)據(jù)庫設(shè)計
根據(jù)部分小伙伴的的建議，我這里做一下數(shù)據(jù)庫的整理：
用戶基礎(chǔ)表（users）
| 字段 | 備注 |
|---|---|
| user_id | 用戶id |
| token | 用戶登陸的token |
| expire_in | token過期時間 |
| try_times | 登錄失敗次數(shù) |
用戶驗證關(guān)聯(lián)表（user_auth_rel）
| 字段 | 備注 |
|---|---|
| id | 自增id |
| user_id | 用戶id |
| auth_id | 驗證表id |
| auth_type | 驗證類型(local、third) |
本地用戶表（user_local_auth）
| 字段 | 備注 |
|---|---|
| auth_id | 認證id，自增id |
| user_name | 用戶唯一標(biāo)識 |
| password | 用戶密碼 |
| mobile | 用戶手機 |
第三方用戶表（user_third_auth）
| 字段 | 備注 |
|---|---|
| auth_id | 用戶id |
| openid | 第三方用戶唯一標(biāo)識 |
| login_type | 第三方平臺標(biāo)識(qq、wechat...) |
| access_token | 第三方獲取的access_token,校驗使用 |
說明
-
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)演進上也是合乎情理的，開始用戶體系大多自建，而后才是對外接入。
總結(jié)
-
總的來講，第三方用戶的接入技術(shù)上來講是比較簡單的，這里設(shè)計多一個user_thirds是可以支持足夠多的第三方接入，當(dāng)然一般我們也就兩三個登錄就好，太多登錄方不僅自身維護成本，界面擺盤也不好看不是。 -
希望大家能夠通過以上學(xué)習(xí)，能夠?qū)τ谖覀兌噘~戶登錄有一個比較好的認知，這里設(shè)計方案不包含分表分庫、沒有服務(wù)化，就是簡單直接的設(shè)計，當(dāng)然用戶量和需要的不一樣，在這個基礎(chǔ)上還要加很多東西，謝謝大家閱讀??！!
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
