后台系统设计（下篇：输入）

Feed流产品在我们手机APP中几乎无处不在，常见的Feed流比如微信朋友圈、新浪微博、今日头条等。对Feed流的定义，可以简单理解为只要大拇指不停地往下划手机屏幕，就有一条条的信息不断涌现出来。就像给牲畜喂饲料一样，只要它吃光了就要不断再往里加，故此得名Feed（饲养）。

大多数Feed流产品都包含两种Feed流，一种是基于算法推荐，另一种是基于关注（好友关系）。例如下图中的微博和知乎，顶栏的页卡都包含“关注”和“推荐”这两种。两种Feed流背后用到的技术差别会比较大。本文将重点探索一下“关注”页卡的后台实现方式。

图片来源:知乎

不同于“推荐”页卡那种千人前面算法推荐的方式，通常“关注”页卡所展示的内容先后顺序都有固定的规则，最常见的规则是基于时间线来排序，也就是展示“我关注的人所发的帖子，根据发帖时间从晚到早依次排列”。

Feed流实现方案介绍

读扩散也称为拉模式，这应该是最符合我们直觉的一种实现方式。如下图：

每一个内容发布者都有一个自己的发件箱（“我发布的内容”），每当我们发出一个新帖子，都存入自己的发件箱中。当我们的粉丝来阅读时，系统首先需要拿到粉丝关注的所有人，然后遍历所有发布者的发件箱，取出他们所发布的帖子，然后依据发布时间排序，展示给阅读者。

这种设计，阅读者读一次Feed流，后台会扩散为N次读操作（N等于关注的人数）以及一次聚合操作，因此称为读扩散。每次读Feed流相当于去关注者的收件箱主动拉取帖子，因此也得名拉模式。

这种模式的好处是底层存储简单，没有空间浪费。坏处是每次读操作会非常重，操作非常多。设想一下如果我关注的人数非常多，遍历一遍我所关注的所有人，并且再聚合一下，这个系统开销会非常大，时延上可能达到无法忍受的地步。因此读扩散主要适用系统中阅读者关注的人没那么多，并且刷Feed流并不频繁的场景。

拉模式还有一个比较大的缺点就是分页不方便，我们刷微博或朋友圈，肯定是随着大拇指在屏幕不断划动，内容一页一页的从后台拉取。如果不做其他优化，只采用实时聚合的方式，下滑到比较靠后的页码时会非常麻烦。

据统计，大多数Feed流产品的读写比大概在100:1，也就是说大部分情况都是刷Feed流看别人发的朋友圈和微博，只有很少情况是自己亲自发一条朋友圈或微博给别人看。因此，读扩散那种很重的读逻辑并不适合大多数场景。我们宁愿让发帖的过程复杂一些，也不愿影响用户读Feed流的体验，因此稍微改造一下前面方案就有了写扩散。写扩散也称为推模式，这种模式会对拉模式的一些缺点做改进。如下图：

系统中每个用户除了有发件箱，也会有自己的收件箱。当发布者发表一篇帖子的时候，除了往自己发件箱记录一下之外，还会遍历发布者的所有粉丝，往这些粉丝的收件箱也投放一份相同内容。这样阅读者来读Feed流时，直接从自己的收件箱读取即可。

这种设计，每次发表帖子，都会扩散为M次写操作（M等于自己的粉丝数），因此成为写扩散。每篇帖子都会主动推送到所有粉丝的收件箱，因此也得名推模式。

这种模式可想而知，发一篇帖子，背后会涉及到很多次的写操作。通常为了发帖人的用户体验，当发布的帖子写到自己发件箱时，就可以返回发布成功。后台另外起一个异步任务，不慌不忙地往粉丝收件箱投递帖子即可。写扩散的好处在于通过数据冗余（一篇帖子会被存储M份副本），提升了阅读者的用户体验。通常适当的数据冗余不是什么问题，但是到了微博明星这里，完全行不通。比如目前微博粉丝量Top2的谢娜与何炅，两个人微博粉丝过亿。

设想一下，如果单纯采用推模式，那每次谢娜何炅发一条微博，微博后台都要地震一次。一篇微博导致后台上亿次写操作，这显然是不可行的。另外由于写扩散是异步操作，写的太慢会导致帖子发出去半天，有些粉丝依然没能看见，这种体验也不太好。

通常写扩散适用于好友量不大的情况，据悉微信朋友圈正是写扩散模式。每一名微信用户的好友上限为5000人，也就是说你发一条朋友圈最多也就扩散到5000次写操作，如果异步任务性能好一些，完全没有问题。

读写混合也可以称作推拉结合。这种方式可以兼具读扩散和写扩散的优点。我们首先来总结一下读扩散和写扩散的优缺点：

仔细比较一下读扩散与写扩散的优缺点，不难发现两者的适用场景是互补的。因此在设计后台存储的时候，我们如果能够区分一下场景，在不同场景下选择最适合的方案，并且动态调整策略，就实现了读写混合模式。如下图：

对于那些活跃用户登录刷Feed流时，他直接从自己的收件箱读取帖子即可，保证了活跃用户的体验。当一个非活跃的用户突然登录刷Feed流时，我们一方面需要读他的收件箱，另一方面需要遍历他所关注的大V用户的发件箱提取帖子，并且做一下聚合展示。在展示完后，系统还需要有个任务来判断是否有必要将该用户升级为活跃用户。因为有读扩散的场景存在，因此即使是混合模式，每个阅读者所能关注的人数也要设置上限，例如新浪微博限制每个账号最多可以关注2000人。如果不设上限，设想一下有一位用户把微博所有账号全部关注了，那他打开关注列表会读取到微博全站所有帖子，一旦出现读扩散，系统必然崩溃；即使是写扩散，他的收件箱也无法容纳这么多的微博。

读写混合模式下，系统需要做两个判断。一个是哪些用户属于大V，我们可以将粉丝量作为一个判断指标。另一个是哪些用户属于活跃粉丝，这个判断标准可以是最近一次登录时间等。这两处判断标准就需要在系统发展过程中动态地识别和调整，没有固定公式了。

可以看出读写结合模式综合了两种模式的优点，属于最佳方案。然而他的缺点是系统机制非常复杂，给程序员带来无数烦恼。通常在项目初期，只有一两个开发人员，用户规模也很小的时候，一步到位地采用这种混合模式还是要慎重，容易出bug。当项目规模逐渐发展到新浪微博的水平，有一个大团队专门来做Feed流时，读写混合模式才是必须的。

前文已经叙述了基于时间线的Feed流常见设计方案，但实操起来会比理论要麻烦许多。接下来专门讨论一个困难点——Feed流的分页。不管是读扩散还是写扩散，Feed流本质上是一个动态列表，列表内容会随着时间不断变化。传统的前端分页参数使用page_size和page_num，分表表示每页几条，以及当前是第几页。对于一个动态列表会有如下问题：

在T1时刻读取了第一页，T2时刻有人新发表了“内容11”，在T3时刻如果来拉取第二页，会导致错位出现，“内容6”在第一页和第二页都被返回了。事实上，但凡两页之间出现内容的添加或删除，都会导致错位问题。

为了解决这一问题，通常Feed流的分页入参不会使用page_size和page_num，而是使用last_id来记录上一页最后一条内容的id。前端读取下一页的时候，必须将last_id作为入参，后台直接找到last_id对应数据，再往后偏移page_size条数据，返回给前端，这样就避免了错位问题。如下图：

采用last_id的方案有一个重要条件，就是last_id本身这条数据不可以被硬删除。设想一下上图中T1时刻返回5条数据，last_id为内容6；T2时刻内容6被发布者删除；那么T3时刻再来请求第二页，我们根本找不到last_id对应的数据了，也就无法确认分页偏移量。通常碰到删除的场景，我们采用软删除方式，只是在内容上置一个标志位，表示内容已删除。由于已经删除的内容不应该再返回给前端，因此软删除模式下，找到last_id并往后偏移page_size条，如果其中有被删除的数据会导致获得足够的数据条数给前端。这里一个解决方案是找不够继续再往下找，另一种方案是与前端协商，允许返回条数少于page_size条，page_size只是个建议值。甚至大家约定好了以后，可以不要page_size参数。

实际业务应用

文章最后结合我们自身业务，介绍一下实际业务场景中碰到的一个非常特殊的Feed流设计方案。直享直播是一款直播带货工具，主播可以创建一场未来时刻的直播，到时间后开播卖货，直播结束后，主播的粉丝可以查看直播回放。这样，每个直播场次就有三种状态——预告中（创建一场直播但还未开播）、直播中、回放。作为观众，我可以关注多位主播，这样从粉丝视角来看，也会有个直播场次的Feed流页面。这个Feed流最特殊的地方在于它的Feed流排序规则。

Feed流排序规则：

1.我关注的所有主播，正在直播中的场次排在最前；预告中的场次排中间；回放场次排最后

2.多场次都在直播中的，按开播时间从晚到早排序

3.多场次都在预告中的，按预计开播时间从早到晚排序

4.多场次都在回放的，按直播结束时间从晚到早排序

问题分析

本需求最复杂的点在于Feed流内容融入的“状态”因素，状态的转变会直接导致Feed流顺序不同。为了更清晰解释一下对排序的影响，我们可以用下图详细说明：

图中展示了4个主播的5个直播场次，作为观众，当我在T1时刻打开页面，看到的顺序是场次3在最上方，其余场次均在预告状态，按照预计开播时间从早到晚展示。当我在T2时刻打开页面，场次5在最上方，其余有三场在预告状态排在中间，场次3已经结束了所以排在最后。以此类推，直到所有直播都结束，所有场次最终的状态都会变为回放。

这里需要注意一点，如果我在T1时刻打开第一页，然后盯着页面不动，一直盯到T4时刻再下划到第二页，这时上一页的last_id，即分页偏移量很有可能因为直播状态变化而不知道飞到了什么位置，这会导致严重的错位问题，以及直播状态展示不统一的问题（第一页展示的是T1时刻的直播状态，第二页展示的是T4时刻的直播状态）。

直播系统是个单向关系链，和微博有些类似，每个观众会关注少量主播，每个主播会可能有非常多的关注者。由于有状态变化的存在，写扩散几乎无法实现。因为如果采用写扩散的方式，每次主播创建直播、直播开播、直播结束这三个事件发生时导致的场次状态变化，会扩散为非常多次的写操作，不仅操作复杂，时延上也无法接受。微博之所以可以写扩散，就是因为一篇帖子发出后，这篇帖子就不会再有任何影响排序的状态转变。在我们场景中，“预告中”与“直播中”是两个中间态，而“回放”状态才是所有直播的最终归宿，一旦进入回放，这场直播也就不会再有状态转变。因此“直播中”与“预告中”状态可以采用读扩散方式，“回放”状态采取写扩散方式。

最终的方案如下图所示：

会影响直播状态的三种事件（创建直播、开播、结束直播）全部采用监听队列异步处理。我们为每一位主播维护一个直播中+预告中状态的优先级队列。每当监听到有主播创建直播时，将直播场次加入队列中，得分为开播的时间戳的相反数（负数）。每当监听到有主播开播时，把这场直播在队列中的得分修改为开播时间（正数）。每当监听到有主播结束直播，则异步地将播放信息投递到每个观众的回放队列中。

这里有一个小技巧，前文提到，直播中状态按照开播时间从大到小排序，而预告中状态则按照开播时间从小到大排序，因此如果将预告中状态的得分全部取开播时间相反数，那排序同样就成为了从大到小。这样的转化可以保证直播中与预告中同处于一个队列排序。预告中得分全都为负数，直播中得分全都为正数，最后聚合时可以保证所有直播中全都自然排在预告中前面。

另外前文还提到的另一个问题是T1时刻拉取第一页，T4时刻拉取第二页，导致第一页和第二页直播间状态不统一。解决这个问题的办法是通过快照方式。当观众来拉取第一页Feed流时，我们依据当前时间，将全部直播中和预告中状态的场次建立一份快照，使用一个session_id标识，每次前端分页拉取时，我们直接从快照中读取即可。如果快照中读取完毕，证明该观众的直播中和预告中场次全部读完，剩下的则使用回放队列进行补充。照此一来，我们的Feed流系统，前端分页拉取的参数一共有4个：

每当碰到session_id和last_id为空，则证明用户想要读取第一页，需要重新构建快照。这里还有一个衍生问题，session_id的如何取值？如果不考虑同一个观众在多端登录的情况，其实每一位观众维护一个快照id即可，也就是直接将系统用户id设为session_id；如果考虑多端登录的情况，则session_id中必须包含每个端的信息，以避免多端快照相互影响；如果不心疼内存，也可以每次随机一个字符串作为session_id，并设置一个足够长的过期时间，让快照自然过期。

以上设计，其实系统计算量最大的时刻就是拉取第一页，构建快照的开销。目前的线上数据，对于只关注不到10个主播的观众（这也是大多数场景），拉取第一页的QPS可以达到1.5万。如果将第二页以后的请求也算进来，Feed流的综合QPS可以达到更高水平，支撑目前的用户规模已经绰绰有余。如果我们拉取第一页时只获取到前10条即可直接返回，将构建快照操作改为异步，也许QPS可以更高一些，这可能是后续的优化点。

读扩散、写扩散、读写混合，几乎所有基于时间线和关注关系的Feed流都逃不开这三种基本设计模式。具体到实际业务中，可能会有更复杂的场景，比如本文所说的状态流转影响排序，微博朋友圈场景中也会有广告接入、特别关注、热点话题等可能影响到Feed流排序的因素。这些场景就只能根据业务需求，做相对应的变通了。

转自： https://cloud.tencent.com/developer/article/1744756

在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，

单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的

其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。

本文将对上述提到的场景提出一种基础的解决方案。

【 角色】： 系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“ 角色” 。

【 组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“ 组织部门” 。

【岗位】： 运营助理、运营主管、运营经理、运营总监我们统称为“ 岗位” 。

【 数据权限】： 大区运营和部门运营所能看到的数据范围不同，我们称之为“ 数据权限”。

【 资源权限】： 文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“ 资源权限” 。

有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。

      我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。

     比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

    岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的：   例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。

    这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管， 然后我们为这个岗位预设好 “采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。 这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。

    撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。

    数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

   组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图

组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。

上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。

阿里云

一级菜单展现形式：一级菜单处于收起状态，鼠标移入出现，可能因为导航和内容区域都为浅色，为了减少视觉干扰加黑色遮罩。阿里云页面设计也是最近才更新为浅色，之前导航菜单一直是深色。

二级菜单展现形式：页面处于二级菜单页面的时候，鼠标移入汉堡按钮出现一级菜单，此时可以从二级页面操作切换一级菜单，鼠标点击黑色遮罩部分一级菜单收回

鼠标点击二级目录，跳转新页面此时导航页面只显示三级目录，点击上面的返回按钮可返回到上一级

阿里云购买页面，左侧导航消失，可通过右上角返回控制台，返回上一级页面

京东云

一级和二级导航是可收缩状态，常态处于收缩，三级导航展开，鼠标移入一级导航自动展开，移出自动收起，点击切换三级导航

展开

京东云购买页面跟阿里云一样，导航消失，减少用户操作干扰，可通过左上角返回按钮返回上一级操作

百度云

跟京东云导航类似，区别在于京东云一二级导航可伸缩，百度云可伸缩区域是一级导航，固定二级导航，红框区为一级导航，蓝框区为二级导航

点击二级导航，页面跳转到三级导航，点击左上角返回上一级

QINGYUN

一二级导航固定在左侧为展开样式，点击导航底部收缩按钮导航收起来

三级页面为弹窗或者跳转页面点击左上角面包屑按钮返回上一级

滴滴云

相对于上面更轻量级的面包屑设计来说，还有更轻量级的就是把侧面导航栏，固定到页面顶部，这样做首先页面看起来给人的感觉更轻松，比较适合业务轻量级，系统业务固定，这种设计可能之后的延展性会差一点。

下面是一级导航设计，

二级导航设计浮在卡片中间，类似页签的设计点击切换下面的页面。

点击右上角的创建按钮页面跳转至三级页面，没有返回按钮。同一位置页签点击切换为上一级页面

此类页面看起来简单，实则操作复杂，我个人觉得学习成本比较高。

综上所述：面包屑按钮适合轻量级的企业系统，操作简单，认知减负，页面跳转自然。较复杂的嵌套导航适合重量级的企业系统，可以把庞大的一级二级三级页面区分清楚，让用户在复杂的业务中快速定位找到自己想要的部分，提高用户操作效率。

2、基本设计思路：根据业务逻辑设计产品，用户体验可让位于业务流程；

3、设计理论基础：RBAC，用户—角色—权限的逻辑；

(1)职位=角色组；方便管理，职位发生变更时，方便权限更改；身兼数职时处理方法：a、可合并取权限并集；b、如果身兼数职情况发生频繁，可单独设定一个角色；

（2）权限分类：

         a、功能权限，某角色可登陆及登陆后可看到的导航栏、可看到哪些功能；

         b、数据权限：是否可以增、删、改、查？还是只能浏览？

4、操作方法：

（1）按系统赋予不同角色不同操作权限；如人力系统赋予普通游客部分浏览权限；

（2）角色组权限划分：将同一类用户（同一个职位）在不同系统中勾选对应的权限，比如产品经理在人力系统中为游客角色、在财务系统中为游客角色、在资源调度系统中为局部观察者角色，这样就能使得某一个职位形成一个角色组，不同角色对应不同的权限；

原文链接：http://api.woshipm.com/m/comment/list.html?newsId=1056633

这两天3.8妇女节，各大电商又开始不断推出促销活动，借势营销。电商平台仿佛不愿意放过任一个可以作为营销话题的日子，不断推陈出新。经过10多年的电商经验积累，现在做起活动来游刃有余，丰富多样。

下图是我从淘宝、京东上取的两个活动页面，可以看出页面自定义程度很高，美观大方。另一种叫法叫做店铺装修或页面配置，那么问题来了， 这样一个自定义页面怎么配置？怎样通过系统化的方式实现页面动态配置。

由于页面动态配置的内容较多，所以打算分两篇长文介绍，第一篇先讲页面动态配置的整体产品逻辑，第二篇详细描述各组件的功能，一直到组装之后的解析。

页面动态配置是CMS系统（内容管理系统）的一部分，在电商行业，CMS系统有时会局限用作页面动态配置的功能。有时也叫作“ 装修 ”，店铺装修、页面装修、自定义新页面。平台见到的首页管理和新建活动页面都属于此类范畴。

在PC电商时代，页面的自定义比作盖楼，添加一个楼层，每层可以自定义内容，譬如商品、优惠券、商品排名等。“淘宝旺铺“就是店铺装修发展出来的一门生意，淘宝店家可以选择基础模块的内容，编辑首页或新建页面，动态配置页面。

可以把页面的动态配置比作乐高玩具，每一个组件就像乐高积木，可以用它搭建不同的乐高玩具，就类似组装成不同的动态页面。我将页面的动态配置分为3步：组件→ 位置+内容 → 动态页面，如下图。

2.1 基础组件

组件是动态页面的基础，提供给用户编辑具体展示的信息。有许多类型的组件：图片轮播、ICON、优惠券等，每种组件都可以有多个不同的样式，选择内部展示的内容或者自定义。用的最常见的就是链接，组件显示样式虽然多样，但是点击之后通往的页面选择库却是共通的。例如：新的活动页面、商品详情页、商品聚合页、购物车、客服等等。

基础组件的定义和解析是自定义页面的核心，不同的组件有不同的功能，表示不同类型的内容。每个组件都需要单独设计，定义其规则和样式。 例如ICON、图片轮播就是简单的图片展示，商品排名对应的算法较为复杂，需要实时去取动态排名。

2.2 位置+内容

有了组件之后，用户在设置或者系统在解析的时候，首先要确定组件在自定义页面中的位置。位置可以称为“楼层”，每个页面的各楼层可以定义名称、设置背景、配置内容，目前最主流的交互是拖动组件到相应的位置，设置内容之后实时预览，自定义页面动态可视化。

2.3 动态页面

对于整个动态页面，需要定义生效时间、结束时间、活动页面名称等基础信息。设置之后可生成相应的链接进行预览。

动态页面是由不同的组件内容构成，首先按照各组件位置去解析，然后再去解析组件的内容（样式、图片/商品、背景、链接等）。按照上图的反向流程走，就能解析出对应的自定义页面内容。

首页设置也是相同，类似自定义页面，可动态设置首页内容，动态添加自定义组件。目前绝大部分电商首页都是动态配置，有着丰富的自定义内容。

配置组件有许多种，常见的图片轮播、 商品推荐、商品分类、 宝贝排行、图标（ICON）这几种形式，其实是富文本、 客服、优惠券、满减活动、满赠活动、自定义区域、商品搜索、文字、公告、倒计时、Tab组件（顶部、底部）。

丰富的自定义组件可以实现各式各样的活动页面，前面举例的京东、淘宝活动页都是通过CMS配置实现。

至于不同的组件设计和功能，下篇再详细讲解。

组件之间有些通用的自定义要素:

页面动态配置的整体产品逻辑基本已经介绍完毕，可以了解到，页面动态配置看似复杂，理顺之后发现其实就分为三个步骤，绝大部分的复杂度增加只是基础配置组件的丰富。

虽然CMS系统产品逻辑简单，但是页面要做到较高的自定义配置程度，需要技术框架的高效率和较强的可扩展性。在浏览一个自定义页面时，系统要逐步去解析该页面下的自定义组件内容和要素，运算量很大。

目前绝大部门电商公司的自定义页面仅仅停留在一个初级阶段，限于首页和少数特殊页面的自定义配置，而且自定义程度较低。本文提供了CMS系统的产品设计思路，落到实际项目中，还需要权衡实际需求和自定义配置程度之间的关系。

近年来，信用卡市场一片火热，各家银行都争相发行自己的信用卡，以巩固及发展自己的零售客户，伴随着花呗借呗（支付宝）、白条（京东金融）、微粒贷（腾讯）等互联网消费金融的崛起，消费金融战场已经成一片红海，斗得不可开交。外加近日，不良借贷、青少年裸贷、暴力催收等恶性事件层出不穷，传统借贷洗牌在即，互联网借贷也必将斩断一些玩家的魔爪。

话说回来，互金领域，除现金流很大、有固定资产的客户，各个金融机构互相争抢外，有两部分客群传统传统金融机构一直处理不好，也实现现在互金发掘的方向：

第1个客群之所以是问题，就是因为大部分银行都不会给这部分客户授信，是政策层面的问题，暂无法很好解决；第2个客群其实就是目前银行等互联网机构主要发力的点——引导用户使用循环利息、账单分期、预借现金等能产生高收益的业务。也因此衍生出了一批针对高风险（或不具备贷款资格）的用户进行高利贷的恶性行为。

因此，进行银行端信用卡的设计，高净值用户及高资产用户已经被国有五大行及其他股份制银行瓜分的差不多了，要重新找一部分用户，我们瞄准的是25-35岁之间、二三线城市，对微信、App等移动互联网渠道接触时间尚且不长的年轻用户。这部分用户的特点在于，已经接受过了直接/间接的市场教育，对循环利息、账单分期、预借现金等高收益业务有一定了解，也愿意尝试新鲜事物。在物欲横行的时代，有资金需求，有提前消费的意愿等等。这些都构成了我们对这部分用户的基本画像。

于是，我们基于以上的背景和需求，针对信用卡产品，设计了一套交互任务管理系统。

主要从以下三个方面考虑：

根据以上几点，结合目前用户使用频次较高的微信渠道，我们参考游戏机制，分别对应以上的三个方面设计了一套任务系统，其中主要包含以下三类任务：

这种分类在游戏中是很常见的，并且现在很多电商、社区、O2O应用都已经开始用游戏化的机制，配合会员营销体系，进行用户运营。纯粹从这个玩法来讲，不算新颖。但是，在金融系统中（尤其是银行），简单的操作引出的背后的系统是非常复杂的。在多系统的交互中，新增这样的玩法，难度相对而言高了很多。其中，关于任务之间相互的连接关系、推送顺序以及内容的判断逻辑，现在很多电商进行活动时，都没有做到比较好的规划。而游戏中的任务却已经很成熟，下面，就本系统的设计作为引子，与大家简单的介绍下将游戏化任务设计引入移动互联网营销平台的一点思路：

首先，任务的概念与电商后台中的活动类型很相似，活动类型下面会设置对应的活动。所以这里所谓的“任务”，也可以看做是“活动”；“领取”也即是“参加”，两者概念通用。

针对任何一个任务，我们需要考量的有几个方面：

以上几个字段，主要控制任务主体的核心要素，从字面上来看，意思都比较容易理解。

其中任务内容这块需要重点说下，很多中小型电商都是将任务内容的逻辑直接写在页面中，而没有直接通过系统自动化，这点来看，是本系统较突出的地方。目前，任务内容主要涵盖用户业务状态信息、用户累计交易信息、用户交易流水信息以及特殊信息等。通过几个维度，依次定位到任务完成逻辑：

通过以上5层操作，基本可以定位到用户大部分的任务场景。然后是针对任务本身逻辑的设定：

针对成长任务，我们设计了两种模式，任务链与任务池。

任务链：用户每完成一个任务链任务，会自动为用户领取子任务并推送消息，引导用户完成整个链条

任务池：用户每完成一个任务池任务，会根据给定逻辑推送次级任务及对应消息

显然，任务链的模式更加固定，不够灵活，最终我们采用了任务池的模式。

附上对应创建任务的截图：

该配置页面中牵扯到了很多外部系统及渠道，包括信审系统、催收系统、银联数据卡核心系统、微信渠道、客户端等等，所谓牵一发而动全身。因此仅就该页面的配置项，就足以深入思考。

我们在后续的版本迭代中，分别加入了数据统计分析、用户分类标识建立、卡产品分类、白名单机制、防黄牛机制、防退货机制等等。这些后续我们再单独拉出来谈。

针对创建任务，会引出其他的几个配置页面，包含经验等级管理、客户任务管理、权益管理以及消息发送管理。非本系统核心，对应的配置页面比较繁多，但是相对逻辑不复杂，可玩味的地方不多，就不附图了（有兴趣的可以私我或者留个邮箱）。

欢迎各位一同探讨。

因为要开始涉及数据库操作，每个表的单表操作我们都会创建Controller、Service、Entity、Mapper、MapperXML，我们先来新建数据库表结构，先建立最基础的表结构，后续有需要再完善，毕竟使用了MybatisPlus，改变结构之后只需要在实体类加属性就好了。

用户表：

角色表：

用户角色表：

菜单表：

角色菜单表：

在用户表中插入超管账号：

引入Lombok方便写实体类

新建用户相关类：

修改完善部分登录服务代码：

重启项目调用登录，控制台输出一下内容

LoginForm(username=admin, password=21232f297a57a5a743894a0e4a801fc3)

SysUserEntity(id=1, username=admin, password=admin, salt=123456, name=超级管理员, createTime=2022-01-27T17:14:16, createBy=null, updateTime=2022-01-27T17:14:16, updateBy=null)

SaLog -->: 账号[admin]登录成功

整体登录流程就是这样了，继续完善。先确定密码加密方式：

md5(md5(password)+md5(salt))

在测试类中生成密码存到数据库中

登录接口中密码已经在前端经过md5加密，所以修改后端代码

新建菜单Controller

重启登录

OK，接下来从完善菜单管理开始逐步写。

主色调色板 Daybreak Blue / 拂晓蓝

中性色板

色彩应用

更多： https://ant-design.gitee.io/docs/spec/colors-cn

何时使用

通过「小号间距」（8px）、「中号间距」（16px）、「大号间距」（24px）三种规格来划分信息层次

在这三种规格不适用的情况下，可以通过加减「基础间距」的倍数，或者增加元素（e.g. 分割线）来拉开信息层次。

—————————————————————————————————————————————

1）次按钮

常规按钮，用于非主要动作。如果 不确定选择哪种按钮，次按钮永远是最安全 的选择。

2） 主按钮

突出“完成”、“推荐”类操作； 一个按钮区最多使用一个主按钮 。

3） 文字按钮

弱化的按钮，采用更轻量的按钮样式，可用于需 大面积展示按钮场景，例如表格组件中的操作列 。

4）图标按钮

图标提供视觉线索，避免逐字阅读按钮文案，更高效地使用界面。

5）在按钮中添加图标

用于对按钮含义补充解释，提高按钮识别效率。

6 ）特殊按钮

虚线按钮、危险按钮、幽灵按钮等

将按钮区放置于用户浏览路径中，便于被用户发现，如 “F 浏览模式” 和 “Z 浏览模式” 。

什么时候需要在 Footer 中放置按钮区？（为了要和 Body 区区分开来）

按钮顺序

推荐操作是阅读的起点，折叠内容始终在最右侧。

按钮分组

布局相关：

验证导航系统 的设计好坏可对其进行压力测试：像跳伞一样跳进网站里，验证导航系统的极限。

1）忽略首页，随机直达网站某一页面；

2）看用户是否能知道当前位置以及与网站其他部分的关系。在哪个网站的哪个部分？上层网页是什么？

3）是否知道这个网页会带你到哪里去？链接文字是否能说明去向?

基础布局

页级的批量操作影响整个页面，可布置于页底。

选择模版

区隔方式

根据各个信息之间的相关性，判断各个信息模块之间的亲密度，通常情况下，相关性强的内容尽量靠近，相关性弱的的内容尽量拉开层次。

简单总结一下最主要思路和中心思想

1、首选light模式，特定情况（需要沉浸式/暗光）下选择dark暗黑模式

2、导航 按需，目的是帮助用户了解网站可用功能、当前位置、关系、去向

3、给内容区域最大的空间

4、根据内容选用合适模版、组件

5、注意布局与间距

6、注意排序、对齐、按钮、文案等

企业网站管理后台设计有一个重要的原则：不需要有多么强大的功能，但是一定要有简洁方便的操作界面，方便企业录入产品或者资讯以及对于后期功能模块的添加等，这样运营维护起来大大降低了成本。

关于功能模块有很多，例如新闻发布系统，产品管理系统，会员管理系统，图片管理系统，友情链接管理系统，在线商品支付系统等。此外，营销型网站有专门的客服管理系统等。这些模块存在的价值就是能够让企业自行维护网站的内容，不需要网站的维护人员懂得专业的建站知识就能懂得网站页面的更新操作，调整、编辑、上传具体内容。