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

简介: 本文作者将用户系统的设计类比为一次创业项目。深入浅出地介绍了用户系统的设计方式。

前言

本文从最原始的需求出发,结合需求变化,推导出用户系统的演进。

(如果有理解偏差之处,还请谅解,欢迎讨论)

(故事纯属虚构)


一、创业

老王是程序员,出去创业了,做当下最火的web3.0,需要做app和web,第一步需要一个用户登录功能,这对老王来说简单。

image.png

用户可以拿邮箱或者手机注册,填一些基本信息(如名称、性别、年龄等),初始化密码,提交后给用户生成平台唯一id。用户可以拿手机或者邮箱登录,设计如图,搞定了。


二、新增需求-三方登录

产品经理提出为了方便用户快速注册,借助当前用户量最大的平台,实现授权登录,授权登录后经过用户授权从大平台那里拿用户基本信息(手机号,邮箱等等),避免用户注册耗时原因导致用户放弃注册的流失。


安全同学也提出了,有可能用户邮箱泄露,黑客拿着邮箱来调用平台的登录服务暴力破解密码,需要限制验密错误次数以及冻结功能等。


老王想了想,简单,在模型中扩充一些字段就可以解决。把市面上比较火的平台id都预留一下,免得后面一个一个加;同时在把验密失败次数或验密失败时间记录下来,一旦达到一定次数,就不允许调用登录服务。


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

由于业务的发展,用户不在局限于个人用户,一些公司也需要入驻进来,显然,年龄、性别等信息就不再适合给公司用户使用了,到这里,模型必须要拆分了。


老王希望把模型拆成继承关系,用户表作为父类,可以延伸出公司用户和个人用户,如下图所示。

image.png


四、业务扩张了

老王的创业公司发展迅速,开始融资了,不仅nft搞得如火如荼,还要搞某币交易。


某币交易涉及到金融(我们假设老王创业的地方监管环境允许),那么需要进行实人(实体)认证,需要知道用户在法律意义上到底是谁。这里的需求,已经不是纯用户角度了,而是知道你的客户是谁,已经开始向客户系统演进。


另外由于涉及到某币账户操作,因此需要搞一个交易密码,现在很多设备都支持指纹和人脸了,产品希望指纹和人脸也能支持。


老王接到了以上需求,他开始思考以下几个问题:


  1. 密码:现在密码种类变多,从登录密码扩展了交易密码;另外交易密码可以支持普通密码、指纹密码、人脸等子类型。


  1. 登录方式:之前的设计太粗暴了,扩展性很差,之后如果要支持身份证登录,或者营业执照号登录,都需要再加字段。


  1. 实人(实体)认证:真实世界的人或者企业,与之前系统模型中的用户是一个概念吗?假如没有监管的要求,之前用户模型里边的信息,就可以支撑用户在平台上的各种使用诉求(登录、信息显示等等)。


4.1 登录方式

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


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


  • 电子联系方式:手机号、邮箱,用这类方式有个很好的收益,就是密码管理,如果出现被盗或者忘记密码,可以多因子认证(验证码)找回在平台上的账号。


  • 证件号码:身份证、营业执照号等,这类登录方式在政务系统上比较常见,政务系统一般希望直接服务社会上的实人或者组织。


  • 系统生成的id:系统中的唯一id,QQ是最典型的例子,注册QQ会生成一个qq号,需要用户记住直接拿QQ号作为登录名。


  • 三方登录:通过oauth协议,在客户授权的前提下,获取用户在第三方平台的部分信息,比如头像、昵称、唯一id,进行授权登录。


总结一下上述的多种登录方式,除了系统生成的id登录,其他三种都是通过外部系统唯一标识登录,登录系统实际就是维护一个用户记忆的系统外部唯一标识 ——> 系统内部唯一标识的关联关系。而外部系统唯一标识可以有千千万万种,并不能穷举,那么就不能像userV2版本中通过字段的模式,每次新增字段解决。


通过以上的分析,老王从模型层面讲登录方式从用户模型中拆了出来,如下图所示。loginType可以是邮箱、手机号、支付宝、身份证、甚至银行卡号,这些都是能够定义注册人是谁的外部唯一标识(这些标识不可能同时被两个人拥有)。这样,任何外部唯一标识都可以作为系统的登录方式,找到系统中的用户,模型做到了高度可扩展。

image.png


4.2 密码

基于上述需求,密码首先需要定义分类,现在有了登录密码和交易密码的区别,同时交易密码要支持普通密码、指纹密码、人脸密码三种密码,因此再定义一个subtype来标识,如下图所示。

image.png

那么密码和登录方式的关系是啥?是不是每一个登录方式都要定义一个登录密码?显然不是,用户在平台有多个登录方式(登录名:手机、邮箱等),但是不可能让用户每个登录方式都维护一个密码,用户记密码、维护密码都累死了。那么,显然登录方式和登录密码的关系是N:1的。


但是,交易密码怎么实现呢?交易密码是用户维度在交易时的验证,因此,每个用户只需要一个交易密码,那么,我们将模型设计成如下这样,每个用户可以有多种密码,但是在登录的主类型(type)下,只有一个密码。在交易的主类型(type)下,有三个密码,靠子类型(subtype)区分开(数字、指纹、人脸)。


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


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


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

image.png


4.3 实人认证

大部分互联网应用,平台并不用知道注册人的真实信息,互联网精神就是自由开放,有一句上个世纪流行语,你永远不知道网络的另一边是人还是什么。


但是也有一些业务必须知道注册人的真实合法的信息,才能完成业务,比如金融业务,监管要求必须实人认证还有附加的限制规则。比如一些toB的CRM业务,会维护潜客、客户的真实信息,甚至是客户公司的经营情况,这里就涉及到了真实世界是否存在的认定。


因此,我们需要在系统中记录真实世界的合法标识,对于个人有身份证、护照,对于企业有营业执照。那么是不是直接在用户模型中添加一些字段就搞定了?可以这么做,但是有个问题,一个人完全可以在平台中注册多个账户,如果在用户模型维度来承载实人信息,那么每个注册的账户都要维护认证状态,显然是不合理的,如果能够做到一个真实世界的实体(人、组织),在系统中只维护一份,针对这一份认证相关的数据进行维护,无论这个人注册了多少个账号,都关联到这份实体信息上,那么实体是认证过的,所有账号都是认证过的。


那么很显然,由于真实的人和用户在系统中是1:N的关系,在这里抽象了新的模型,我们可以把它命名为客户,模型扩展后如下图所示。客户和用户的设计类似,是一体两面的。一个人的真实信息属于客户这个领域,而一个人在平台里边可以有多个账号登录,使用平台的服务,因此系统中为了登录和现实信息相关的数据,都属于用户这个领域。没有客户域的数据,是可以在系统中运行的(使用系统服务),这就是用户领域的职责。那么客户领域的职责是什么?我认为是维护客户关系,要维护客户关系第一步是知道你的客户是谁,是不是真实的,在这之后,就可以进行营销相关的操作,将客户从潜客发展成资深客户,同时不断完善客户信息,包括不限于真实信息、喜好、消费习惯等等。所以,实人就是客户信息建设的第一步。

image.png

image.png


4.4 其他问题

到这里模型好像已经很强大了,对于老王的创业团队来说可以支撑很多情况,我们在回顾下整个模型,客户是真实世界存在的实体的反映,登录方式是断定注册人是谁的外部唯一标识,这两个概念互相之间貌似是有关系的。也就是说,登录方式里边的手机号、邮箱都是真实世界的实体所拥有的唯一标识。同一个手机号不可能同时被两个人拥有,并且用作平台的登录名。


那么在4.3提到,一个人在平台上可以有多个账户,比如张三,刚开始作为nft的用户用手机号注册了一个账号,过了一段时间他开了一家公司,想在平台上开店,张三希望还是用这个手机号来登录(这个例子举得并不恰当,大家不要当真)。这个场景下,登录方式和用户变成了1:2的关系。

image.png

手机号作为我的唯一标识,我希望在一个平台只需要手机号就能登陆,同时我在平台可能有多个身份,因此登录方式需要升级一下。无论有多少登录方式,都是为了识别出真实世界的人是谁在登录,因此抽象实体外标并分配一个id,就代表了这个人在登录,登录成功之后,可以选择具体的身份,比如个人用户或者企业用户。


密码模型不再和userId强关联,抽象出targetEntity字段可以对登录、用户甚至客户等维度做密码验证。当前登录密码场景直接通过实体外标的id关联,交易密码场景通过userid关联。

image.png

image.png

到这里,整个模型比较完备了。


五、总结

总结一下前边的模型,简化下来就是下图的关系,登录名就是标识,系统用来判定实际是谁在注册,用登录名登录后,可以选择一个身份在系统中操作,可以是卖家(经营店铺),也可以是买家(逛店+购物),还可以是客服(负责与买家沟通,处理异常订单)。


该模型中每一个抽象都充分考虑了业务场景的需求,非常灵活,可以支撑大用户量级的各种需求。

image.png


作者 | 徐浩(銆然

来源 | 阿里云开发者公众号

相关文章
|
8月前
|
存储 监控 搜索推荐
内容管理系统CMS是什么?全面解读CMS的核心功能
2分钟了解内容管理系统CMS的主要作用和常见平台。CMS常被用于简化内容管理流程,提高内容发布效率。
2485 7
内容管理系统CMS是什么?全面解读CMS的核心功能
|
9月前
|
存储 人工智能 数据库
面向金融场景的大模型 RAG 检索增强解决方案
本方案为您介绍,如何使用人工智能平台 PAI 构建面向金融场景的大模型 RAG 检索增强解决方案。
|
小程序 前端开发 JavaScript
微信小程序实现微信支付(代码和注释很详细)
微信小程序实现微信支付(代码和注释很详细)
|
存储 监控 供应链
聊聊「订单」业务的设计与实现
订单业务一直都是系统研发中的核心模块,订单的产生过程,与系统中的很多模块都会高度关联,比如账户体系、支付中心、运营管理等,即便单看订单本身,也足够的复杂;
12065 3
聊聊「订单」业务的设计与实现
|
11月前
|
数据采集 存储 Go
如何使用Colly库进行大规模数据抓取?
如何使用Colly库进行大规模数据抓取?
|
中间件 测试技术 持续交付
FastAPI测试秘籍:如何通过细致的测试策略确保你的代码在真实世界的挑战面前保持正确和稳定?
【8月更文挑战第31天】在软件开发中,测试至关重要,尤其在动态语言如Python中。FastAPI不仅简化了Web应用开发,还提供了强大的测试工具。通过`unittest`框架和Starlette测试客户端,开发者可以轻松编写和执行测试用例,确保每个功能按预期工作。本文将详细介绍如何设置测试环境、编写基础和高级测试用例,并探讨中间件和依赖项测试。此外,还将介绍如何在持续集成环境中自动化测试,确保代码质量和稳定性。利用FastAPI的测试工具,你可以构建出高效可靠的Web应用。
193 0
|
程序员 Shell C语言
【C/C++ main函数】深入探索C++中的main函数及其参数
【C/C++ main函数】深入探索C++中的main函数及其参数
1410 0
|
存储 SQL 关系型数据库
万级TPS亿级流水-中台账户系统架构设计
我们需要给所有前台业务提供统一的账户系统,用来支撑所有前台产品线的用户资产管理,统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力,在万级TPS下保证绝对的数据准确性和数据溯源能力。 >注:资金类系统只有合格和不合格,哪怕数据出现只有0.01分的差错也是不合格的,局部数据不准也就意味着全局数据都不可信。
1746 0
|
存储 前端开发 JavaScript
登录系统及表结构设计
登录系统及表结构设计
1140 0
|
资源调度 前端开发 JavaScript
Axios 请求库入门教程:从零开始学习
Axios 是一个流行的基于 Promise 的 HTTP 请求库,用于在浏览器和 Node.js 中进行 HTTP 请求。
Axios 请求库入门教程:从零开始学习