零售系统软件架构---设计之权限数据分发

一、概述

用户权限数据在我们系统中分为两类，一类是菜单操作权限，一类是数据权限。分析详见
这里。
用户数据在用户中心维护，相关的菜单权限，数据类也在这个系统中。提供管理员用户添加用户、分配角色、资源划分等操作。
那外围子系统怎么来取得用户相关数据，用以判断用户是否有权访问。（说明，用户认证（登录验证在用户中心完成）后，然后授权登录到指定子系统。目前是基于Cookie实现的简单SSO。）

二、集成方式

不管何种方式的集成，都需要在后续请求中加入验证程序。那后续验证的数据来源应该怎么设计呢？
一种A方式是，建立一个统一的缓存层，用户中心登录后，将用户的相关权限设计维护在缓存中，其他子系统使用缓存接口调用。



另一种B方式是，用户中心提供接口，登录子系统时通过接口调用，将用户权限数据缓存在本地系统中。



比较上述A、B方案：
A B
1、数据一致性 较好 通知同步开销大
（数据更新）

2、系统可用性 很强，缓存down机 只对本子系统产生影响
子系统都不能使用

3、性能 不同子系统访问 分摊访问压力
统一缓存，网络IO

4、退出机制 可直接删除对应缓存数据 需要各子系统删除操作

三、选择

根据 应用场景以及目标的，确定我们选择合适的方案。
根据实际场景，我们的系统是一个企业管理系统，对于角色用户权限的划分，基本上是认为是稳定的，不会经常性的发生变动，同时也不会像一些互联网用户，一些恶意操作，需要踢出用户的需求。
也依据我们系统设计原则与理念，以及平台化建设的目标，系统之间交互都需要采用API方式，而不是采用共享存储（包括共享内存或是DB库）。
我们选择B方案。

目前，我们子系统采用本地缓存这些数据，单后续考虑比如各个子系统集群情况，需要采用各子系统集群的共用缓存服务器。



数据更新，通过MQ异步处理，同一个集群中的每台实例都可消费消息，即保证同一个集群下对同一条消息至少消费一次。