请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 1
IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路
微信扫一扫关注!

本文引用了“低调的码农”原创文章“多账户的统一登录”一文的部分内容,感谢原作者的无私分享。


1、引言


在即时通讯网经常能看到各种高大上的高并发、分布式、高性能架构设计方面的文章,平时大家参加的众多开发者大会,主题也都是各种高大上的话题——什么5G啦、AI人工智能啦、什么阿里双11分分钟多少万QPS高并发等等。

但实际上,对于普通的开发者(包括IM开发人员)来说,多数公司、多数团队也都是干着默默无闻、平淡无奇的产品开发,并没有那么多高并发、高大上的事情可以做。

就拿一个IM系统来说,无论你的架构设计考虑了多少分布式、高吞吐、高可用,所有这些事情只要落地,那编码的第一件事情就是要实现几乎所有信息系统都要面对的任务——如何设计账号登录功能?

本文将分享几种典型的移动端账号登陆方式的技术原理,以及设计思路,理解后,完全可以快速实施于你的各种应用系统(并不限于IM系统)中。本文阅读对像主要为刚入门的开发人员,请程序老司机们嘴下留情哦。

c.jpg

通过本篇文章, 你可以学到:

  • 1)主流账号登陋技术方案细节;
  • 2)相应的表设计;
  • 3)相应的流程设计。

通过本篇文章, 你无法学到:

  • 与其他原理性的文章一样,本篇不涉及具体代码实现细节(对于程序员来说,只要思路搞通,代码咋写都不会太烂,大家应该都有体会)。

2、IM开发干货系列文章


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


3、最经典的用户名密码注册登陆方式


一个典型的用户名密码注册登陆功能类似于下面这样:
x1.png

这种账号登陆方式很经典也很常用,先注册、再进行登录,尤其在老一点的CMS系统、网站系统、聊天应用中都能找到这个影子。

它的技术原理流程图如下:
1.png

如上图所示,详细的流程说明如下:

  • 1)前端将用户名、密码发送到服务器,服务器进行常规的判断,判断用户名、密码长度是否满足,用户名是否重复等条件,条件不通过直接返回对应错误码给到前端,这里密码字段,为了防止传输过程中被截胡,建议加密再上传,我们的传输密码默认都是会进行一个md5加密,然后记录到数据库再进行一层加密,就算是脱库也没事,密码不要明文存储。
  • 2)校验通过后,就将用户名密码写入数据库,并进行后面积分发放等操作,这里不展开。
  • 3)现在进行登录,前端将用户名,密码发送给到服务端,服务端首先会校验登录次数是否超过设置的阈值,如果超过只能继续等待被关小黑屋。
  • 4)如果未超过继续登录逻辑,判断用户名、密码是否正确,不正确密码则进行阈值的判断,如果超过则关小黑屋,记住小黑屋必须设置过期时间,要不然就会永久关上了,这个可以用redis的过期来做。
  • 5)登录成功后进行后续的一切后置逻辑,比如加积分。。。等操作。

这种经典的注册登陆方式,具体怎么设计就不在这里赘述了,谁都懂。

4、现今最主流的手机号注册登陆方式


4.1基本原理


典型的手机号注册登陆功能类似于下图:
2.jpg

典型的手机号注册技术原理流程图如下:
2.png

如上图所示,详细的流程说明如下:

  • 1)首先输入手机号:然后发送到服务端,服务端将手机号记录在我们数据库中,然后生成随机验证码,并将手机号和验证码绑定到一个redis里面,然后记录过期时间,这个过期时间一般是10分钟左右,这就是我们一般手机验证码的有效期;
  • 2)手机接收到手机短信后:那么就在界面填写验证码发送服务端,服务端收到验证码后就会在redis里面查询到这个手机号对应的验证码,失败就返回错误码。
  • 3)成功后:就进行登录操作。

这里看起来没有明确的注册登录操作,其实在发送手机号码就可以认为是一个常规的注册,然后后面的验证码输入就是一个登陆操作。

但这种区别于常见的用户名密码注册方式,是没有密码的的。

问: 那我要密码咋办?

答: 在后续产品里面增加一个手机号码密码补录的功能即可,这也是现在很常规的手法,但是现在移动互联网大爆炸时代,密码已经显得不是那么重要了,反正我从来记不住密码,如果手机号码能操作的app,绝对不用密码来操作。

4.2具体的数据库设计


表结构:
t1.jpg

说明:
这里只是单纯说明需要用到的数据,没有扩展具体场景,这个表结构能够满足上面两个方案的设计。

5、一种辅助的登陆方式:第3方账号登陆


5.1基本原理


现在很多应用为了降低新用户的使用门槛,都会对接第3方账号进行登陆(比如:用微信号登陆、QQ号登陆、微博账号登陆等)。

这里我以QQ的开放平台登录逻辑为例进行讲解。

某团外卖的QQ账号登陆功能如下图:
3.jpg

我们先来一波时序图:
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):
t2.jpg

用户验证关联表(user_auth_rel):
t3.jpg

本地用户表(user_local_auth):
t4.jpg

第三方用户表(user_third_auth):
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用的是对称加密还是非对称加密?

本帖已收录至以下技术专辑

想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
推荐方案
评论 1
流程图画的很详细,很好
签名: 星期六,那又怎样,还是得上班
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部