从公共业务提取来看架构演进—

1. 引言

在产品业务多元化的过程中，往往会遇到一些与业务发展不匹配的架构问题，这些问题可能会在业务迭代中以性能差、重复开发等形式表现出来，进而给系统的扩展和维护带来一些挑战。

本文准备以一个帐号权限的业务为例，来讨论下：当遇到架构问题时，如何识别并及时调整，以适应业务的发展。

在问题开始之前，先对帐号的权限作下说明，以便更好的理解。

在本文中，权限是指帐号在一个产品系统中能允许使用的功能列表。以视频会议产品举例大概如下图所示：

一个帐号在多个产品中可能会有多套权限，就权限的理解达成一致后，下面我们进入正文。

2. 问题

企业有一个合同计费系统叫作Boss, 负责合同和帐号权限的开通, 它和业务系统之间的交互形式最初可能是这样：

一个帐号在系统中有两套组件权限：网络会议组件权限和云会议组件权限
开通帐号时，boss将两组权限分别下发到网络会议平台和云会议系统，由每个系统分别管理自己职责范围内的帐号权限数据。

如下图所示：
在这里插入图片描述

看起来也挺清晰，boss和业务之间耦合少，不用关心产品的业务迭代，只通过回调机制来同步帐号数据。

但这可能只是第一个版本，随着公司产品和业务的发展，又上线了一些系统，如：

电话业务
直播业务
课堂业务

并且一个帐号有可能同时开通这些业务，Boss就要向多个产品系统都同步数据，系统模型演变成下图所示：
在这里插入图片描述

上图中红色的气泡里也有指明，随着产品业务线的扩张，带出了不少问题，例如：

开通慢：开通帐号要回调的业务系统越来越多，由于Boss要等每个业务系统都回复处理成功后帐号才算开通完成，所以帐号开通速度就变得越来越慢；
重复做：各个产品都要自己维护一份帐号权限数据，并且业务逻辑相似，代码也类同；
扩展差：各个团队对帐号权限这块儿业务数据的理解层次不齐，直接表现是代码扩展性不足，导致的结果是：每当产品要增加功能权限时，对应系统的代码和DB结构就要不停的跟着调整。

尤其是第1个问题，当面向C端的个人注册上线后，这个帐号开通慢的问题就如同被拿到放大镜下，在用户侧直接表现一种很差的体验，例如：

用户提交注册表单成功了，但打开产品的客户端却无法登录，原因在于向业务系统的帐号同步工作是后台异步进行的，还未同步完。

这种问题在目前的系统模型下几乎没什么有效的根治办法，只能让用户等待。但等待也就意味着体验差、用户流失。

而且随着业务的多元化继续发展，帐号开通速度还会变得更慢。如果帐号开不出来，就等于是把用户挡在了门外面，产品都没有展示给用户的机会，所以问题还是相当棘手的。

那如何解决呢？

3. 方案思路

对于此问题的解决思路，我们从架构调整、存储优化、可扩展性三个方面来描述具体的优化方案。

3.1 架构调整

上面提到，各个产品对帐号权限的维护工作几乎是相同的。因此，我们可以尝试把帐号权限从各个产品中提取出来，成为公共服务，我们暂且称为统一权限。引入此服务后，系统需要做一定的调整：

各个产品都改从统一权限服务查询帐号数据，自己不需要再额外存储；
Boss开帐号时只需要等待统一权限的结果回执，帐号开通模型大大简化；

系统模型演化如下：
在这里插入图片描述

这样调整后，带来几个明显的好处：

减少重复工作：不论有多少产品，帐号权限的回调、保存、查询等操作都只需要维护一份；
提升开通速度：Boss只需要把数据下发到统一权限即可认为帐号开通成功，回调链路大大缩短，帐号开通慢的问题也就得到解决。
带动登录业务的优化：依赖帐号校验的登录也可以提取为公共服务，进一步减少了各产品中的重复业务工作量。

3.2 存储优化

看到这里，不知道你心中是否有疑问：为何要额外增加一个统一权限服务，而不直接让Boss来提供帐号查询服务呢？

原因1：前面已经提到的，Boss不愿意与业务系统耦合，阻力大；
原因2：Boss的DB存储不是为了高并发场景服务的，它有很大的历史包袱（具体下面会说明），即使它提供了查询服务，也很有可能达不到优化的目标。

帐号权限的数据内容本身是比较复杂的，它涉及到多块信息：

帐号信息
产品状态
资源信息
开通的产品组件
开通的权限属性
……

传统的关系数据库基本就是把每块信息建一张表，使用时再多表联查出来合并数据。导致的结果就是IO多，查询慢，并且还不好扩展字段。
<多张表的示意>

Boss基本就是类似上面这种拆分存储模式，甚至表比上面更多。估计也正是因为如此，Boss才把帐号下发给各个产品，以免自己成为性能瓶颈点。

这个问题放在10多年前的Boss上可能确实是个问题，但放在如今，却不一定难解。

仔细梳理会发现，上面这些信息不论如何分块，其实本质上都是帐号的一部分，如果把帐号的这些组成部分视作一个整体，其实就是一个带嵌套结构的文档对象。而这类数据的存储最适合面向文档的数据库，例如mongoDB。

它的特点是一个文档就能存下整个对象，特别适合存储结构化的对象。帐号权限用mongoDB存储后的结构示例：

{"_id": {"$oid": "5ef0a57570b03d622f967848"},"userId": 81299529, "userStatus": 82,"status": 62,"contractId": 73522,"productId": 60000,"billingCode": "88130601","resource": {      # 帐号资源信息"siteId": 95729,"siteURL": "20180518test8.quanshi.com/meetnow","hostPassword": "2020194396","guestPassword": "2020194397","password": ""},"accountId": 154772,"siteId": 95729,"components": [    # 产品组件列表{                # 产品组件1"id": 1,……},{                # 产品组件2"id": 2,"name": "summit","activationUrl": "","property": {  # 帐号在产品下的权限信息"AllowGuestMuteOverride": "0","MuteOverride": "2","AllowHostMuteOverride": "0"},"status": 1},{                 # 产品组件3"id": 22,……}],"expiryDate": 0,"gender": 0,"vip": "","conferenceName": "88130601","isFee": 1,"buyMonths": 0,"buyParties": 0
}