软件架构自学笔记-- 畅途亿级业务日志系统演变过程

﹏ヽ暗。殇╰゛Y 2021-10-26 20:44 217阅读 0赞

# 畅途亿级业务日志系统演变过程 #

原文链接：[https://www.infoq.cn/article/xWlmaS0-rdIjUgNrTjGI][https_www.infoq.cn_article_xWlmaS0-rdIjUgNrTjGI]

## 痛点 ##

你是否遇到过如下情况：线上偶尔出现一个问题，但我们并不能快速准确的排查定位该问题！

为了解决这个问题，快速准确的排查定位问题，畅途网建立了一套业务日志系统。

## 畅途业务日志系统模块 ##

畅途业务日志系统模块主要分 4 个模块：

*  日志集中查询
 *  业务编码配置
 *  日志异步记录
 *  日志存储

### 日志集中查询 ###

由于你没有线上环境的权限，所以还需要运维帮你取一些日志。通常情况下，你是无法知道具体执行方法的代码位于集群中的哪台机器上，可能需要一台一台登录进行查询。为了避免这种情况，我们需要把所有日志统一到一个地方，提供统一的查询入口，供相应人员进行查询。

![16636e80ddf08862fed07f7bffbb4608.png][]

> 备注：登录系统，时间范围为当前时间 -3 天 到当前时间 默认仅需要输入搜索条件即可进行搜索查询，如果需要调整时间，选择相应时间即可。

### 业务编码配置 ###

由于每一个业务逻辑不一样，需要处理的数据也不一样，我们定义了一个下面类似的页面，每新加一个业务处理，添加一个业务，需要设置相应位置的字段的内容。

![060b7884d2911f0314debe44cce1e9e0.png][]

> 备注：定义完这个业务编码之后，我们输出的时候会在每个字段前面加上相应的解释，比如 ip 地址：123.145.33.25，而不是一些没有解释的直接输出的内容。

### 日志异步记录 ###

如果记录日志慢，就会影响正常的业务流程，那么这个记录就是失败的！所以记录日志必须要走异步。

这里经历了 3 个大版本的演变，后续慢慢说明！

### 日志存储 ###

对记录的日志进行处理，存储到相应地方，提供接口供统一查询进行调用。

这里也经历了 3 个大版本的演变，后续慢慢说明！

## 那些坑和演变过程 ##

演变的过程，在我看来就是不断挖坑、填坑的过程！

上面提到畅途业务日志系统的 4 个模块分别是：

*  日志集中查询
 *  业务编码配置
 *  日志异步记录
 *  日志存储

其中关于日志异步记录、日志存储经历了一些坑，下面我们分别来谈谈。

### 日志异步记录的坑和演变过程 ###

我们写一个通用工具类，通过在业务代码中间穿插发送日志代码

![c7e07082ee4b03fd900d4cc8ecb025ab.png][]

调用 sendMessage 方法发送日志如下：

复制代码

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td> 
    <div>
      String 
     <span>[] param = { ip, operStatus, result, errorMessage, userId,……等等的一些其他参数 };</span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td>&nbsp;</td> 
   <td> 
    <div> 
     <span><span>MessageLogsTempate.send<span>Message(<span>"123456", <span>param);</span></span></span></span></span> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

sendMessage 内部实现日志异步记录经历了三个过程：

*  走 activemq 记录日志
 *  走 nginx 记录日志
 *  走队列，异线程取队列走 nginx 记录日志

> 备注：记录日志的逻辑不能影响正常业务！！！

记录日志的逻辑不能影响正常业务！！！这个也很容易理解，但是我们以前就经历过这个坑。

大概在 2012-2013 年左右，我们当时讨论选择的框架就是走 mq，那样异步不会影响业务。当时就选择了 activemq。

做法思路就是 sendMessage 往 activemq 里面写数据，另外消费者消费 activemq 里面的数据。

思路也很简单，修改做起来也很简单，一直都挺好，有次业务高峰期，忽然整个系统很慢，最后排查定位发现是写 activemq 阻塞了。（具体原因很多，在这里就不详细说明了 ）。

![de8d7fd67528a1cde1e42ba920e4788b.png][]

使用 activemq 记录日志，出现阻塞，导致影响业务！问题很严重，后来我们就选择了通过走 nginx 记录日志了。

谈谈当时的想法，为什么没有继续选择其他 mq 呢？

*  时间紧迫，nginx 简单，并且用过 nginx 类似功能。
 *  mq 学习成本较大，同时也怕再次遇到类似 activemq 问题 。

由于上面的 2 个原因，最后我们选择了 nginx。

![3e015408e41cf74f0411980260ac3a6f.png][]

就变成了 sendMessage 方法通过调用 http 发送 nginx。

文件名称都是以小时来生成的，不同的情况会有不同的后缀，处理完成之后会修改文件名为 bak。

下面是测试环境类似日志：

![e1f20a65d96b803993e3cf9d225da92f.png][]

有次我们通宵模拟的时候，发现如果 nginx 服务器特别卡顿的时候，会导致类似 activemq 一样的情况，会阻塞。

![74717e59fc613f91bfb6172846258ce8.png][]

所以 sendMessage 方法继续修改：

![5f2dc99ea5ee1f1e5e1511efd4e70aeb.png][]

最终我们的日志发送就变成：

![79a91482c9f98bb5d2a2d164292e10b7.png][]

日志发送完全异步，不管什么情况都不会影响业务！！！

### 日志存储的坑和演变过程 ###

日志存储也同样经历了三个过程：

*  走 DB 存储
 *  走 solrcloud 存储
 *  走 es 集群存储

现在我们讨论后半段，之前不管是走 activemq 还是后面的异步 nginx 过程，开始的时候我们都是把数据存储在 DB 里。2012-2013 年的时候，数据不是特别多，也没发现特别大的问题，虽然搜索不太方便，但是还是可以搜索的（需要输入业务编码 ，相应属性输入值）

![e0f2f8e201eec2d7e6d6a642b042a2ab.png][]

从上图可以发现，搜索不是特别方便，并且各个业务编码之间也不能相互搜索，一次只能搜索一个编码！但是还是可以使用，并且解决了很多问题！随着业务发展，日志越来越多，慢慢的数据入 DB 就跟不上了，就会面临一个问题：有时候一个日志生产了，但需要很久才可以查询的到。所以，我们就开始考虑解决这个问题，将单条插入修改为批量插入，性能提高了 n 倍，勉强做到了：日志产生后，5 分钟内可以处理入 DB。但是还是会有其它问题出现：

*  查询速度越来越慢！
 *  跨业务编码间的搜索诉求越来越大！
 *  模糊搜索很不理想！

针对这些问题，我们进行了专门的调研，SolrCloud 就进入了我们的视线了，solr 具备高级全文搜索能力：由 Lucene ™提供支持，Solr 可实现强大的匹配功能，包括短语、通配符、联接、分组以及任何数据类型 。

通过对 solr 的研究，我们用 solr 替换掉了 db，从而达到了下面的搜索情况：

![16636e80ddf08862fed07f7bffbb4608.png][]

不管搜索体验，还是搜索效率，都提高了很多，引入 SolrCloud 算是质的飞跃！并且还具备高亮，通过关键词、人员相关字段都可以进行匹配搜索到，如下：

![5116213ded073858573597a762f208a0.png][]

选择一条记录点击，出现明细如下：

![5b6a25e3377df4f060daa8abad8371d7.png][]

字段的解释名也会出现在行的左侧（这个就是之前配置的业务编码，不同的业务编码对应的字段是不一样的），后面是对应的值！

如果搜索条件在各个编码里面，如下，并且搜索的条件是红色的:

![6e65f3e516bcac4f88a303cbed62e9e0.png][]

到这里之后，我们如果有什么问题，可以通过搜索这套日志系统，就可以快速准确的排查定位问题。这套系统不仅仅给开发查询问题，在周末、节假日值班的时候，我们的维护也通过可以通过这套系统进行查询，初步定位问题，解决 90% 的问题。剩余的 10% 的问题再到相应开发人员定位解决，提高了处理问题的响应速度，给用户一个好的体验！

本以为到这里很完美了，那里知道又要经历一波折磨人的时刻！

由于引入了 SolrCloud，业务发展迅速，日志量越来越多，1 天 2-3 亿的日志数据，查询速度在 1s 左右可以返回，但是 SolrCloud 忽然变的不稳定。

![3a2da4a093065d44ee920bff061ac206.png][]

很早之前的测试环境

经常出现 SolrCloud OOM，需要重启，每次开发人员、维护人员都在喊:日志查不了！！！每次都需要重启之后补数据，特别节假日，晚上非常麻烦（solrcloud 太复杂当时没有想着看代码解决，曲线解决问题，我们定时 2 小时执行一次 FGC）经过执行 FGC 之后，出现频率问题低很多了，但是偶然还是会出现 OOM。

针对 SolrCloud 的问题很头疼，后来搜索发现 elasticsearch 和 solr 类似，并且互联网很多公司都用的是 es，决定研究下 es，看看是否可以采用！

通过研究 elasticsearch 发现和 solr 基本类似，替代也比较简单，就给替换了。

![6e8076999244d746b5767695a2ba5c92.png][]

目前 elasticsearch 运行时间 2 年多了，并没有像 solr 那样的出现过 oom 等情况，非常稳定，这段期间也对 elasticsearch 进行过一些方面的优化（以后可以和大家分享）！

同一份数据多份去向的处理逻辑修改，由于之前我们的日志数据仅仅是流向到了 elasticsearch 集群，而有些数据特定的业务编码数据可能需要入库，有些需要进行大数据 fsdf，或者 redis 或者 kafka 中供大数据那边分析，所以我们对数据处理进行了修改，支持多种去向，并且做到已经有的处理可以立即配置生效。

![1777fabd19e3c2541729e260653d53b0.png][]

由于日志系统太好用，记录的越来越多，我们发现有些日志没有必要，所以就对日志进行了分级（借鉴 log4j 的日志级别），这样很多一些低级别日志就不进入 elasticsearch 了。

我们日志的去向也可以根据业务编码进行动态的调整，控制去哪个维度，从而做到了灵活。

## 总结 ##

这套畅途业务日志系统经历了很多迭代，集合了很多人的智慧，不仅易用好用，而且可以快速准确的定位问题。希望我们做到的这套日志系统能够对读者有所帮助，我们要的不是屌炸天技术，而是稳定可靠易用，未来这套日志系统可能还会继续进行升级。

转载于:https://www.cnblogs.com/1605-3QYL/p/11047113.html

[https_www.infoq.cn_article_xWlmaS0-rdIjUgNrTjGI]: https://www.infoq.cn/article/xWlmaS0-rdIjUgNrTjGI
[16636e80ddf08862fed07f7bffbb4608.png]: /images/20211026/43a40f29808a4812870c4dac3b381d45.png
[060b7884d2911f0314debe44cce1e9e0.png]: /images/20211026/184c3acf1d454ae683b8e34d59f444de.png
[c7e07082ee4b03fd900d4cc8ecb025ab.png]: /images/20211026/875cf98b91ff4f8b94da75b559c34ece.png
[de8d7fd67528a1cde1e42ba920e4788b.png]: /images/20211026/670c76f1c2a748b9ba0f54f0c9cbb7fb.png
[3e015408e41cf74f0411980260ac3a6f.png]: /images/20211026/1114c40cbd1a431ca9885447c792fe86.png
[e1f20a65d96b803993e3cf9d225da92f.png]: /images/20211026/77beb8731837459ebd1c93b28ab3a3b0.png
[74717e59fc613f91bfb6172846258ce8.png]: /images/20211026/aae2db6a9e4f47e5abeee2889d271fa8.png
[5f2dc99ea5ee1f1e5e1511efd4e70aeb.png]: /images/20211026/7f39d2180e344f7d86012836b39ae98d.png
[79a91482c9f98bb5d2a2d164292e10b7.png]: /images/20211026/fbf1fa5a4afa42958c97311f86cb83a2.png
[e0f2f8e201eec2d7e6d6a642b042a2ab.png]: /images/20211026/1cd08f55ae8045079560227693bb57b7.png
[5116213ded073858573597a762f208a0.png]: /images/20211026/1fd417a6847b4043a48749b70c2dbc92.png
[5b6a25e3377df4f060daa8abad8371d7.png]: /images/20211026/f54fb027ed3443e5a6c729aec54e648a.png
[6e65f3e516bcac4f88a303cbed62e9e0.png]: /images/20211026/44f652987a5243e1bb4e38ff5fc7fd72.png
[3a2da4a093065d44ee920bff061ac206.png]: /images/20211026/73ad2511c58b4113bb2f1250e9aec038.png
[6e8076999244d746b5767695a2ba5c92.png]: /images/20211026/83d463c6c00340ddb1466bff671244cd.png
[1777fabd19e3c2541729e260653d53b0.png]: /images/20211026/e2b524ecdaea4d8985a3373ed6e278eb.png