运营中心数据权限三级分类实践

去年一月，我在某头部电商平台的运营中心主导了数据权限三级分类实践——这事儿说起来简单，做起来全是坑。当时团队接到的需求是：把原本混乱的权限体系（比如区域经理能查全国数据、运营专员能改所有商品标签）重构为“总部-区域-门店”三级，同时要兼容旧系统的127个接口，还得保证测试期间业务不停摆。这活儿，光是梳理现有权限点就花了整整两周——光是“商品上下架”这个操作，在旧系统里就有8种不同的权限组合，你说离谱不离谱？

三级分类的核心是“动态权限继承”，这技术我查过，国内用的人不多——总部设置基础规则，区域可以叠加限制，门店只能执行不能修改。举个例子：总部允许“查看所有订单”，区域可以加“仅查看本区域订单”，门店就只能看自己门店的订单。但实际落地时，问题来了：旧系统的接口是硬编码的，权限判断全写在SQL里，改一个接口就得重构整个查询逻辑。我们试过用代理模式拦截SQL，结果发现部分旧接口用了存储过程，代理模式根本拦不住——最后只能硬着头皮，给每个接口单独写权限校验逻辑，127个接口，写了整整三个月。

最崩溃的是测试阶段——我们按三级分类设计了一套测试用例，覆盖了“总部越权”“区域冲突”“门店越界”等200多种场景，结果第一轮测试就炸了：区域经理的权限被门店覆盖了！查日志发现，旧系统的权限缓存是按用户ID存的，三级分类后，区域和门店的权限需要合并，但缓存没更新，导致区域经理登录时，系统只读了门店的权限。这问题，要不是我们测了“跨层级权限继承”这个冷门场景，根本发现不了——后来我们给缓存加了版本号，每次权限变更都强制刷新，才解决了这个问题。

新技术的好处，在这时候就体现出来了——我们用了图数据库来存储权限关系，把用户、角色、权限点画成一张图，查询时直接走图遍历，比传统关系型数据库快3倍。比如查“某个门店员工能否修改商品价格”，旧系统要连查5张表，新系统直接从图里找“员工-门店-区域-总部”的路径，0.2秒出结果。但图数据库也有坑——它的事务支持不如MySQL，我们刚开始用时，并发修改权限会导致数据不一致，后来加了分布式锁，才勉强稳住。

有个细节别人肯定没写过：三级分类后，权限日志变得超级重要——以前权限出问题，查日志就能定位，现在权限是动态继承的，日志得记录“权限来源”。比如门店员工修改了商品标签，日志得记“该权限继承自区域规则A，区域规则A继承自总部规则B”，否则出了问题根本没法追溯。我们为此专门开发了一套权限日志解析工具，能把图结构的权限关系转成树形日志，业务方看了都说“终于能看懂了”。

文章配图，仅供参考

（编辑：汽车网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!