关于架构设计:亿级用户中心的设计与实践

14次阅读

共计 5193 个字符，预计需要花费 13 分钟才能阅读完成。

用户核心是互联网最为根底的外围零碎，随着业务和用户的增长，势必会带来一直的挑战。如何在亿级的状况下保证系统的高可用，高性能以及高平安，本文可能给你一套实际计划。

注 1：本文探讨的是微服务框架下的用户核心，不波及受权等性能；

注 2：本文所波及的用户核心设计与 vivo 本身业务无关。

用户核心，顾名思义就是治理用户的中央，简直是所有互联网公司最为外围的子系统之一。它的外围性能是登录与注册，次要性能是批改明码、换绑手机号码、获取用户信息、批改用户信息和一些延长服务，同时还有登录之后生成 Token 以及校验 Token 的性能。上面咱们从几个维度来拆解用户核心。

用户核心既须要为用户提供服务，也会承当其余业务的频繁调用；既然须要为用户提供服务，它就会自带一些业务逻辑，比方用户在登录过程中须要风控或短信的校验，那么就会存在不可用的危险。而比方获取用户信息的接口，则没有那么多的依赖，可能只须要调用数据库或者缓存就能够。获取用户信息接口要求稳固，而外围的登录注册接口也须要稳固，然而当咱们在接口层面加一些策略或者批改的时候，不心愿因为上线问题导致整个服务不可用，而且上线后，须要对整个服务性能做全量的回归，导致资源重大节约。

因而，基于业务个性，咱们能够将用户核心拆成 3 个独立的微服务: 网关服务，外围服务，异步消费者服务。网关服务，提供 http 服务，聚合了各种业务逻辑和服务调用，比方登录时候须要校验的风控或者短信；外围服务，解决简略的业务逻辑以及数据存储，外围服务处在调用链路的终端，简直不依赖调用其余服务，比方校验 Token 或者获取用户信息，他们就只依赖于 redis 或者数据库；而异步消费者服务，则解决并生产异步音讯。下文会具体介绍。

这样的设计之后，当有新性能上线时，外围服务和异步生产服务简直不须要从新公布，只须要公布网关服务，依赖咱们外围服务的第三方十分释怀，层级也十分的清晰。当然，这样做的代价就是服务的调用链路变长了。因为波及到网关和外围服务，就须要公布两个服务，而且要做兼容性测试。

用户核心的接口波及到用户的外围信息，安全性要求高；同时，承接了较多第三方的调用，可用性要求也高。因而，对用户核心的接口做以下设计：

首先，接口能够拆分为面向 Web 和面向 App 的接口。Web 接口须要做到跨域状况下的单点登录，加密、验签和 token 校验的形式也同 App 端的不一样。

其次，对外围接口做非凡解决。比方登录接口，在逻辑和链路上做了一些优化。为什么要对这些接口做非凡解决呢？如果用户不能登录，用户会十分恐慌，客诉量会立马上来。

那怎么做呢？一方面，咱们将用户外围信息表做简略。用户的信息当中会蕴含 userId、手机号码、明码、头像、昵称等字段，如果把用户的这些所有信息都保留在一张表中，那么这张表将会异样宏大，变更字段变得异样艰难。因而，须要将用户表拆分，将外围的信息保留在用户表中，比方 userId、username、手机号码、明码、盐值（随机生成）等；而一些如性别，头像，昵称等信息保留在用户材料表中。

另一方面，咱们须要将登录的外围链路做短，短到只依赖于读库。个别状况下，用户登录后，须要记录用户登录信息，调用风控或者短信等服务。对于登录链路来说，任何一个环节呈现问题都有可能导致用户无奈登录，那么怎么样能力做到最短的链路呢？办法就是依赖的服务可主动降级。比如说反欺诈校验出问题了，那么它主动降级后应用它的默认策略，极其状况下只做明码校验，主库挂了之后还能到从库读取用户信息。

最初就是接口的安全性校验。对 App 接口咱们须要做防重放和验签。验签可能大家比拟相熟，然而对防重放这个概念可能绝对生疏。防重放，顾名思义就是避免申请反复发送。用户申请在特定时间段内只能申请一次。即便用户申请被攻击者挟持，在一段时间内也无奈反复申请。如果攻击者想要篡改用户申请再发送，对不起，申请不会通过。得益于大数据的反对，联合终端，咱们还能够把每个用户行为画像存储在零碎中（或者调用第三方服务）。用户发动申请后，咱们的接口会依据用户画像对用户进行诸如手机号码校验、实名认证、人脸或者活体校验。

随着用户的增长，数据超过了 1 亿，怎么办？常见的方法就是分库分表。咱们来剖析一下用户核心常见的一些表构造：用户信息表，第三方登录关联表，用户事件表。从上述表中能够看进去，用户相干的数据表增长绝对迟缓，因为用户增长是有天花板的。用户事件表的增长是呈指数级增长，因为每个用户登录、变更等明码及变更手机号码等操作是不限次数。

因而，首先咱们能够先把用户信息表垂直切分。正如下面说的，将用户 ID、明码、手机号、盐值等常见字段从用户信息表中拆分，其余用户相干的信息用独自一张表。另外，把用户事件表迁徙至其余库中。相比于程度切分，垂直切分的代价绝对较少，操作起来绝对简略。用户外围信息表因为数据量绝对较少，即便是亿级别的数据，利用数据库缓存的机制，也可能解决性能问题。

其次，咱们能够利用前后台业务的个性采纳不同的形式来区别对待。对于用户侧前台拜访：用户通过 username/mobile 登录或者通过 uid 来查问用户信息。用户侧信息的拜访通常是单条数据的查问，咱们能够通过索引屡次查问来解决一致性和高可用问题。对于经营侧后盾拜访：依据年龄、性别、登录时间段、注册时间段等来进行查问，基本上都是批量分页查问。然而因为是外部零碎，查问量低，对一致性要求低。如果用户侧和经营侧的查问采纳同一个数据库，那么经营侧的排序查问会导致整个库的 CPU 回升，查问效率降落，影响到用户侧。因而，经营侧应用的数据库能够是和用户侧同样的 MySQL 离线库，如果想要减少经营侧的查问效率，能够采纳 ES 非关系型数据库。ES 反对分片与复制，不便程度宰割和扩大，复制保障了 ES 的高可用与高吞吐，同时可能满足经营侧的查问需要。

最初，如果还是要程度切分来保证系统的性能，那么咱们采取什么样的切分形式呢？常见的办法有索引表法和基因法。索引表法的思路次要是 UID 可能间接定位到库，然而手机号码或者 username 是无奈间接定位到库的，须要建设一个索引表来记录 mobile 与 UID 或者 username 与 UID 的映射关系的形式来解决这个问题。通常这类数据比拟少，能够不必分库分表，然而相比间接查问，多了一次数据库查问的同时，在新增数据的时候还多了一次映射关系的插入，事务变大。基因法的思路是咱们将 username 或者 mobile 融入到 UID 中。具体做法如下：、

用户注册时，依据用户的手机号码，利用函数生成 N bit 的基因 mobile\_gen，使得 mobile\_gen=f(mobile);
生成 M bit 全局惟一的 id，作为用户标识；
拼接 M 和 N，作为 UID 赋给用户；
依据 N bit 来取余来插入到特定数据库；
查找用户数据的时候，将用户 UID 的后 N bit 取余来落到最终的库中。

从上述过程中看，基因法只实用于某类常常查问的场景，比方用手机号码登录，如果用户应用 username 登录就比拟麻烦了。因而大家以依据本人的业务场景来抉择不同的形式程度切分。

用户登录之后，另一个重要的事件就是 Token 的生成与校验。用户的 Token 分为两类，一类是 web 端登陆生成的 Token，这个 Token 能够和 Cookie 联合，达到单点登陆的成果，在此不细说了。另外一类就是 APP 端登录生成的 Token。用户在咱们的 APP 输出用户名明码之后，服务端会对用户的用户名明码进行校验，胜利之后从系统配置核心获取加密算法的版本以及秘钥，并依照肯定的格局排列用户 ID，手机号、随机码以及过期工夫，通过一系列的加密之后，生成了 Token 之后并将其存入 Redis 缓存。而 Token 的校验就是把用户 ID 和 Token 组合并校验是否在 Redis 中存在。那么如果 Redis 不可用了怎么办呢？这里有一个高可用和主动降级的设计。当 Redis 不可用的时候，服务端会生成一个非凡格局的 Token。当校验 Token 的时候，会对 Token 的格局进行一个判断。

如果判断为 Redis 不可用时生成的 Token，那么服务端会对 Token 进行解密，而 Token 的生成是由用户 ID，手机号、随机码和过期工夫等数据依照特定顺序排列并加密而来的，那么解密进去的数据中也蕴含了 ID，手机号码，随机码和过期工夫。服务端会依据获取到的数据查询数据库，比对之后通知用户是否登录胜利。因为内存缓存 redis 和数据库缓存性能的差距，在 redis 不可用的状况下，降级有可能会导致数据库无奈及时响应，因而须要在降级的办法上退出限流。

数据安全对用户核心来说十分重要。敏感数据须要脱敏解决，对明码更是要做多重的加密解决。利用尽管有本人的安全策略，但如果把黑客限度在登录之前，那利用的安全性将失去大幅度的晋升。互联网上用户明文数据受到泄露的案件每每产生，因而各大企业对数据安全的意识也提到了前所未有的高度。而即便应用了 MD5 和 salt 的加密形式，仍然能够应用彩虹表的形式来破解。那么用户核心对用户信息是怎么保留的呢？

首先，正如上文中提到的用户明码、手机号等登录信息和其余的信息拆散，而且在不同的数据库中。其次，对用户设置的明码进行了黑名单校验，只有符合条件的弱明码，都会回绝提交，因为不论应用了什么加密形式的弱明码，都极其容易破解。为什么呢？因为人的忘性很差，大部分人总是最偏向于抉择生日，单词等来当明码。6 位纯数字能够生成 100 万个不同的明码，8 位小写字母和数字的组合大略能够生成 2.8 万亿个不同的明码。一个规模为 7.8 万亿的明码库足以笼罩大部分用户的明码，对于不同的加密算法都能够领有这样一个明码库，这也就是为什么大部分网站都倡议用户应用 8 位以上数字加字母明码的起因。当然，如果一方面加了盐值，另一方面对密钥离开保存，破解难度会指数级减少。

最初，能够用 bcrypt/scrypt 的形式来加密。bcrypt 算法是基于 Blowfish 块密钥算法来实现的，bcrypt 外部实现了随机加盐解决，应用 bcrypt 之后每次加密后的密文都不一样，同时还会应用内存初始化 hash 过程。因为应用内存，尽管在 CPU 上运行很快，然而在 GPU 上并行运算并不快。随着新的 FPGA 集成了大型 RAM，解决了内存密集 IO 的问题，然而破解难度仍然不小。而 scrypt 算法补救了 bcrypt 算法的有余，它将 CPU 计算与内存应用开销都指数级晋升了。bcrypt 和 scrypt 算法可能无效抵挡彩虹表，然而安全性的晋升带来了用户登录性能的降落。用户登录注册并不是一个高并发的接口，所以影响并不会特地大。因而在平安和性能方面须要根据业务类型和大小来做均衡，并不是所有的利用都须要应用这种加密形式来爱护用户明码。

此处的异步生产，就是上文提到的异步生产服务。用户在做完登录注册等操作后，须要记录用户的操作日志。同时，用户注册登录结束后，上游业务须要对用户减少积分，赠送礼券等处分操作。这些零碎如果都同步依赖于用户核心，那么整个用户核心将异样宏大，链路十分简短，也不合乎业内的“大零碎做小“的准则。依赖的服务不可用之后将会造成用户无奈登录注册。因而，用户核心在用户操作完之后，将用户事件入库后发送至 MQ，第三方业务监听用户事件。用户核心和上游业务解耦，同时用户操作事件入库后，在 MQ 不可用或者音讯失落的时候可做弥补解决。用户的画像数据也在很大水平上来源于此处的数据。

用户核心波及到用户的登录注册更改明码等外围性能，是否及时发现零碎的问题成为要害指标，因而对业务的监控显得尤为重要。须要对用户核心重要接口的 QPS、机器的内存使用量、垃圾回收的工夫、服务的调用工夫等做具体的监控。当某个接口的调用量降落的时候，监控会及时发出报警。除了这些监控之外，还有对数据库 Binlog 的写入，前端组件，以及基于 ZipKin 全链路调用工夫的监控，实现从用户发动端到完结端的全面监控，哪怕呈现一点问题，监控随时会通知你哪里出问题了。比方经营互动推广注册量降落的时候，用户核心就会发出报警，能够及时告诉业务方改过问题，挽回损失。

本文从服务架构设计，接口设计，token 降级，数据安全和监控等方面介绍了亿级用户核心的设计，当然用户核心的设计远不止这些，还会蕴含用户数据的分库分表，熔断限流，第三方登录等，在本文中就不一一赘述。只管本文中设计的用户核心可能满足大部分公司的需要，然而还存在一些比拟大的挑战：在鉴权服务增长的状况下，如何平滑的从用户核心剥离；监控的侵入性以及监控的粒度的欠缺；另外服务的安全性、可用性、性能的晋升永远都没有止境，也是咱们孜孜追求的指标。在将来的日子里，心愿可能通过大家的致力，使用户核心的技术体系更上一层楼。