一个服务于近300家500强企业的企业培训软件， app应用的首页居然反复出现白屏，请求超时，负载过高，挤占其他业务服务器资源，最终整个程序无响应的现象，更难想象压测 5线程时， tps 仅有 20 ， 诺大的一个公司，居然这么少的处理效率，平时赶上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，若如此也不是不行，将权限这一块的功能和不需要权限的功能进行拆分，剥离需要摆人员权限的功能，单独判断，再剩下的大部分功能进行一个缓存处理，这样就会造成一个排序问题，所以再组装拿到最终结果之后，再进行一个排序，保证进入的功能和出去的内容顺序一致，最后再加个分布式事务锁，短时间内也就只能处理成这样， 运行多年且成型的框架没有深耕最好还是慎重调整结构，很可能小毛病重构到 ICU。嗯嗯，相信后人的智慧。
简单的 redis 拆分 +分布式锁 ，tps 从20 直接到 120 ，纵使 shit 山代码，简单的优化一下，也能提升不少，如果从设计上一开始就规避这种对策功能，只管实现的要求，tps 处理还能更高， 这么简单的道理为啥不懂？ 无非是快速迭代，快餐思想，为追求结果只图快，体验如何，马马虎虎，差强人意就行，即使某天有故障，先临时扩容再说，上面还有ppt大侠，张嘴闭嘴就是系统垃圾，需要重构，如何如何好，然后一计算成本，哈哈，还是保持现状，得过且过！
优化后 
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
一、SpringCloud SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud/ SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现服务器…
