日志对于我们开发人员是非常重要的，当我们的系统会出现异常或者业务出现错误的时候，我们都是利用日志来定位问题，问题定位到之后就可以有针对性的来解决这个问题，下面我们来聊聊日志系统架构的常见设计方案。
1、单体应用下的日志系统设计
在互联网初期的业务系统都是单体架构部署的，所以针对这种架构下的日志一般都是采用文件的形式存储日志，如下所示：
用户在使用系统的过程中，系统中采用log4j或者logback方案来记录日志数据到日志文件中，如果项目中出现问题之后，开发人员可以直接从日志文件中定位系统的问题点。
这种单体方案下的日志架构设计的优势是部署简单、成本低、性能高，但是在当下微服务架构中就不太适用了。
2、微服务架构下的日志系统设计
随着业务的发展，很多公司都是采用微服务架构部署应用，如下图所示的微服务图：
如果微服务架构下我们依然采用文件的形式来保存日志的话，一旦系统出现问题就非常的难定位问题，所以在微服务架构下我们需要一个统一的日志管理系统来帮助我们存储日志和提供页面查询日志功能。
在微服务架构下需要设计一套不仅可以收集日志，而且还提供日志查询功能的日志管理系统，但是这个日志系统一方面不能影响我们正常的业务执行，另一方面还需要具有可扩展性，用于方便后续的其他系统日志接入。目前比较主流的日志架构设计方案有如下几种：
（1）ELK日志架构方案
图片
ELK方式的是目前比较主流的方案，这种方案的一个比较全面、功能比较齐全的日志系统实现方案，实现的原理是通过filebeat采集日志信息并推送到MQ上，MQ将日志信息让logstash消费，logstash通过日志的过滤和转化之后将日志存储到ES中，开发人员通过Kibana查询ES中的日志数据。
（2）采用mongodb实现日志系统的方案
图片
此方案的原理是各个服务中的日志采集后通过异步消息的方式存储到mongodb中，由于mongodb是一个nosql的数据库，它通过json的方式存储日志数据并且支持非常丰富的查询语句，可以帮助我们对日志的数据来进行过滤查询，最后开发人员通过web页面就可以实现对日志的查询功能。
由于mongodb是存储json数据格式，所以它可以存储非常灵活的日志数据结构，并且它也支持分片和复制等功能，mongodb适合大规模的日志数据存储、复杂的查询场景下的日志系统实现方案。
（3）Loki日志系统实现方案
Loki是grafana提供的一个插件，它类似es一样存储了日志信息，通过promtail收集日志数据，然后将日志的数据推送到Loki中存储，最后开发人员通过grafana查询日志数据。
这种方案比较适用于应用系统有部署granfan并且公司只需要一个轻量级的日志收集系统前提下使用。
总结：
市面上比较成熟的方案有ELK、mongodb方案、Loki方案，每种方案都有各自的特点，在搭建日志系统的时候我们可以根据实际的业务需要选择合适的方案。
