微服务架构落地：用户服务怎么设计？兼容、扩展、多终端适配实战

承接上文：大宗商品销采运储系统六层分层架构连载

在上一篇连载中，我们搭建好了大宗商品销采运储系统完整的六层分层架构。 架构骨架落地之后，公共服务层里的用户服务，往往是第一个踩坑的模块。

很多团队在初期做用户服务，只简单实现账号、密码、登录功能，当成一个单纯的账号工具。但面向供应链、销采运储这类企业级业务，用户服务远不止登录注册，它是整个系统的身份底座，一旦前期设计缺少扩展性，后续改造代价极高。

一、业务场景特点（大宗商品销采运储）

这套系统用户类型复杂，账号来源不统一：

1. 内部员工：销售、采购、仓储、调度、财务，基于公司组织架构；

2. 外部合作方：上游供应商、下游客户、物流承运商；

3. 接入终端：Web 管理后台、移动端 APP、第三方对接接口；

4. 后续扩展：未来需要对接单点登录、第三方系统账号互通。

如果账号、权限、身份信息混在业务服务中，会出现账号体系混乱、多端登录不一致、租户 / 数据隔离困难等问题。所以独立拆分用户服务，放在公共服务层是合理的选择。

二、用户服务在六层架构中的定位

回顾整体分层：

• 展示层：Web、APP、其他客户端

• 统一网关：鉴权、路由、限流

• 业务服务层：采购、销售、仓储、运输等业务微服务

• 公共服务层：用户服务、接口服务、日志服务、调度服务、报表服务

• 公共中间件层：注册 / 配置中心、MQ、Redis、监控、链路追踪

• 数据层：数据库集群、文件存储

用户服务归属【公共服务层】，职责：统一身份管理、账号维护、角色权限、组织管理、令牌发放。 网关只做鉴权放行，复杂权限判定交给用户服务。

三、用户服务核心模块设计

1. 账号管理模块

• 账号基础信息：账号、姓名、手机号、邮箱、状态（启用 / 禁用 / 锁定）

• 账号类型区分：内部账号、外部商户账号、API 对接账号

• 密码策略：密码复杂度、过期策略、登录失败锁定、密码历史记录

扩展性预留：支持多登录方式（账号密码、短信验证码、单点登录），新增登录方式不改动原有业务代码。

2. 组织与角色模块

• 组织架构：部门、分公司、合作商户组织，支持树形结构

• 角色管理：角色定义、角色绑定资源

• 权限模型：RBAC + 数据维度策略 + 条件表达式，支持复杂业务权限

  • 功能权限：页面、按钮、接口访问控制

  • 数据权限：采购只能看自己单据，仓储只能看所属仓库数据（销采储系统核心）

3. 身份认证与令牌模块

• 登录接口：多终端统一登录入口

• Token 管理：JWT + Redis 黑名单，支持主动登出、过期控制

• 会话管理：多端在线控制、单点踢下线

4. 外部账号兼容模块（扩展性重点）

这是企业供应链系统最容易忽略的点：

• 对接外部合作方账号同步；

• 支持第三方系统单点登录；

• API 应用账号管理，给外部对接系统分配独立应用身份，和人工账号隔离。

5. 用户审计模块

• 登录日志、账号变更日志、权限变更记录

• 与公共日志服务打通，统一日志上报，便于安全审计。

四、权限模型详细优化（支持复杂权限场景）

基础 RBAC 只能解决简单角色绑定资源，大宗商品销采运储业务存在大量动态、组合、多维度数据权限，单纯 RBAC 不足以支撑。 采用模型：RBAC (主体 - 角色 - 资源) + 数据策略策略集 + 条件表达式引擎

4.1 模型组成

1. 主体（Subject）

   ：用户 / 应用账号

2. 角色（Role）

   ：静态角色（采购专员、仓库管理员、财务、供应商账号）；支持多角色叠加，一个用户可同时拥有多个角色，权限取并集。

3. 资源（Resource）

   ：接口、页面、按钮，以及业务数据对象（采购单、销售合同、入库单、运单）

4. 权限策略（Policy）

   ：核心扩展点，支持为【角色 / 用户】绑定多条独立数据策略

   • 策略生效范围：可绑定到角色，也可单独给某个用户单独配置策略（例外权限）

   • 策略维度：组织、仓库、客商、业务品类、单据时间区间、单据状态

   • 条件表达式：支持and/or/()组合条件，例如：

     （仓库 ID IN [A,B 仓]）AND（单据创建时间 >= 本月初）AND（单据状态！= 作废）

5. 决策引擎

   ：接收入参（用户 ID、资源编码、业务上下文参数），输出是否允许访问；

   • 缓存策略结果到 Redis，减少重复计算；

   • 权限判定下沉到用户服务，业务服务只负责传入业务上下文，不写权限规则。

4.2 权限分类

1. 操作权限（功能权限）

   控制页面、按钮、接口能否访问。例如：是否新增采购单、是否导出销售报表。

粒度到 API 资源编码，新增接口只需注册资源，无需修改权限引擎代码。

1. 数据权限（核心复杂部分）

   支持多维度组合过滤，适配销采运储复杂隔离场景：

• 按组织维度：只能查看本部门 / 下属分公司单据

• 按归属维度：只能查看本人创建单据

• 按业务对象维度：只能操作指定仓库、指定供应商、指定品类

• 按单据状态 + 时间：仅可查看本年度已生效合同，不可查看草稿、作废单据

• 支持排除策略：例如某采购主管拥有全部门权限，但排除某涉密大客户单据

实现思路：权限引擎返回过滤条件片段，业务服务结合条件拼装 SQL 过滤，或者在内存做数据过滤。

4.3 权限继承与优先级

• 角色权限：通用基础权限

• 用户独立策略：优先级高于角色策略，用于特殊例外场景

• 支持白名单、黑名单：黑名单直接拦截，优先级最高

4.4 扩展性设计

1. 新增业务维度（如货种、运输线路），不需要修改权限引擎核心代码，只需要新增维度参数和策略配置；

2. 支持策略版本管理，策略变更可审计、可回滚；

3. 支持租户隔离，内部用户、外部供应商两套主体隔离，互不干扰。

五、扩展性兼容设计要点

✅ 1. 账号模型预留扩展字段

不要硬编码字段，基础字段固定，扩展属性用 JSON / 扩展表存储。 新增用户属性（如供应商资质编号、承运商编码），不需要改表结构、不用改动核心登录逻辑。

✅ 2. 权限模型解耦

功能权限、数据权限分开。 业务服务只需要传入「当前用户 ID + 业务上下文参数」，向用户服务查询该用户可访问的数据范围，业务本身不维护权限规则。 后续新增业务模块，不需要修改用户服务核心代码，只需要注册资源和配置对应策略。

✅ 3. 多终端兼容

统一身份模型，Web/APP/ 第三方 API 使用同一套账号体系。 网关区分客户端类型，用户服务只负责身份，终端差异化逻辑放在网关或前端。

✅ 4. 水平扩容能力

用户服务是高频访问服务，设计为无状态服务，可多实例部署。 热点登录会话、权限缓存放入 Redis，减轻数据库压力。

✅ 5. 版本兼容策略

接口版本号管理（/api/v1/user），旧接口保留一段时间，平滑升级。 避免一次性全量切换导致上下游业务服务中断。

六、常见踩坑点

1. ❌ 只用基础 RBAC：只能控制按钮，复杂多维度数据权限无法实现，大量权限逻辑散落在业务服务 SQL 里，难以维护；

2. ❌ 内部用户和外部商户共用一张表，缺少类型隔离，后期数据混乱；

3. ❌ 没有会话黑名单，token 无法主动失效，安全风险；

4. ❌ 缺少扩展字段，新增业务属性就要 DDL 改表，线上发布风险大；

5. ❌ 网关承担全部权限判断：网关太重，复杂数据权限、多条件表达式无法实现。

七、总结

在大宗商品销采运储微服务体系中，用户服务作为公共底座，核心目标不是实现登录，而是统一身份、权限隔离、预留长期扩展能力。 采用「RBAC + 策略引擎 + 条件表达式」的复合权限模型，既能满足简单按钮权限，又能支撑供应链场景下多维度、动态、可例外的复杂数据权限。把账号、组织、权限策略、审计收敛到公共服务层，业务服务只专注销、采、运、储本身业务逻辑，后续接入外部商户、多终端、第三方对接时，系统改动量最小。

下篇预告：基础服务 —— 日志服务架构设计，分布式日志采集、存储与检索落地。