limp-cloud:微服务日志模块设计

女爷i 2023-07-17 07:27 38阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70][]

## **一、问题概要** ##

微服务场景下，日志模块如何设计？

## 二、问题分析 ##

日志模块设计目前首先想到的如上两种

**方案一**：每个微服务提供者 集成日志模块以及相关的库表(如图上方案一)，这种集成方式以及使用方式区别不大，

但是意味着存在

1.“代码冗余”，需要引入日志相关代码

2.库表冗余，需要微服务库创建一系列相关库表

3.查看不方便，如果查询整个项目日志列表，将会从每个从库获取，相对不是很方便

**方案二**：每个模块集成远程调用日志方法，日志统一管理

可以很好的解决方案方案二的问题，但是由于远程调用，效率会有所影响 （不过可以用缓存、MQ、异步等方式解决）

综合分析，方案二的意向更大些，那就向方案二研究下吧

## 三、用户“行为日志”集成使用 ##

首先日志分为多维度进行讨论，确定方案选型，如上述日志一般指的是用户的行为日志，如登录、重置密码、访问某页面“等低频”操作

这类型日志如如下特点

> 数据量小
> 
> 常规操作比较多，如分页查询、根据条件查询统计
> 
> 很必须！作为用户的行为数据，所以很关键，不可缺失
> 
> 数据不可丢失,用户行为不像其它无关紧要日志可丢失，需要保证数据的完整性

所以整体技术选型采用关系行数据存储

\---------------方案待补充-----

## 四、系统API调用日志 ##

在第三部分讨论了行为相关日志有了方案，那系统API调用、系统运行日志如何处理呢？

### 4.1 此类型日志有如下特点 ###

> 日志量大
> 
> 要求实时统计，效率比较高
> 
> 数据少量丢失，不影响统计
> 
> 日志需要图形化展示
> 
> ...

### 4.2 经过小组讨论,该场景技术选型有如下分类 ###

> **数据库：mongo、Redis**
> 
> **消息队列：kafka**
> 
> **搜索引擎：ES、MQ**
> 
> **日志推送：filebeat（小巧）、flume（**数据量大比较有优势、大数据技术栈、支持分布式**）**
> 
> **部署方式：docker、脚本安装**

### 4.3 数据插入效率对比（未查询相关资料，尚需验证，有问题欢迎纠正） ###

日志写入效率：**本地日志文件.txt 》  MQ》非关系行数据库 MongDB》 搜索引擎（2万/s+）》DB(关系型数据库)  **

### 4.4 采用方案会从选取2个研究方向 ###

**  1）ELK方案（可解决微服务分布式日志）：Elasticsearch、Logstash、Kibana**

其中Elasticsearch是一个基于Lucene、分布式、通过Restful方式进行交互的近实时搜索平台框架

Logstash是ELK的中央数据流引擎，用于从不同目标（文件/数据存储/MQ）收集的不同格式数据，经过过滤后支持输出到不同目的地（文件/MQ/redis/elasticsearch/kafka等）。

Kibana可以将elasticsearch的数据通过友好的页面展示出来，提供实时分析的功能

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70 1][]

上述架构对数据源服务器性能影响较大，因为Logsash是需要安装和运行在需要收集的数据源服务器中，然后将收集到的数据实时进行过滤，过滤环节是很耗时间和资源的，过滤完成后才传输到ES中。下面是优化后的架构图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70 2][]

架构图中添加了Kafka作为缓冲存储作用，运行在数据源的Logstash采集器收集到数据后作为生产者直接传输到Kafka,注意这里省略了过滤动作，这样对数据源服务器影响最小，因为Kafka大家都清楚，它的读写性能是非常高的。另一方面，我们需要独立部署一个专门消费的Logstash，这个Logstash负责过滤，并将过滤好的数据传输到ES，后面依然由Kibana读取ES数据进行展示。

这个架构不但性能好，而且耦合低（补充，整个部署采用docker部署，尽量解决运维学习成本，为了不影响应用效率 es-kibana等组件和应用在不同的服务器）

**2）本地文件.txt->flume(filebeat 备用)->kafka->logstash->es-》其它图形化展示组件**

组件和方案一大体相同，就是在技术栈有个别区分，工作重心更倾向于大数据采集处理方向

日志到本地文件，其余工作都有大数据项目组构建（各种离线处理统计类等工作）

补充：对于统计类型信息，可能会涉及到MySql和Redis存储信息

原则：服务器压力& 存入效率 & 解耦 &展示灵活性 & **部署方便（重点！！！）**

Filebeat介绍：

> Filebeat是轻量级单用途的日志收集工具，用于在没有安装java的服务器上专门收集日志，可以将日志转发到logstash、elasticsearch或redis等场景中进行下一步处理。
> 
>     流程：Filebeat收集日志发送到logstash  ===> logstash收到日志写入redis或者kafka ===> logstash收集redis或者kafka日志写入到elk

ileBeat相关介绍：[https://www.cnblogs.com/yanshicheng/articles/9448006.html][https_www.cnblogs.com_yanshicheng_articles_9448006.html]

## 五、总结 ##

方案待补充状态，预计下周完成更新

# #

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70]: /images/20230528/a5f5967512f341a0896536f5aac82b1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70 1]: /images/20230528/1a9215e33b6c419ba8ee4156b3920aec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p6aHVhbl8x_size_16_color_FFFFFF_t_70 2]: /images/20230528/b972a01f712547799144b3cb63a37770.png
[https_www.cnblogs.com_yanshicheng_articles_9448006.html]: https://www.cnblogs.com/yanshicheng/articles/9448006.html