创业之路的故事|如何设计一个用户系统

简介: 创业之路的故事|如何设计一个用户系统

前言

本文从最原始的需求出发,结合需求变化,推导出用户系统的演进。(如果有理解偏差之处,还请谅解,欢迎讨论)(故事纯属虚构)

一、创业

老王是程序员,出去创业了,做当下最火的web3.0,需要做app和web,第一步需要一个用户登录功能,这对老王来说简单。用户可以拿邮箱或者手机注册,填一些基本信息(如名称、性别、年龄等),初始化密码,提交后给用户生成平台唯一id。用户可以拿手机或者邮箱登录,设计如图,搞定了。

二、新增需求-三方登录

产品经理提出为了方便用户快速注册,借助当前用户量最大的平台,实现授权登录,授权登录后经过用户授权从大平台那里拿用户基本信息(手机号,邮箱等等),避免用户注册耗时原因导致用户放弃注册的流失。安全同学也提出了,有可能用户邮箱泄露,黑客拿着邮箱来调用平台的登录服务暴力破解密码,需要限制验密错误次数以及冻结功能等。老王想了想,简单,在模型中扩充一些字段就可以解决。把市面上比较火的平台id都预留一下,免得后面一个一个加;同时在把验密失败次数或验密失败时间记录下来,一旦达到一定次数,就不允许调用登录服务。

三、新增需求-用户类型区分

由于业务的发展,用户不在局限于个人用户,一些公司也需要入驻进来,显然,年龄、性别等信息就不再适合给公司用户使用了,到这里,模型必须要拆分了。老王希望把模型拆成继承关系,用户表作为父类,可以延伸出公司用户和个人用户,如下图所示。

四、业务扩张了

老王的创业公司发展迅速,开始融资了,不仅nft搞得如火如荼,还要搞某币交易。某币交易涉及到金融(我们假设老王创业的地方监管环境允许),那么需要进行实人(实体)认证,需要知道用户在法律意义上到底是谁。这里的需求,已经不是纯用户角度了,而是知道你的客户是谁,已经开始向客户系统演进。另外由于涉及到某币账户操作,因此需要搞一个交易密码,现在很多设备都支持指纹和人脸了,产品希望指纹和人脸也能支持。老王接到了以上需求,他开始思考以下几个问题:

  1. 密码:现在密码种类变多,从登录密码扩展了交易密码;另外交易密码可以支持普通密码、指纹密码、人脸等子类型。
  2. 登录方式:之前的设计太粗暴了,扩展性很差,之后如果要支持身份证登录,或者营业执照号登录,都需要再加字段。
  3. 实人(实体)认证:真实世界的人或者企业,与之前系统模型中的用户是一个概念吗?假如没有监管的要求,之前用户模型里边的信息,就可以支撑用户在平台上的各种使用诉求(登录、信息显示等等)。

4.1 登录方式

我们思考一下为什么会有登录方式,登录方式是用来确定系统中的哪个用户正在进行操作(这里先不考虑账号被盗的情况)。只要登录进来,就能在系统中确定是某一个userid(系统内部唯一标识),登录后的所有操作,都可以通过userid来留痕。

登录方式总共有多少种?能穷举吗?目前行业里的登录方式实现基本包含以下几种:

  • 电子联系方式:手机号、邮箱,用这类方式有个很好的收益,就是密码管理,如果出现被盗或者忘记密码,可以多因子认证(验证码)找回在平台上的账号。
  • 证件号码:身份证、营业执照号等,这类登录方式在政务系统上比较常见,政务系统一般希望直接服务社会上的实人或者组织。
  • 系统生成的id:系统中的唯一id,QQ是最典型的例子,注册QQ会生成一个qq号,需要用户记住直接拿QQ号作为登录名。
  • 三方登录:通过oauth协议,在客户授权的前提下,获取用户在第三方平台的部分信息,比如头像、昵称、唯一id,进行授权登录。

总结一下上述的多种登录方式,除了系统生成的id登录,其他三种都是通过外部系统唯一标识登录,登录系统实际就是维护一个用户记忆的系统外部唯一标识 ——> 系统内部唯一标识的关联关系。而外部系统唯一标识可以有千千万万种,并不能穷举,那么就不能像userV2版本中通过字段的模式,每次新增字段解决。通过以上的分析,老王从模型层面讲登录方式从用户模型中拆了出来,如下图所示。loginType可以是邮箱、手机号、支付宝、身份证、甚至银行卡号,这些都是能够定义注册人是谁的外部唯一标识(这些标识不可能同时被两个人拥有)。这样,任何外部唯一标识都可以作为系统的登录方式,找到系统中的用户,模型做到了高度可扩展。

4.2 密码

基于上述需求,密码首先需要定义分类,现在有了登录密码和交易密码的区别,同时交易密码要支持普通密码、指纹密码、人脸密码三种密码,因此再定义一个subtype来标识,如下图所示。那么密码和登录方式的关系是啥?是不是每一个登录方式都要定义一个登录密码?显然不是,用户在平台有多个登录方式(登录名:手机、邮箱等),但是不可能让用户每个登录方式都维护一个密码,用户记密码、维护密码都累死了。那么,显然登录方式和登录密码的关系是N:1的。但是,交易密码怎么实现呢?交易密码是用户维度在交易时的验证,因此,每个用户只需要一个交易密码,那么,我们将模型设计成如下这样,每个用户可以有多种密码,但是在登录的主类型(type)下,只有一个密码。在交易的主类型(type)下,有三个密码,靠子类型(subtype)区分开(数字、指纹、人脸)。

总结一下密码这么设计的好处:

  1. 不同登录方式之间可以共享登录密码,用户不用维护多个登录密码;
  2. 密码根据类型、子类型可以支持多种密码同时存在;

好像登录和密码这么设计很完美了,想一想有没有什么问题。

4.3 实人认证

大部分互联网应用,平台并不用知道注册人的真实信息,互联网精神就是自由开放,有一句上个世纪流行语,你永远不知道网络的另一边是人还是狗。但是也有一些业务必须知道注册人的真实合法的信息,才能完成业务,比如金融业务,监管要求必须实人认证还有附加的限制规则。比如一些toB的CRM业务,会维护潜客、客户的真实信息,甚至是客户公司的经营情况,这里就涉及到了真实世界是否存在的认定。因此,我们需要在系统中记录真实世界的合法标识,对于个人有身份证、护照,对于企业有营业执照。那么是不是直接在用户模型中添加一些字段就搞定了?可以这么做,但是有个问题,一个人完全可以在平台中注册多个账户,如果在用户模型维度来承载实人信息,那么每个注册的账户都要维护认证状态,显然是不合理的,如果能够做到一个真实世界的实体(人、组织),在系统中只维护一份,针对这一份认证相关的数据进行维护,无论这个人注册了多少个账号,都关联到这份实体信息上,那么实体是认证过的,所有账号都是认证过的。那么很显然,由于真实的人和用户在系统中是1:N的关系,在这里抽象了新的模型,我们可以把它命名为客户,模型扩展后如下图所示。客户和用户的设计类似,是一体两面的。一个人的真实信息属于客户这个领域,而一个人在平台里边可以有多个账号登录,使用平台的服务,因此系统中为了登录和现实信息相关的数据,都属于用户这个领域。没有客户域的数据,是可以在系统中运行的(使用系统服务),这就是用户领域的职责。那么客户领域的职责是什么?我认为是维护客户关系,要维护客户关系第一步是知道你的客户是谁,是不是真实的,在这之后,就可以进行营销相关的操作,将客户从潜客发展成资深客户,同时不断完善客户信息,包括不限于真实信息、喜好、消费习惯等等。所以,实人就是客户信息建设的第一步。

4.4 其他问题

到这里模型好像已经很强大了,对于老王的创业团队来说可以支撑很多情况,我们在回顾下整个模型,客户是真实世界存在的实体的反映,登录方式是断定注册人是谁的外部唯一标识,这两个概念互相之间貌似是有关系的。也就是说,登录方式里边的手机号、邮箱都是真实世界的实体所拥有的唯一标识。同一个手机号不可能同时被两个人拥有,并且用作平台的登录名。那么在4.3提到,一个人在平台上可以有多个账户,比如张三,刚开始作为nft的用户用手机号注册了一个账号,过了一段时间他开了一家公司,想在平台上开店,张三希望还是用这个手机号来登录(这个例子举得并不恰当,大家不要当真)。这个场景下,登录方式和用户变成了1:2的关系。

手机号作为我的唯一标识,我希望在一个平台只需要手机号就能登陆,同时我在平台可能有多个身份,因此登录方式需要升级一下。无论有多少登录方式,都是为了识别出真实世界的人是谁在登录,因此抽象实体外标并分配一个id,就代表了这个人在登录,登录成功之后,可以选择具体的身份,比如个人用户或者企业用户。密码模型不再和userId强关联,抽象出targetEntity字段可以对登录、用户甚至客户等维度做密码验证。当前登录密码场景直接通过实体外标的id关联,交易密码场景通过userid关联。到这里,整个模型比较完备了。

五、总结

总结一下前边的模型,简化下来就是下图的关系,登录名就是标识,系统用来判定实际是谁在注册,用登录名登录后,可以选择一个身份在系统中操作,可以是卖家(经营店铺),也可以是买家(逛店+购物),还可以是客服(负责与买家沟通,处理异常订单)。该模型中每一个抽象都充分考虑了业务场景的需求,非常灵活,可以支撑大用户量级的各种需求。

相关文章
|
6月前
|
安全 程序员 数据安全/隐私保护
创业之路的故事|如何设计一个用户系统
本文作者将用户系统的设计类比为一次创业项目。深入浅出地介绍了用户系统的设计方式。
|
Cloud Native 程序员 Serverless
你眼中的程序员 vs 程序员眼中的自己,是时候打破刻板印象了丨KubeCon 主题活动
你眼中的程序员 vs 程序员眼中的自己,是时候打破刻板印象了丨KubeCon 主题活动
|
Cloud Native 数据库 运维
认证故事|我的成长之路。
学习的动力来源于成就感,当有了一次的成功,就会触发您后续的持之以恒; 而往往第一次的成功所要下定的决心和努力都是最厚重的。
524 2
认证故事|我的成长之路。
|
弹性计算 人工智能 移动开发
我与云开发的故事
分享在云开发当中的开发感受,心得体验,以及成长经验!
460 0
我与云开发的故事
WM
|
存储 canal 开发框架
我所经历的创业公司是如何做技术的?--《我与开源的故事》
人类的文明得以快速发展,很重要的一点在于我们可以站在巨人的肩膀上继续探索。而开源世界之于互联网行业来说就是这个巨人之一, 本文将重点阐述作者本人所了解的开源世界,以及如何通过开源项目做出有效个工作产出。
WM
9081 0
我所经历的创业公司是如何做技术的?--《我与开源的故事》
|
消息中间件 人工智能 自然语言处理
真实如刀的洞见:和扶墙老师聊技术、组织和商业
真实如刀的洞见:和扶墙老师聊技术、组织和商业
417 0
真实如刀的洞见:和扶墙老师聊技术、组织和商业
|
云计算
我和阿里云认证的故事#2021努力并成长#
云计算现在是最优先考虑的业务。我们专注于保持领先地位,增强实力,帮助我们的客户利用云重新创造他们的业务。您在这段旅程中至关重要,我们致力于提升您的云计算技能和职业生涯。 为了给您提供培训和认证,为您提供正确的工具,让您在云职业生涯中学习和成长,我们将按照以下时间表推出一批新的认证-阿里云ACP.
159 0
路歌,15亿背后的ALPD故事
数字经济时代,阿里云已经不仅仅是庞大的云基础设施。基于丰富的实践经验和技术优势,阿里云为企业提供随时随地的智能移动协同,重塑运营管理流程,帮助企业数字化升级。
5177 0
|
分布式计算 大数据 专有云
关涛:接手一个6年的平台型系统,我是如何带领团队破局前行的
12月20日的北京云栖大会上,由云栖社区主办的开发者技术进阶峰会再度开启,在此之前,我们整理了2017杭州云栖大会开发者技术进阶专场上的精彩分享内容。
5278 0