需求开发引入es，却跌入远古巨坑

注：记录开发，自己总结，随便写写，不喜勿喷。

问题描述

最近开发一个需求，本来很简单，就一个单表查询，最多再加一层缓存，结果组长担心qps太高，数据库压力太大，影响核心业务(这张表挺核心的)。因此在定方案的时候，考虑把这张表的数据迁移到es，然后查询走es，具体方案我就不说了。

开发过程不算顺利，但也完成了，接口对接第三方，因此直接打包上开发环境，准备联调了。部署没啥问题，准备自测下，出现了下面这个问题。最讨厌这种本地没问题，上服务器就报错了。

问题分析

这个问题初看就是类初始化失败，找不到这个类或者jar冲突，我全局搜了下

发现就只有一个这个类，应该没问题才对啊！为啥找不到类？

漫漫爬坑路刚刚开始。

难道是es相关的包没有么？我又去服务器看了下，包也存在，所以为啥初始化不了这个类？搜索了一下午也没找到问题，心情烦闷。吃晚饭的时候跟导师聊了这个问题，他说看能不能在本地复现这个问题，我想要是本地有这个问题我就不会打包上开发环境了，继续讨论，他又说可以考虑重启下或者重新打包，我也只能死马当活马医了。

吃完饭回来重新打包部署上去，然后再调了一次接口，发现这次的报错变了，如图：

这次说找不到LogManager，又调了一次，又变成上面那个初始化失败了，好像有点眉目了，应该是找不到LogManager导致上面的类初始化失败；紧接着我打开了上面那个类。

发现这个类初始化的时候就依赖这个LogManager，这里我就想不通了，我本地咋没问题呢？想了下可能是本地有这个包，但是开发环境没这个包？带着问题我又去开发环境看了下包，果然没有。。。

问题又来了，离了个大谱，jinkens打包还能丢包？带着问题去找运维，果不其然被骂了一顿，jinkens肯定没问题的，那问题在哪里呢？又陷入了僵局，这时候已经快晚上11点了，先打车回了，第二天再看。

回去的路上想了下，会不会是打包的时候某个地方排掉了这个包？第二天到公司就开始找，直接全局搜索log，终于找到问题了，如图：

这里把很多包都排掉了，问题是处于什么原因要排掉这些包呢？依赖里排掉不就好了么？为啥在打包的时候排？做这个的人已经离职了，只能我自己看看了，不搞清楚不敢随便动啊。

百度了一波了解下，改这个是为了统一日志框架slf4j门面+logback实现，依赖里也有相关的桥接包，这些包如果保留的话会导致死循环，不然前人不会这么做的。

问题解决

这里解决的话为了防止其它问题，我就把正则简单改了下，如下图：

至此问题终于解决了，已经是第二天的下午了。