鸡翅Club-03

Aetherial included in 笔记

2026-04-18 1997 words 4 minutes

Contents

本篇要点

RBAC模型详解
GateWay 网关

RBAC模型详解

RBAC，全称Role-Based Access Control，即基于角色的访问控制。非常成熟的安全的模型概念，基于角色帮助我们把授权和用户的访问控制来做结合。由三个核心组件构成：

用户（User）：系统的使用者。
角色（Role）：一组权限的集合，代表用户在系统中的职责或身份。
权限（Permission）：对系统资源（如菜单、按钮、数据）的操作权限。

其核心的思想是将权限分配给角色，而不是直接分配给用户。用户通过被分配角色来获得相应的权限，从而实现灵活的权限管理。举个例子：将"查看用户列表"的权限分配给"普通用户"角色，那么所有被分配了"普通用户"角色的用户都能查看用户列表。

泛生模型

RBAC-0 模型

也就是最基础的RBAC模型，只包含用户、角色、权限三个核心组件。用户与角色、角色与权限之间是多对多的关系。

RBAC-1 模型

在 RBAC-0 基础上增加了角色等级（Hierarchy）。

上级角色（如 Admin） 自动拥有 下级角色（如 User） 的所有权限。
这样可以避免为管理员重复配置基础权限，只需配置其特有的管理权限即可。

RBAC-2 模型

在RBAC-1的基础上，增加了角色互斥、基数约束、先决条件等规则，以满足更复杂的权限管理需求。

角色互斥：某些角色不能同时被分配给同一个用户，例如"财务主管"和"审计员"不能由同一人担任。
基数约束：限制用户可以同时拥有的角色数量，例如一个用户最多只能拥有3个角色。
先决条件：某些角色的分配需要满足特定条件，例如只有在拥有"部门经理"角色的情况下，才能分配"项目负责人"角色。

用户组 VS 角色

用户基数非常庞大时，角色也非常的多，如果说我给每个用户都操作一下角色，就非常的麻烦。我们抽象一层组的概念，把同类的用户，放在一起，直接拥有相同的权限。

相较于直接分配角色，分配用户组是否多此一举呢？显然不是：

核心定位不同

角色 (Role)：解决的是 “做什么” 的问题。它是权限的集合（如：审核员、系统管理员、访客）。
用户组 (User Group)：解决的是 “谁在一起” 的问题。它是用户的集合（如：开发部、财务部）。

管理效率的巨大差异

假设公司有 100 个新入职的“开发人员”，他们需要 3 个共同的角色（如：代码查看者、代码提交者、基础运维）。

没有用户组：需要对这 100 个人，每人点击 3 次，总计 300 次授权操作。如果以后要增加一个新角色，还得再点 100 次。
有用户组：
1. 创建一个“开发部用户组”。
2. 给该组分配那 3 个角色（点 3 次）。
3. 把 100 个用户丢进这个组（通常可以批量导入）。
4. 未来调整：如果开发部需要新权限，只需给“开发部用户组”加一个角色，100 个人瞬间同步获得权限。

职责解耦

角色通常对应岗位/职责。
用户组通常对应组织架构/部门。

在现实中，一个部门（组）往往包含多个岗位（角色）。如果直接给用户分角色，当某个用户从“开发部”调岗到“测试部”时，你需要手动删除旧的所有角色，再手动添加新的所有角色，极易出错。如果使用用户组，只需将其从“开发部组”移动到“测试部组”，权限会自动完成切换。

GateWay 网关

个人理解：网关就是在微服务项目中为了统一后端所有服务的入口而存在的一个中间层。确保暴露给前端的只有一个网关层，前端所有的请求都通过这个网关层，再由网关路由到对应的服务接口。同时，网关可以做微服务项目中的统一鉴权并将相关的认证信息正确的传递到下游。

路由

网关的路由是将某个请求转发到对应的微服务，那么就需要这个请求对应哪个微服务，例如请求 /auth/login 需要转发到 auth-service 服务。

注册服务为网关层需要导入对应的配置

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

并且在配置文件中定义对应的路由关系

spring:
  cloud:
    gateway:
      routes:
        - id: auth # 网关路由ID
          uri: lb://jc-club-auth-dev # 路由的服务名称
          predicates:
            - Path=/auth/** # 路由的请求路径
          filters:
            - StripPrefix=1 # 去除请求路径中的前缀

id 是路由的唯一标识
lb:// 这个前缀告诉网关：“不要把这个字符串当成普通的 HTTP 地址，去服务注册中心找它。”
predicates 是路由的请求路径匹配规则
filters 是路由的过滤规则，StripPrefix=1 表示去除请求路径中的1层前缀，例如请求 /auth/login 会剥离/auth 变成 /login

服务注册与发现

网关知道了对应请求需要转发到对应名称的服务，那么如何知道对应的微服务地址呢？这就需要服务的注册与发现了。

Nacos不仅仅可以作为配置管理，同样也可以作为服务的注册中心，在配置文件中启用了服务注册与发现功能后，微服务启动时会自动向Nacos注册自己的地址，此时网关拿到请求会先根据配置文件中路由的服务名称去Nacos中查询对应的服务地址，然后将直接请求转发到对应的服务。

总之 Nacos 的定位是控制面，负责记录谁在哪；而网关和微服务是数据面，负责真实的业务流量传输

启动服务的注册与发现功能

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

并且在 bootstrap.yml 配置文件中定义相关的名称与地址

spring:
  application:
    name: jc-club-auth-dev # 这里的服务名称需要和网关配置文件中的一致
  profiles:
    active: dev
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        prefix: ${spring.application.name}
        group: DEFAULT_GROUP
        namespace:
        file-extension: yaml
      discovery:
        enabled: true
        server-addr: 127.0.0.1:8848