一、问题概要
微服务场景下，日志模块如何设计？
二、问题分析
日志模块设计目前首先想到的如上两种
方案一：每个微服务提供者 集成日志模块以及相关的库表(如图上方案一)，这种集成方式以及使用方式区别不大，
但是意味着存在
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的数据通过友好的页面展示出来，提供实时分析的功能
上述架构对数据源服务器性能影响较大，因为Logsash是需要安装和运行在需要收集的数据源服务器中，然后将收集到的数据实时进行过滤，过滤环节是很耗时间和资源的，过滤完成后才传输到ES中。下面是优化后的架构图
架构图中添加了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
五、总结
方案待补充状态，预计下周完成更新
