1、引言
在即時通訊網經常能看到各種高大上的高并發、分布式、高性能架構設計方面的文章，平時大家參加的眾多開發者大會，主題也都是各種高大上的話題——什么5G啦、AI人工智能啦、什么阿里雙11分分鐘多少萬QPS高并發等等。
但實際上，對于普通的開發者（包括IM開發人員）來說，多數公司、多數團隊也都是干著默默無聞、平淡無奇的產品開發，并沒有那么多高并發、高大上的事情可以做。
就拿一個IM系統來說，無論你的架構設計考慮了多少分布式、高吞吐、高可用，所有這些事情只要落地，那編碼的第一件事情就是要實現幾乎所有信息系統都要面對的任務——如何設計賬號登錄功能？
本文將分享幾種典型的移動端賬號登陸方式的技術原理，以及設計思路，理解后，完全可以快速實施于你的各種應用系統（并不限于IM系統）中。本文閱讀對像主要為剛入門的開發人員，請程序老司機們嘴下留情哦。
通過本篇文章， 你可以學到：
1）主流賬號登陋技術方案細節；
2）相應的表設計；
3）相應的流程設計。
通過本篇文章， 你無法學到：
與其他原理性的文章一樣，本篇不涉及具體代碼實現細節（對于程序員來說，只要思路搞通，代碼咋寫都不會太爛，大家應該都有體會）。
學習交流：
- 即時通訊/推送技術開發交流5群：215477170[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2863-1-1.html）
2、IM開發干貨系列文章
本文是系列文章中的第20篇，總目錄如下：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》
《移動端IM登錄時拉取數據如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《淺談移動端IM的多點登陸和消息漫游原理》
《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登陸接口的原理》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《IM群聊消息的已讀回執功能該怎么實現？》
《IM群聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)？》
《IM開發基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《一個低成本確保IM消息時序的方法探討》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《IM里“附近的人”功能實現原理是什么？如何高效率地實現它？》
《IM開發基礎知識補課(七)：主流移動端賬號登錄方式的原理及設計思路》（本文）
3、最經典的用戶名密碼注冊登陸方式
一個典型的用戶名密碼注冊登陸功能類似于下面這樣：
這種賬號登陸方式很經典也很常用，先注冊、再進行登錄，尤其在老一點的CMS系統、網站系統、聊天應用中都能找到這個影子。
它的技術原理流程圖如下：
如上圖所示，詳細的流程說明如下：
- 1）前端將用戶名、密碼發送到服務器，服務器進行常規的判斷，判斷用戶名、密碼長度是否滿足，用戶名是否重復等條件，條件不通過直接返回對應錯誤碼給到前端，這里密碼字段，為了防止傳輸過程中被截胡，建議加密再上傳，我們的傳輸密碼默認都是會進行一個md5加密，然后記錄到數據庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。
- 2）校驗通過后，就將用戶名密碼寫入數據庫，并進行后面積分發放等操作，這里不展開。
- 3）現在進行登錄，前端將用戶名，密碼發送給到服務端，服務端首先會校驗登錄次數是否超過設置的閾值，如果超過只能繼續等待被關小黑屋。
- 4）如果未超過繼續登錄邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，如果超過則關小黑屋，記住小黑屋必須設置過期時間，要不然就會永久關上了，這個可以用redis的過期來做。
- 5）登錄成功后進行后續的一切后置邏輯，比如加積分。。。等操作。
這種經典的注冊登陸方式，具體怎么設計就不在這里贅述了，誰都懂。
4、現今最主流的手機號注冊登陸方式
4.1 基本原理
典型的手機號注冊登陸功能類似于下圖：
典型的手機號注冊技術原理流程圖如下：
如上圖所示，詳細的流程說明如下：
- 1）首先輸入手機號：然后發送到服務端，服務端將手機號記錄在我們數據庫中，然后生成隨機驗證碼，并將手機號和驗證碼綁定到一個redis里面，然后記錄過期時間，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期；
- 2）手機接收到手機短信后：那么就在界面填寫驗證碼發送服務端，服務端收到驗證碼后就會在redis里面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。
- 3）成功后：就進行登錄操作。
這里看起來沒有明確的注冊登錄操作，其實在發送手機號碼就可以認為是一個常規的注冊，然后后面的驗證碼輸入就是一個登陸操作。
但這種區別于常見的用戶名密碼注冊方式，是沒有密碼的的。
問： 那我要密碼咋辦？
答： 在后續產品里面增加一個手機號碼密碼補錄的功能即可，這也是現在很常規的手法，但是現在移動互聯網大爆炸時代，密碼已經顯得不是那么重要了，反正我從來記不住密碼，如果手機號碼能操作的app，絕對不用密碼來操作。
4.2 具體的數據庫設計
表結構：
說明：
這里只是單純說明需要用到的數據，沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。
5、一種輔助的登陸方式：第3方賬號登陸
5.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登錄接入指南》、《第三方賬號登錄功能接入完全流程》。
5.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）整個設計理念就是將自建用戶與第三方在存儲上區分，這在架構演進上也是合乎情理的，開始用戶體系大多自建，而后才是對外接入。
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王者——釘釘在后端架構上的過人之處》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2863-1-1.html）