业务中台建设系列（一）：用户中台V1

本系列拙作是个人在公司业务中台建设中的思考，共分为3篇（按中台划分），本篇为第一篇。由于中台尚处于建设中，最终走向还待实践。公司的产品有2B和2C方向，因此在设计时需要同时考虑这两方面。

ps：我所声称的用户中台，可以认为是一个基于微服务的类SAAS的综合身份管理中心，主要给公司平台内的业务系统使用。

问题域

用户中台需要面对哪些问题呢？

把时间线往前拨一下，先看看企业在信息化方面的遇到的问题，然后再看看用户遇到的问题。

企业遇到的问题：

在多年以前，企业的业务系统是由各个部门负责建设，比如大家熟知的OA系统、财务系统、CRM和ERP等系统，这些系统是由某个部门提出然后并负责推向公司使用。

当业务系统慢慢变多的时候就会发现，虽然企业拥有了这么多系统，但是这些系统的数据是不通用的。每个系统都需要把员工和组织录入一遍。

一旦员工变动（变更组织或者辞职、新员工入职），那么所有业务系统都需要全部更新一遍，这无疑增加员工的工作。而且，由于这些系统互不相同，导致职员在上班时需要逐个登录到相关系统，浪费不少时间。

更致命的是，有的员工离职之后，某些系统的操作人员没能及时注销员工账号导致公司数据泄露；某些员工在离职前拷贝公司客户数据导致客户被挖墙脚，这些事情也屡见不鲜。

那么企业遇到的主要问题有（4A）：

• 统一管理员工账号，为新员工创建账号，为离职员工注销账号；
• 统一管理员工权限，避免员工越权接触数据或越权操作等；
• 统一认证，所有系统只需要登录一次；
• 统一审计，记录所有员工的 操作日志。

除了这些企业内部遇到的问题外，还有一些是对外暴露的一些问题：用户在A产品上的账号不能在B 产品上登录，尽管A产品和B产品都属于同一个公司。

那么回到一个用户中台（类似SAAS），不仅要面对上述问题，还需要处理以下问题——组织如何注册。

• 组织如何实名
• 组织如何登录（组织管理员如何登录）
• 员工怎么登录，手机密码、手机短信验证码、第三方登录（微信、QQ、微博等）、账号名称/ID
• 怎么创建、删除、禁用员工账号
• 管理员怎么邀请员工加入到这个虚拟“组织”
• 组织如何分配员工权限（控制访问）

用户遇到的问题：

用户面对的问题与企业是有一些类似，明明用的都是某一个公司的产品，结果却需要用户再次注册；更有甚者web端和移动端不统一，导致用户在web端下的单但是在手机上却看不着。

如果没有统一的用户管理，付出的代价也是非常昂贵的，用户流失是一方面，用户打通的成本是另一方面。比如最近2年阿里推出的88vip，其中一个目的就是为了打通阿里系相关产品的用户体系。

对于用户，重点是以下问题：

• 需要登录么
• 怎么登录，手机密码、手机短信验证码、第三方登录（微信、QQ、微博等）
• 怎么注册，手机号注册、邮箱注册
• 怎么能够注销账号
• 是否需要实名，如何实名

解决方法域

对于问题域中提及的问题，业内其实有很成熟的解决方案，比如4A管理和IAM。

4A管理：集中账号管理（Account）、集中认证管理（Authentication）、集中授权管理（Authorization）和集中审计管理（Audit）

IAM：Identity and Access Management，即身份识别与访问管理

当然类似的公开产品有（非公开的更多）：

• 东软 SaCa IAM
• 国民认证的统一身份认证平台（UAP）
• 其它的就不列举了

无论哪种解决方案，重点要解决的问题是：

• 统一管理账号，创建账号、注销账号、修改密码、找回密码、修改信息等等
• 统一管理权限
• 统一登录
• 统一注册
• 统一认证鉴权

设计思路

在分享设计思路之前先定义一些概念

概念

下面是一些概念（来源于关于SaaS平台中应对多租户模式的设计—权限设计）：

（1）资源

被安全理的对象（Resources页面、菜单、按钮、订单等）。

（2）权限

访问和操作资源的许可（Permit删除、编辑、审批等）。

（3）角色

用户通过业务需求确定一个角色（Role），并按照实际的业务场景，赋予角色对应的权限的过程，角色也可以理解是权限的集合，是众多权限颗粒组成。

（4）用户

系统实际的操作员（User）

（5）操作权限

• 页面权限：即用户登录系统可以看到的页面，由菜单来控制，菜单包括一级菜单或多级菜单。当系统赋予用户对应菜单的权限，那么用户就可以访问对应的菜单页面。
• 操作权限：即页面的功能按钮，包括：查看、新增、修改、删除、审核等。当用户点击按钮时，系统将会校验用户的是否包含次操作权限，如果有，就可以进行下一步操作。
• 数据权限 ：数据权限就是用户在同一页面看到的数据是不同的。比如项目管理员，就能看到当前团队正在进行中的项目，以及项目的进度情况。而团队成员，就只能看到本人具体参与的项目以及项目信息。相对于复杂一项的权限也可以基于组织结构来拓展。

注意：在用户中台中，资源归属于各业务系统，但权限（权限控制）却是属于用户中台！

关于统一管理的说明：

这里面的统一管理是从开发角度或者系统治理角度出发，并非是从使用角度出发。

以权限管理为例，之前每个业务系统需要搭建自己的权限管理，10个系统就需要开发10次 。如果将这些分散在各系统中的权限管理合并到某个系统中，那么只需要开发一次即可。

而这个独立的权限管理系统就可以称之为统一权限管理系统。这个统一的管理系统可以由专人/部门维护，也可以由各个系统来维护。

从使用角度上来看，统一权限就是有专门的人负责给平台所有用户分配权限，比如新来一个研发小张，公司信息部给他创建账号并给他分配各系统的权限。这个信息部就承担了统一管理的角色。

以“用户”为中心

用户中台是以“用户”为中心的，那么可以基于用户的活动来绘制一张“用户地图”，如下图所示。

从图中可以看到，用户属于用户中台，但是他在物业系统中的角色是管理员，在智慧园区系统中的角色是普通员工。这表明着用户在不同的业务系统中承担着不同的角色，换句话说，角色是与系统关联，系统限定了用户的角色。

上图有一个明显的问题，这个用户没有属于任何组织或者只属于一个组织（平台方）。如果仅是一个自用的平台、小团队等等，没有显式的组织是有可能的。但是，有人的地方就会有团队，有团队的地方就会有组织（有人的地方就有江湖）。

而软件系统是人类真实社会的一个写照一个映射，组织自然就应该加上。用户可以属于1个组织也可以属于多个组织，这些组织之间可以是相关联（比如集团公司和子公司），也可以不关联（比如特朗普不仅是总统，还是商人）。用户与组织的关联关系后面再详细介绍。

由于我们的部分业务是对外提供服务（SAAS），用户中台还要考虑多租户需求。各租户的权限控制可能不一样，组织架构也可能不一样，因此需要进一步调整以应对这两种挑战。

这会遇到一个问题，若租户使用多个系统，那么是每个系统都创建组织还是所有系统都使用一个组织？

个人比较大倾向于各个系统使用独立的组织（指组织机构），这样会更灵活一些（有的业务系统不需要组织架构，而有的业务系统需要组织架构来划分各种权限尤其是数据类权限）

此处是分割线……

如果不存在多租户概念，那就没有租户这一层。这种更接近于自用的内部平台，此时用户应当与组织关联（下图未画用户与组织的关联）

如果没有组织（组织架构）这一层，那么还可以简化为：

账号体系

从平台角度上来看，平台的账号分为两类，一类是个人账号，一类是组织账号（组织有政府机构、企业、社会团体等）。个人账号非常常见，全部的C端应用和部分B端应用都是基于个人账号体系的。

关于组织账号其实在一些平台中也是非常常见的，银行有公司账号和个人账号，支付宝和微信也有类似的账户；苹果的开发者账户有个人、企业之分。

在组织账号的实现上其实有两种方式：

• 一种是为组织创建独立的账号（曾经在政府OA系统中设计过）；
• 一种是将个人账号绑定到组织进而通过个人账号来登录。后者在平台中非常常见，比如各类SAAS平台

ps：在授权方面，个人账号和组织账号并无区别。

权限管理

用户中台的权限体系是基于RBAC概念，这个RBAC是基于资源的RBAC而非基于角色的RBAC。

各业务系统的权限是相互独立的，没有依赖关系

业务系统的权限遵从于基于资源的RBAC

数据权限受限于数据规则

权限并集：与 RBAC2 的静态职责分离-角色互斥原则相反，平台采用多角色权限取并集的设计。即在某个业务系统中，用户可以拥有多个角色。此时用户在该业务系统的权限等于各角色权限的并集

为满足以上几点，权限体系中必须有系统标识；数据资源权限中不仅有组织标识，还必须要有部门标识和创建者标识，部门标识和创建者主要是便于区分消费者和生产者。

ps：目前暂未设计用户组和角色组概念

账号体系和权限管理小结

账户体系和权限管理遵循以下原则：

个人账户统一原则：个人账户一次注册，全平台通用，类似于全网通行证和 SSO。

业务权限独立原则：每个子系统的权限体系是独立的，但是由用户中台统一管理维护。『个人账户统一原则』明确了账户体系是统一的，但是对于每个子系统而言，每个账户所能使用的功能和服务，所能查看的数据权限是独立维护的。

组织实体隔离原则：不同的组织实体之间，是相互隔离，独立管理的。每个组织实体可以自行组织自己的组织体系、账户体系和权限体系。不同的组织实体资源权限也是隔离的。

从属关系隔离原则：个体账户与组织实体的从属关系是基于单独的业务系统存在的，『个人账户统一原则』明确的仅是个人账户的全网统一，但组织实体、从属关系并没有统一，并且是隔离的。

比如在 CRM 系统中，张三（用户）从属于 XXXX 公司（组织），但在 OA 系统中，张三（用户）默认是不从属于任何组织的，从属关系受到具体业务系统的影响。

事实上，这个原则是非强制的，具体取决于各自的业务逻辑和业务场景。

如果要简化从属关系的管理，那么可以不遵循此原则，即个体账户与组织实体的从属关系是全平台统一的，与业务系统无关，但这会为降低平台的灵活性和扩展性。灵活性和复杂度之间通常要做一个取舍。

扩展：

在序言中提及到的《平台级SAAS架构的基础-统一身份管理系统》文章中，作者用的是OS-RBAC权限体系，其中O是Orgnization组织，S是Systerm系统。笔者解释这个体系说明权限受组织和系统双重约束。

这一点我是赞同的，权限是依赖于系统，数据依赖于组织。这个在多租户体系中尤为明显，A公司的管理员不能看到B公司的数据，因为A和B是两个不同的组织；同样，A公司的组织架构、权限体系可以和B公司的完全不一样。

考虑公司平台的业务主要集中在自用和第三方开发者接入使用，短期内（半年到一年内）有租户入驻的概率较低。为了降低复杂度，我降低了组织对权限的影响（设计和开发实现上兼顾）。

即在某个业务系统中，所有管理员的功能权限是一样的（数据权限除外，因其受到组织影响）。

用户类型

下图来源于《平台级SAAS架构的基础-统一身份管理系统》，这个里面概况的用户类型非常详细。我将组织用户和行业用户都放在了组织用户概念中，与前文的组织账户对应。

组织类型

《GBT20091-2006组织机构类型》中定义了以下组织类型：

• 国家机关
• 企业
• 事业单位
• 社会团体（含行业协会）
• 其它类型

我们平台对应的2B业务有智慧社区、智慧园区、智慧办公、智慧校园等，2C业务有智能家居、电商等。综合这些业务场景，平台首要考虑：

• 国家机关，园区、社区类需要考虑，尤其是引入政府资金时，可能需要将数据提供给街道办、公安或政法委（综治办2018年被撤销，相关事宜转交到政法委）
• 电商平台，主要考虑到企业类型

服务分解

微服务架构下的服务分解有两种方式：一种是基于业务能力的分解方式，一种是基于DDD领域驱动子域分解。由于我还在学习DDD领域驱动，故先基于业务能力来分解服务。

业务能力

用户中台需要满足下列需求：

从功能角度来看，可以分为以下模块，详见脑图：

• 账户
• 认证
• 组织管理
• 权限管理
• 授权管理
• 鉴权中心
• 系统管理

服务分解

以下是具体的服务

（1）账号类服务

• 账号管理服务
• 注册服务
• 注销服务

（2）权限类服务

• 角色服务
• 权限服务

（3）组织类服务

• 组织管理服务
• 组织机构管理服务

（4）授权类服务

授权服务：绑定/解绑角色权限，绑定/解绑用户角色，绑定/解绑用户和系统，绑定用户和组织机构。

（5）鉴权类服务

• 登录鉴权服务：登录方式配置、登录风控和登录鉴权3个业务能力
• 其它访问鉴权：负责外部应用访问内部服务的鉴权

（6）认证类服务

认证服务：包含个人实名认证、组织实名认证和人证资质审核3个业务能力。

（7）系统类服务

系统管理服务：负责系统的增删改查