降本增笑：记一次首页并发白屏优化过程

      一个服务于近300家500强企业的企业培训软件， app应用的首页居然反复出现白屏，请求超时，负载过高，挤占其他业务服务器资源，最终整个程序无响应的现象，更难想象压测 5线程时， tps 仅有 20 ， 诺大的一个公司，居然这么少的处理效率，平时赶上X踏，X耀，X金，X发，X达信等这种动则好几万人的集团公司有在线抽奖，课程学习，以及签到打卡的活动时，问题频出，虽然刚签完协议，协议离职也还有几天，上头又将这个烫手山芋交给我处理，但本着：在其职,谋其位,尽其力,担其责 的原则 ，还是好好的处理此事。

     首页之所以加载慢，来自于大量的流程处理，其中穿插各业务的的特殊流程，涉及到redis，mongo，solr等等，整个链路非常长，举个例子，首页可以配置1个显示方案，方案都有对应的可见人员的范围，这些方案下配置各个业务的功能跳转，功能本身是有权限的，功能也有自己特殊的逻辑，如是否VIP，如可见人员等等，举例如下图（不能说和B站像似，只能说一摸一样），整个首页的内容称之为一套显示方案，这个方案至少由5部分组成，

1.频道页签，2快捷图片，3快捷图标，4内容面板，5底部运营，

其中会涉及到多个频道，多个内容，而频道，内容都会有对应的可见范围，也就是说，即使A 和B 用的是同一套配置方案（若干频道，内容全部相同），但是只要其中某个频道，某个功能的可见范围和权限不同，那么最终 A，B 两人的界面就会不一样，如A多几个模块，B少一些模块，那如果配置方案不相同，那A，B的界面可能完全天差地别，这也是啥叫互联网杀熟， 说白了就是不同的账号，登录同一个app，显示的东西，或者搜索同一个东西，结果不一样（淘宝：你是在说我吗？杀熟我都是老手了）

 

 

 了解完这一套流程，然后去分析内部的实现，如右上图， 白色部分是原逻辑的简易流程图，即使已过滤掉了大量的链路，仍可预见存在诸多问题，存在优化空间，众所周知，优化来源于三大方向：

设计上：不同的产品一年又一年无脑堆功能到首页，各种乱七八糟的特殊要求，并且态度强硬， 流动的研发一茬接着一茬同步实现，嗯，相信后人的智慧

硬件资源：本不富裕的日子肯定不能雪上加霜， 纵然是可怜巴巴的服务器亦如此，坚信只要销售强，再烂的产品都能推销出去

实现上（代码层面，仓储层面）：只能苦一苦研发，代码是他们写的，问题都是他们的，纵然是流水的研发，铁打的bug，后人也得啃下来

    啃一啃，也没什么，

    第一部分，配置内容，以及实体这一块，如果id相同，那么计算的结果便是相同的，可以拆分出来做一个缓存，不用每次遍历配置逐个取数据。

    第二部分，功能的跳转，部分涉及权限，站在研发的角度，完全可以将其剔除，等到重定向跳转后，具体业务自行判断即可，不要在首页做过多的业务性较强的逻辑，如此便可对首页的主流程进行解耦，但是此方案直接被否决，虽然是少数功能会有权限验证，但是用户就是要直接过滤，能显示但是跳转后却提示无权限，会有意见，ok，若如此也不是不行，可以将权限这一块的功能和不需要权限的功能进行拆分，剥离需要摆人员权限的功能，单独判断，在将剩下的大部分功能进行一个缓存处理，就是一块内容拆分两块分别处理.

    第三部分， 根据权限拆分功能会造成一个排序问题，所以在拿到配置数据集合时，初始化一个排序字段sort，后面在组装拿到最终结果之后，再根据sort 字段进行一个排序，保证进入的功能和出去的内容顺序一致，最后再加个分布式事务锁，短时间内也就只能处理成这样， 运行多年且成型的框架没有深耕最好还是慎重调整结构，很可能小毛病重构到 ICU。嗯嗯，相信后人的智慧。(下图：红色部分为优化内容）

      简单的 redis 拆分 +分布式锁 ，简简单单5线程，tps 从20 直接到 120 ，纵使 shit 山代码，简单的优化一下，也能提升不少，如果从设计上一开始就规避这种对策功能，只管实现的要求，tps 处理还能更高， 这么简单的道理为啥不懂？ 无非是快速迭代，快餐思想，功能无脑使劲往上堆，为追求结果只图快，再加上降本增笑，新人无脑复制+粘贴，体验如何，马马虎虎，差强人意就行，即使某天有故障，先临时扩容再说，上面还有ppt大侠，张嘴闭嘴就是系统垃圾，需要重构，如何如何好，一顿画饼，然后一计算成本，哈哈哈，哈哈，还是保持现状，得过且过！    

                 优化后