菜单规则剖析优化实例

菜单，作为各个系统功能的直接入口，很大程度影响IT系统的易用性。尤其是对于样功能繁琐的系统，如何做好千人千面，针对性显示用户所需的功能，是一个值得深入分析的问题。

一、菜单规则概览

全量菜单树是如何一步步过滤裁剪的？

菜单的字段中包含过滤条件，最简单的便是不依靠任何外部条件的“是否发布”字段。但随着其他模对块菜单过滤的要求，不断新增个性化的字段。例如根据权限点、账号类型、项目相关属性来过滤。然后在菜单功能灰度发布或框架切换的过程中，持续性存在定制的菜单规则，可选择指定菜单对指定特征的项目。但是过滤得到的菜单并不是最终呈现的菜单。在此基础上，PM可以继续定制项目专属菜单，个人用户又可以在项目专属菜单上定制个人菜单。

image

二、菜单规则存在的问题

为何一个菜单的获取，会经历如此繁琐的过程呢？

1、过滤规则的冗余

让我们先分析一下，上面的过滤条件中，有多少是重复交叉的，又有多少是真正的过滤依据。

权限点过滤中，权限点会根据菜单相关属性来生成不同的权限点。但一套权限点模型异常复杂【这里参考ISDP的权限模型】，而项目属性繁多，我们无法做到对每个项目属性控制。于是乎，往往一套权限模型应用到多种类型的项目，但也能满足大部分的业务控制需求了。

菜单字段过滤中，有相当一部分项目属性的字段被重复利用了。其可以做到对项目类型的精确控制。

至于灰度发布，则直接指定菜单在指定项目下的显示隐藏，最细粒度的控制。

这3套规则下来，控制力度层层细化，虽然最终保证了业务规则的实现，却也成了页面性能的瓶颈。

获取用户权限点，获取项目的各个属性这样的接口，一个逻辑复杂，一个源头复杂。作为外部接口，性能本身也有问题。因此在这套规则下，性能优化十分艰难。

2、个别特殊菜单的过滤规则在所有菜单项内过滤

我们来对比一下菜单项自身字段过滤的方式和灰度发布的方式。前者是仅对单个菜单项生效，后者却是对菜单树进行全身检查。一条灰度发布的规则，由于在应用前并不知道是否涉及某菜单某项目，因此无一例外全部搜一遍。我们的菜单树上百条记录，灰度发布规则也有十来条，交叉对比就是上万次比对。这就是这般控制粒度的IT代价。

然而，这并不全是IT方案的错。灰度发布的规则如若管理得当，记录并不会太多。然而菜单来自各个子产品，大家互不干涉。且对于历史数据，大家都报着只增不减不清理的心态，于是，性能不可避免地持续下降。

3、业务规则的合理性

项目属性字段那么多，每个子产品都希望加个字段方便控制。然而，这些属性字段到底数据项目的基本属性，还是项目运作中的业务字段呢？是否真的需要在菜单层面这么控制？存疑。

从IT层面，这些基本属性往往还来自于不同接口，并不是顺手一加。来一个字段便是多一份性能压力。

此外，后面的项目菜单和个人菜单是否都有必要？

三、整改路径

菜单是否显示，根据前文可以看出，从3个维度来顾虑：1、用户特征（权限点）；2、项目特征（项目属性）；3、菜单特征（灰度发布）。能否精简？

用户特征即权限点，权限点根据项目特征和角色来生成；项目特征由各子产品自定义了，理应由业务行管来梳理规定；灰度发布则是批量配置多个菜单在多个项目项目下的显示隐藏，依旧回到项目维度。

从上面的分析可以看出，归根结底就是项目属性，外加一个角色。且项目属性在各个维度都被重复配置了。那么，我们能否一步到位呢，哪怕放在一个地方也好。

权限点模型牵一发动全身，菜单只是其中给一个应用场景，不便于拿此开刀。那我们能否弃用呢？该接口逻辑复杂，性能较差，但其业务目的，实际还是控制到角色和项目。哪我们能否直接改成某角色可见？这样直接从配置表中获取，性能完全不是问题。

应用于菜单过滤的项目属性，应当是在项目生成之前便被赋予的属性，是可以对项目进行分类打标签的基础数据。对于项目运行中维护的业务属性，即使想与菜单挂钩，也只能放在默认菜单之后的定制之上。

灰度发布在我看来是一个很鸡肋的功能，其本身只是为了运维方便，完全是可以融入到菜单字段上的。一条灰度发布规则往往是n个菜单和m个项目或项目属性的关系。迁移到菜单项配置上，需要做n次配置。但这个操作本身，是可以优化页面交互以提升配置人员效率的。

所以，个人给出最优的整改方案：所有的菜单过滤规则都放在菜单项的字段中，保留角色和项目基本属性即可。权限点弃之不用，灰度发布合并到单个菜单项的配置中。定制的菜单只保留个人裁定定制即可。

具体的实施过程中，弃用权限点需要拉通所有子产品评估，且需要重新对应到指定角色；菜单过滤中的项目属性，对于少量的关联了非基本属性的菜单页面，在其进入时再做限制；灰度发布的数据可通过脚本配置到菜单字段中；

四、总结：

问题描述	影响	建议
过滤规则的过于冗余	控制力度层层细化，虽然最终保证了业务规则的实现，却也成了页面性能的瓶颈	本质是根据角色和项目基本属性过滤菜单，减少重复过滤。
灰度发布规则过多	每条灰度发布规则都会对菜单树进行全身检查，性能负担较重	1、合并灰度发布规则；2、将灰度发布也纳入菜单字段中
业务规则的合理性	控制维度太多，达到的业务效果是否值得消耗掉的性能	日落部分项目维度的字段，日落项目菜单。

（优：可线性减少性能消耗；劣：不同子产品的业务规则会交织在一起。Ps.也可在灰度发布页面做个自动合并功能，把部分运算放在配置完成之后，而不是菜单过滤之时。）

（优：按需过滤，基础维度为菜单 劣：配置时相对麻烦，需要对涉及到的菜单挨个配置）