业务中台建设系列一用户中台

　　本系列拙作是个人在公司业务中台建设中的思考，共分为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：IdentityandAccessManagement，即身份识别与访问管理
　　当然类似的公开产品有（非公开的更多）：
　　东软SaCaIAM
　　国民认证的统一身份认证平台（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架构的基础统一身份管理系统》文章中，作者用的是OSRBAC权限体系，其中O是Orgnization组织，S是Systerm系统。笔者解释这个体系说明权限受组织和系统双重约束。
　　这一点我是赞同的，权限是依赖于系统，数据依赖于组织。这个在多租户体系中尤为明显，A公司的管理员不能看到B公司的数据，因为A和B是两个不同的组织；同样，A公司的组织架构、权限体系可以和B公司的完全不一样。
　　考虑公司平台的业务主要集中在自用和第三方开发者接入使用，短期内（半年到一年内）有租户入驻的概率较低。为了降低复杂度，我降低了组织对权限的影响（设计和开发实现上兼顾）。
　　即在某个业务系统中，所有管理员的功能权限是一样的（数据权限除外，因其受到组织影响）。
　　用户类型
　　下图来源于《平台级SAAS架构的基础统一身份管理系统》，这个里面概况的用户类型非常详细。我将组织用户和行业用户都放在了组织用户概念中，与前文的组织账户对应。
　　组织类型
　　《GBT200912006组织机构类型》中定义了以下组织类型：
　　国家机关
　　企业
　　事业单位
　　社会团体（含行业协会）
　　其它类型
　　我们平台对应的2B业务有智慧社区、智慧园区、智慧办公、智慧校园等，2C业务有智能家居、电商等。综合这些业务场景，平台首要考虑：
　　国家机关，园区、社区类需要考虑，尤其是引入政府资金时，可能需要将数据提供给街道办、公安或政法委（综治办2018年被撤销，相关事宜转交到政法委）
　　电商平台，主要考虑到企业类型
　　服务分解
　　微服务架构下的服务分解有两种方式：一种是基于业务能力的分解方式，一种是基于DDD领域驱动子域分解。由于我还在学习DDD领域驱动，故先基于业务能力来分解服务。
　　业务能力
　　用户中台需要满足下列需求：
　　从功能角度来看，可以分为以下模块，详见脑图：
　　账户
　　认证
　　组织管理
　　权限管理
　　授权管理
　　鉴权中心
　　系统管理
　　服务分解
　　以下是具体的服务
　　（1）账号类服务
　　账号管理服务
　　注册服务
　　注销服务
　　（2）权限类服务
　　角色服务
　　权限服务
　　（3）组织类服务
　　组织管理服务
　　组织机构管理服务
　　（4）授权类服务
　　授权服务：绑定解绑角色权限，绑定解绑用户角色，绑定解绑用户和系统，绑定用户和组织机构。
　　（5）鉴权类服务
　　登录鉴权服务：登录方式配置、登录风控和登录鉴权3个业务能力
　　其它访问鉴权：负责外部应用访问内部服务的鉴权
　　（6）认证类服务
　　认证服务：包含个人实名认证、组织实名认证和人证资质审核3个业务能力。
　　（7）系统类服务
　　系统管理服务：负责系统的增删改查
　　参考链接
　　平台级SAAS架构的基础：统一身份管理系统
　　关于SaaS平台中应对多租户模式的设计权限设计