前段时间从其他团队接过来一个级别很高的项目，就把代码给到手里，相关的其它资料为0，其它调用端还催着超时问题，问题一大堆需要紧急优化！在这就随手记一下优化过程。。。
第一阶段：了解库的内容，要了解的大约有30多个接口，相关业务，服务的日志，ng存储的地方，相关用到的环境，发布的地址等等
第二阶段：边熟悉项目边优化项目
1）.项目入参控制不当，参数传到了DAO层，error日志疯狂打印——将不合理的报错一一排查解决，上线后错误日志瞬间由原来的上G变为几兆。
2）.项目接口无监控，错误无报警，业务日志基本没有——添加接口监控，钉钉报警埋点，拦截器打印入参，AOP监控接口耗时给与接口超时钉钉提示等为定位问题做准备
3）.业务访问高峰期接口耗时总体能达到10秒，真不知原来维护这个项目的人是怎么忍受的——
第一次优化：分析高峰期接口的调用情况，有的接口调用量会成几十倍的增加（在不知道具体调用点和调用业务的情况下还不能确定是否调用方调用合不合理），所有的接口在高峰期耗时都增加，根据这种现象先排查服务器在高峰期的cpu，load等高不高，发现监控服务相关指标并不高，则可以排除是项目服务器的性能并没有问题。由于项目并没有走缓存也基本没有和其它系统交互的地方，则可以初步怀疑数据库那层出现了问题，于是找到DBA去查数据库的问题，发现基本没有慢查询，然而通过数据库监控可以看出高峰期数据库线程数达到最大，qps也达到最大，慢sql量高峰期非常多，则让BDA帮忙给定位高峰期是不是有任务排队等待的情况，果真不假好多任务都在排队等待中，这显然高峰期的请求数据库的次数明显大于数据库的承受能力，当然这种情况一般都是先想办法降低数据库的压力，从数据库的请求量上下手解决。找到请求量剧增的那几个接口，自己去各个端的操作页面一一定位请求接口的地方，果然不出所料有个系统列表页只显示一下状态而已去调他们的后台，他们的后台系统的竟然来一条条列表来请求这个系统，而且调用的这个接口是所有的相关字段都给返回了，高峰期本来访问这个页面的量就很大，这样一条条调不紧给数据库线程增加开销，IO也会很高，于是赶紧提供批量接口只返回一个状态，推送其它端快速改成新接口上线，效果是很明显的请求量一下收了十几倍，高峰期的平均耗时降了三分之二，但是还是没有达到理想状态。
第二次优化：从其它端操作页面可以看出高峰期高频操作的那几个页面很显然有很多调用不合理的地方，为了展示几个字段但是却来并发访问这个系统好几次，但是毕竟跨端项目，改动量要好几个项目还配合于工作量上是不可能快速实现的，只能来看后台接口是否能可以有加缓存的地方，排查后几个调用量大的接口是不太好加缓存的，因为查询条件都是不固定的可选的，调用端也多，有的要求实时性有的不要求这增加了用缓存的难度，最后决定找DBA增加两个从库来分担查询的压力，果不其然高峰期访问数据库耗时长问题解决了，每个数据库服务压力趋于正常了。
4）优化相关功能点，接口偶尔耗时高问题，有个接口在调第三方翻译时接口耗时比较高，因为客户端仅限制调接口超时时间为300ms，但此接口仅调第三方平均耗时就在1s左右，至此每次都超时客户端很难第一次打开报告页——解决方案是将在保存数据的时候触发消息，接收消息去异步翻译存储，查询接口得到解决。
5）.敏感字问题——因有敏感字遭到有用户投诉是很大的一个问题，于是找过滤敏感字项目的负责人要相关接口，但是敏感是过滤这个接口并没有在线上真实用过，无法预知准确率，如果错误率太高根本没有人力去跟这个事情，于是我将线上数据说不导下来，用作测试用户来一遍遍支持这个过滤敏感字项目的人迭代优化接近想要的结果最终上线。
6）.其它小功能的优化，数据源引入方式的修改等等。。。
在今天项目总算能正常运行了，最大的高峰超时问题已解决，各种接口监控，报警，业务重要日志添加上等。。。
