SaaS系统多租户多应用多用户设计(二)

SaaS系统多租户多应用多用户设计（二）

资源管理

所有服务都是按照RESTful API规范来的，如：

• GET /xxx/{id} 获取某个资源的详细信息
• POST /xxx 新增资源
• PUT /xxx 修改资源等

服务资源模型图

这样的话其实我们服务的资源都是树形结构的，我们可以把所有资源划分为三类：

• 根节点（服务A，服务B）， 每个服务就是一个根节点。
• 资源（资源A，资源B），资源一般用于前端菜单栏鉴权，后端基本用不到。
• 操作（GET /xxx/{id}）, 这个相当于前端的按钮，这个一般都需要前后端同时鉴权。
  对于操作会有一个问题，那就是服务之间的URL会有重复的情况，这样对于统计鉴权就会带来困难，通过分析发现，其实统一鉴权不需要关心具体的URL，只需要关系是否配置了这个资源点，所以我们对资源进行映射：
• 服务A->资源A->GET /xxx/{id} 映射为： 服务A::资源A:detail
• 服务A->资源A->POST /xxx/{id} 映射为： 服务A::资源A:add
• 服务A->资源A->PUT /xxx/{id} 映射为： 服务A::资源A:update

资源表结构

• root_code 根节点代码 serviceA , 冗余字段，为的是扁平化显示资源信息
• code 资源映射码, 本来应该是为 serviceA::资源A:detail ，因为冗余了root_code，所以可以简化为：资源A:detail,通过代码在去转换为serviceA::资源A:detail
• type 分为两类 资源和操作，服务也算做一个资源。
  这样就把restfull api的操作全部映射到数据库里，方便后面的鉴权。