云开放平台SAAS化设计

账号C

获取应用服务

应用资源模型 定义

一个用户可以有多个账号

用户N#账号N

账号B

账号N

关联操作产生account_role

RBAC通用权限数据模型定义领域

商家B#商超C

应用B

应用A#API-1

用户A#ID标识

用户A#公司-2

商超A#仓库A

应用市场

关联操作产生role_resources

商家A

商超N#仓库B

申请成为租户

应用C#角色A

应用C#权限标识-1

商家N

应用C#API-1

应用A

商家C#仓库C

用户A#地址-N

用户A#地址-3

商家A#商超A

应用A#角色N

应用列表

商家B

授权-2

应用菜单模型 定义

商家#仓店实例

用户A#工作-2

应用N

APP-1

用户中心

仓库B

子集

商家仓店组织架构

4

商超C#仓库C

授权

开发者A#应用A

accredit授权逻辑

用户地址维度

租户平台

租户A#应用B

用户A#地址-2

商家A#商超B#账号B

开发者C

商超N

入驻商家

应用C#菜单标识-1

开发者A

用户A#公司-3

用户N#ID标识

仓库

菜单列表

云平台-权限模块

租户

仓店域

用户A#账号A

商家C#仓库C#账号C

商家N#商超N#账号N

租户B

账号中心

商超A

关联仓库

商超B

租户-云平台-SAAS

关联商超

商超C

用户A#工作-3

3

商家域

用户A#N-3

开发者

注册

商家A#商超A#账号A

应用A#权限标识-1

用户A#公司-1

关联店铺

SAAS化

user-1

开发者应用

用户A#公司-N

应用模块

APP-3

用户公司维度

租户A#应用A

用户A#账号B

开发者B

应用权限标识模型 定义

用户账号实例

租户B#应用A

创建账号映射账号

account-2

本质上可以直接申请成为租户，但一般会有一些条件约束即，申请成为租户需要完成实名认证，同时需要完成用户公司维度的信息认证系统会为其生产一个商户号，用改商户号去创建一个租户，这个也可以直接粗暴的由账号来触发创建

用户工作维度

账号A

用户B#ID标识

云平台-SAAS

account-3

关联操作产生role_premission

user-2

入驻开发者

用户C#ID标识

云平台-用户模块

商家

云平台-账号模块

用户B#账号C

归属

应用A#权限标识-n

仓库C

一般条件

唯一账号序列

发布应用到应用市场

商超B#仓库A

应用角色模型 定义

开发者A#应用B

应用A#菜单标识-1

招聘员工

商家A#商超B

应用A#菜单标识-n

授权-1

account-1

应用A#角色A

应用C

应用A#API-N

用户A#工作-1

1.先有账号，现实世界中的人去注册一个叫A的应用，会得到一个账号（A应用会为其生成一个账号，这个账号下所由的数据都应该关联到这个应用（appid）2.接着要为这个账号分配一些权限（授权），在分配权限之前需要为A应用定义出角色模型和资源模型，这样才可以通过授权给当前账号有哪些角色，因为不同的角色又对应不同的资源（标准RBAC）3.此时以上的场景中是一个应用，当有多个应用时应该怎么办？一个很实际的问题是一个公司有多个应用，难道每个应用都需要去创建一次账号，完成一次授权，完成一次实名认证？那么这对用户是多么的不友好！对一个公司来说系统的数据又是有多么的冗余？还有其他一些场景，比如商业化，我们的服务是否能为其他行业赋能？因此基于以上的这些问题，你是否也有了答案？4.租户的设计理念也因此产生，软件即服务，这里的解决方案是，此时账号可以去申请为租户（基于能力的扩展），即当前账号ID关联了一个租户ID，也可由该账号完成实名认证之后，并且完成了用户公司维度信息的认证并为其生成一个商户号，用这个商户号去产生一个租户（比较严谨和符合客观世界一点），账号和或用户公司和租户是1：1的关系5.最后是通过saas化动作完成租户和应用的关联，一个tenantId对应多个appId（一个租户可对应对多个应用，一个应用是一系列的资源的集合），一个账号在一个应用下（每一个应用有自己可以独立的权限体系，通过appId唯一标识）一个应用在一个租户下，一个租户依托于一个用户。

商超

租户应用列表

用户中心/用户实体通用模型领域

APP-4

租户N

仓库A

开发者平台

用户A#N-1

用户A#N-2

APP-2

仓库N

用户A#工作-N

租户A

用户A#N-N

用户N个维度

用户A#地址-1

开发者C#应用C

商超#仓库实例

租户C

商家C