默認
打賞 發表評論 1
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路
閱讀(2927) | 評論(1 收藏3 淘帖1 3

本文引用了“低調的碼農”原創文章“多賬戶的統一登錄”一文的部分內容,感謝原作者的無私分享。


1、引言


在即時通訊網經常能看到各種高大上的高并發、分布式、高性能架構設計方面的文章,平時大家參加的眾多開發者大會,主題也都是各種高大上的話題——什么5G啦、AI人工智能啦、什么阿里雙11分分鐘多少萬QPS高并發等等。

但實際上,對于普通的開發者(包括IM開發人員)來說,多數公司、多數團隊也都是干著默默無聞、平淡無奇的產品開發,并沒有那么多高并發、高大上的事情可以做。

就拿一個IM系統來說,無論你的架構設計考慮了多少分布式、高吞吐、高可用,所有這些事情只要落地,那編碼的第一件事情就是要實現幾乎所有信息系統都要面對的任務——如何設計賬號登錄功能?

本文將分享幾種典型的移動端賬號登陸方式的技術原理,以及設計思路,理解后,完全可以快速實施于你的各種應用系統(并不限于IM系統)中。本文閱讀對像主要為剛入門的開發人員,請程序老司機們嘴下留情哦。

IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_c.jpg

通過本篇文章, 你可以學到:

  • 1)主流賬號登陋技術方案細節;
  • 2)相應的表設計;
  • 3)相應的流程設計。

通過本篇文章, 你無法學到:

  • 與其他原理性的文章一樣,本篇不涉及具體代碼實現細節(對于程序員來說,只要思路搞通,代碼咋寫都不會太爛,大家應該都有體會)。

2、IM開發干貨系列文章


本文是系列文章中的第20篇,總目錄如下:


3、最經典的用戶名密碼注冊登陸方式


一個典型的用戶名密碼注冊登陸功能類似于下面這樣:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_x1.png

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

它的技術原理流程圖如下:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_1.png

如上圖所示,詳細的流程說明如下:

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

這種經典的注冊登陸方式,具體怎么設計就不在這里贅述了,誰都懂。

4、現今最主流的手機號注冊登陸方式


4.1基本原理


典型的手機號注冊登陸功能類似于下圖:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_2.jpg

典型的手機號注冊技術原理流程圖如下:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_2.png

如上圖所示,詳細的流程說明如下:

  • 1)首先輸入手機號:然后發送到服務端,服務端將手機號記錄在我們數據庫中,然后生成隨機驗證碼,并將手機號和驗證碼綁定到一個redis里面,然后記錄過期時間,這個過期時間一般是10分鐘左右,這就是我們一般手機驗證碼的有效期;
  • 2)手機接收到手機短信后:那么就在界面填寫驗證碼發送服務端,服務端收到驗證碼后就會在redis里面查詢到這個手機號對應的驗證碼,失敗就返回錯誤碼。
  • 3)成功后:就進行登錄操作。

這里看起來沒有明確的注冊登錄操作,其實在發送手機號碼就可以認為是一個常規的注冊,然后后面的驗證碼輸入就是一個登陸操作。

但這種區別于常見的用戶名密碼注冊方式,是沒有密碼的的。

問: 那我要密碼咋辦?

答: 在后續產品里面增加一個手機號碼密碼補錄的功能即可,這也是現在很常規的手法,但是現在移動互聯網大爆炸時代,密碼已經顯得不是那么重要了,反正我從來記不住密碼,如果手機號碼能操作的app,絕對不用密碼來操作。

4.2具體的數據庫設計


表結構:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_t1.jpg

說明:
這里只是單純說明需要用到的數據,沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。

5、一種輔助的登陸方式:第3方賬號登陸


5.1基本原理


現在很多應用為了降低新用戶的使用門檻,都會對接第3方賬號進行登陸(比如:用微信號登陸、QQ號登陸、微博賬號登陸等)。

這里我以QQ的開放平臺登錄邏輯為例進行講解。

某團外賣的QQ賬號登陸功能如下圖:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_3.jpg

我們先來一波時序圖:
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_3.png

時序流程詳細說明:

  • 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登錄接入指南》、《第三方賬號登錄功能接入完全流程》。

5.2具體的數據庫設計


表結構:

對于讀者的建議,我這里做一下數據庫的整理。

用戶基礎表(users):
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_t2.jpg

用戶驗證關聯表(user_auth_rel):
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_t3.jpg

本地用戶表(user_local_auth):
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_t4.jpg

第三方用戶表(user_third_auth):
IM開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路_t5.jpg

表結說明:

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

6、本文小結


總的來講,賬號注冊登錄功能在一般的系統里都是入口功能,一般情況下都不會太復雜。

對于第三方用戶的接入技術,也同樣比較簡單,我文章里設計多一個user_thirds是可以支持足夠多的第三方接入,當然一般我們也就兩三個登錄就好,太多登錄方不僅自身維護成本,界面擺盤也不好看不是。

希望大家能夠通過以上學習,能夠對于賬戶注冊登錄有一個比較好的認知,文章里設計方案不包含分表分庫、沒有服務化,就是簡單直接的設計,當然用戶量和需要的不一樣,在這個基礎上還要加很多東西,謝謝大家閱讀。

附錄:更多IM開發方面的文章


[1] IM開發綜合文章:
新手入門一篇就夠:從零開發移動端IM
移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”
移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結
從客戶端的角度來談談移動端IM的消息可靠性和送達機制
現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障
騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路
小白必讀:閑話HTTP短連接中的Session和Token
IM開發基礎知識補課:正確理解前置HTTP SSO單點登陸接口的原理
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用字節流好還是字符流好?
請問有人知道語音留言聊天的主流實現方式嗎?
一個低成本確保IM消息時序的方法探討
完全自已開發的IM該如何設計“失敗重試”機制?
通俗易懂:基于集群的移動端IM接入層負載均衡方案分享
微信對網絡影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)
開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)
騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(上篇)
騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(下篇)
如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源
基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的?
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)
字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8
全面掌握移動端主流圖片格式的特點、性能、調優等
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
自已開發IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)
融云技術分享:解密融云IM產品的聊天消息ID生成策略
適合新手:從零開發一個IM服務端(基于Netty,有完整源碼)
拿起鍵盤就是干:跟我一起徒手開發一套分布式IM系統
>> 更多同類文章 ……

[2] 有關IM架構設計的文章:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐
社交軟件紅包技術解密(八):全面解密微博紅包技術方案
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途
多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了
從游擊隊到正規軍(一):馬蜂窩旅游網的IM系統架構演進之路
從游擊隊到正規軍(二):馬蜂窩旅游網的IM客戶端架構演進和實踐總結
IM開發基礎知識補課(六):數據庫用NoSQL還是SQL?讀這篇就夠了!
瓜子IM智能客服系統的數據架構設計(整理自現場演講,有配套PPT)
阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:求助IM中發送者怎么監聽接收者是否在線且處于正在聊天的狀態?下一篇:即時通訊安全篇(八):你知道,HTTPS用的是對稱加密還是非對稱加密?

本帖已收錄至以下技術專輯

推薦方案
評論 1
流程圖畫的很詳細,很好
簽名: 星期六,那又怎樣,還是得上班
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
乐彩网17500