分布式日志存储架构设计方案

在一个完整的项目中,不仅仅是要完成正常的业务开发。同时为了提高一些开发效率、系统异常的追踪、系统功能的扩展等等因素,往往会用到系统在开发、运行过程中所产生的日志。这就需要我们有一个完善的日志系统来存储这些数据。本文将分享如何设计一个高可用、可扩展的分布式日志系统。

  1. 本文是一种理论性的方案探索,当然各种方案也是在实际的生产环境中经过实践总结而来的。
  2. 本文是分布式日志存储系列的理论篇。也有实战篇,将会分享从0到1的整个过程,从0环境的搭建到真正的实践落地。文章会定期的完善,最终文章地址

日志的重要性

在一个系统中,日志常常在下面的一些场景中占着非常大的作用:

  1. 项目开发阶段的调试、线上服务异常排查。
  2. 系统异常的监控。
  3. 系统数据分析。

对应日志,主要分为下面三大类型:
Snipaste_2022-05-05_16-33-09

日志服务的演进

通过上面几点,大致明白了一个日志系统的重要性。接下来,我们将进一步了解如何设计一个日志系统。

单节点部署

在项目早期,由于项目用户量小业务数据少等特点,一般项目都会采用单节点的方式进行部署。此时的日志,一般会以文件的方式存储在对应服务器上。如下图:

Snipaste_2022-05-05_16-37-38

当客户端向服务端发送请求,对应的服务器处理业务并将日志记录到日志文件中。这也是传统的日志记录方式,很多的后端框架默认的日志记录方式也如此。如下面PHP的Hyperf框架,默认将MySQL的操作日志记录到日志文件中。
Snipaste_2022-05-05_16-43-08

优点

按照这种传统的单节点部署,有什么好处呢?

  1. 系统架构单一、部署简单。不用担心各种服务之间调用问题。
  2. 技术成本低、易维护。直接使用开发语言的文件操作函数,写人即可。
  3. 性能高、稳定。不需要调用其他的服务组件,直接调用系统接口写入磁盘即可。
缺点
  1. 当日志文件过大时,需要对日志文件做切割,避免写入性能降低。
  2. 不便于日志排查。对应开发人员来说,可以直接分析日志内容。如果对于非开发人员来说,对日志存储的就有一定的要求。
  3. 存在安全问题。对应服务器一般都有设置权限,需要对服务器用户设置严格的权限。

分布式部署(文件)

这里的分布式部署(文件)指的是,系统服务采用分布式部署时,日志存储还是采用文件存储。大致的逻辑图如下:
Snipaste_2022-05-05_20-46-13

优点
  1. 这样的部署方案有什么好处,和上面提到的单节点部署一样。
缺点
  1. 在分布式部署中,还是同样的会遇到单节点部署所遇到的问题。
  2. 不便于系统排查。当系统出现异常时,由于是分布式部署,我们不知道最终的日志存储在那一台服务器上,就需要挨个服务器的排查。降低了问题排查效率。

分布式部署(日志系统)

上面提到了分布式系统,使用文件存储日志的几个弊端。因此这里推出使用独立的日志系统,存储系统日志。大致逻辑图如下:
Snipaste_2022-05-05_17-07-04

  1. 当客户单发送请求到服务器,服务器处理对应的业务逻辑和记录日志服务。
  2. 为了提高系统的响应速度、高可用,在记录日志时,先将日志写入到MQ消息队列中,开启独立的线程将队列中的日志写入到磁盘中。常见的MQ消息队列有,RabbitMQ,RocketMQ,ActiveMQ,ZeroMQ,Kafka,IBM WebSphere等。可以根据系统的实际需要选择合适的MQ服务。
  3. 写入对应的日志系统之后,可以独立开发一套系统,来做日志的显示、查询、删除等操作。
优点
  1. 解决了分布式部署中采用文件存储的弊端。
  2. 提高了系统的可用性。在写日志时,开发人员只需要将日志写入到对应的MQ消息队列中即可。做持久化直接让单独的线程执行。
  3. 提高了系统的扩展性。如果团队中,其他的项目需要增加日志功能,我们不需要单独的增加服务器,直接写入原有的MQ消息队列系统即可。
缺点
  1. 系统部署复杂。增加了MQ服务,也意味着在项目前期增加了运维成本。
  2. 对开发人员要求高。需要熟悉MQ消息服务技术栈。
  3. 系统架构要求高。在项目前期一定要搭建一个高可用、高扩展的架构,当业务变得越来越复杂时以及各种服务之间的调用,影响正常的业务逻辑。

日志系统

上面针对日志服务做了一个架构演进的总结。接下来,就来具体的探讨如何设计一个高可用、高扩展的日志系统。
对应日志系统,我个人如下几个观点:

  1. 可用性强,不能影响正常业务的执行。日志的作用最大的意义在于我们排查问题、分析问题以及解决问题。要保证在这个过程中,即使日志服务不可用的状态下,仍然不能影响到正常业务的日志。
  2. 扩展性强。在设计日志系统时,不能只针对当前的系统做设计,还需要考虑到后期其他项目日志的接入。

针对日志系统,我们可以采用自研的方式,也可以采用开源系统部署。在本文总,分享两种较为简单的日志服务系统。大致的逻辑图如下:
Snipaste_2022-05-05_17-41-25

MongoDB存储

系统日志最终的落地,肯定是磁盘。因此,第一种方案我们使用MongoDB来记录日志。
为什么采用MongoDB作为日志存储服务器呢?

  1. MongoDB严格来说是一个非关系型的数据库系统。它支持的数据结构非常松散,类似json格式的bson格式,因此可以存储比较复杂的数据类型。如果采用MySQL、SQLserver、oracle这样的具有严格数据结构要求的数据库,在日志统计纬度变化时,对应的数据表结构也会随着变化。
  2. 查询效率高。MongoDB最大的特点是它支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。
  3. 业务拆分、提高业务数据库性能。如果把日志也存储在MySQL中,必然会降低MySQL的高并发性能问题。一个系统中,日志内容肯定非常的多,日志的读写抢占了对应的操作必然是会降低业务读写的操作。

使用MongoDB作为日志存储服务,大致的逻辑可以采用如下结构:
Snipaste_2022-05-05_18-12-21

  1. 业务系统处理日志,再调用MQ消息服务,先将日志数据存在MQ消息服务中。
  2. 开启异步线程,将MQ服务的消息同步到MongoDB服务中,以达到持久化的目的。
  3. Web页面则是用于日志数据的展示。

ELK存储

​ ELK是Elasticsearch+Logstash +Kibana 这种架构的简写。​ 这是一种开源日志分析平台的架构。ELK是开源的,社区活跃,用户众多,这样的架构也得到广泛的使用。大致的逻辑图如下:
Snipaste_2022-05-05_18-35-40

ELK常用架构
  1. Elasticsearch + Logstash + Kibana
    这是一种最简单的架构。这种架构,通过logstash收集日志,Elasticsearch分析日志,然后在Kibana(web界面)中展示。这种架构虽然是官网介绍里的方式,但是往往在生产中很少使用。

  2. Elasticsearch + Logstash + filebeat + Kibana
    与上一种架构相比,这种架构增加了一个filebeat模块。filebeat是一个轻量的日志收集代理,用来部署在客户端,优势是消耗非常少的资源(较logstash), 所以生产中,往往会采取这种架构方式,但是这种架构有一个缺点,当logstash出现故障, 会造成日志的丢失。

  3. Elasticsearch + Logstash + filebeat + redis(也可以是其他中间件,比如kafka(集群化)) + Kibana这种架构是上面那个架构的完善版,通过增加中间件,来避免数据的丢失。当Logstash出现故障,日志还是存在中间件中,当Logstash再次启动,则会读取中间件中积压的日志。目前我司使用的就是这种架构,我个人也比较推荐这种方式。

总结

  1. 对于上面提高的几种方案,在实际过程中,还需要结合自身的项目情况,选择合适的架构,而不是为了追求技术的复杂度而忽略了自身的实际情况。

  2. 关于分布式日志的理论在这里就介绍结束了,接下来的内容将实战演示分布式日志设计方案。感兴趣的可以持续关注。对于文章提到的方案,存在不足的地方,也欢迎大家指教。

  • 1
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 我可以回答这个问题。分布式项目架构设计的流程图通常包括需求分析、系统设计、技术选型、系统实现、测试和部署等环节。在需求分析阶段,需要明确系统的功能需求和性能需求;在系统设计阶段,需要根据需求设计系统的整体架构和模块设计;在技术选型阶段,需要选择合适的技术栈和工具;在系统实现阶段,需要按照设计实现系统的各个模块;在测试阶段,需要对系统进行各种测试,包括单元测试、集成测试、性能测试等;在部署阶段,需要将系统部署到生产环境中。 ### 回答2: 分布式项目架构设计是一个多角度考量的过程,下面是一个大致的流程图: 1. 需求分析:首先要对项目需求进行全面的分析和理解,明确项目的目标、业务流程和功能需求。 2. 技术评估:根据项目需求,评估各种可能的分布式技术和架构方案,确定使用的技术栈和框架。 3. 功能模块划分:将项目功能根据业务逻辑进行模块化拆分,确定不同模块的职责和交互方式。 4. 数据库设计:根据需求分析,设计数据库结构,确定数据存储和访问方式,考虑数据的一致性和性能优化。 5. 通信协议选择:确定不同模块之间的通信方式和协议,例如使用RESTful API或消息队列等。 6. 负载均衡和高可用性设计:考虑分布式系统的负载均衡和故障恢复机制,如通过负载均衡器实现请求分发和高可用性。 7. 安全性设计:保障数据安全和系统的可靠性,通过身份验证、权限控制和数据加密等方式提升系统安全性。 8. 缓存设计:考虑使用缓存技术提升系统性能,如使用Redis等进行数据缓存和预读。 9. 日志记录和监控:设计系统的日志记录和监控机制,对系统进行实时监控和错误排查,确保系统可靠性和快速反应能力。 10. 性能优化:根据需求和实际使用情况,对系统进行性能优化,如通过分布式缓存、数据库读写分离等提升系统性能和扩展性。 11. 部署和测试:将设计好的分布式架构部署到实际环境中,并进行相应的测试和验证,确保系统稳定可用。 12. 维护和扩展:持续对分布式系统进行维护和优化,根据实际需求进行扩展和升级,保持系统的稳定运行和持续发展。 以上是一个较为完整的分布式项目架构设计流程,其中每个环节都需要深入思考和细致计划,以满足项目的需求并保证系统的稳定性和性能。 ### 回答3: 分布式项目架构设计流程图包括以下几个关键步骤: 1.需求分析:明确项目的目标和需求,包括功能、性能、可靠性等方面的要求。与项目利益相关者沟通,理解他们的期望和关注点。 2.系统拓扑设计:确定系统的整体结构,包括前端、后端、数据库等各个组件的划分和交互方式。选择合适的技术栈和框架,确保系统能够满足需求。 3.模块拆分设计:将系统拆分成多个独立的模块,每个模块可独立运行并拥有自己的数据存储和业务逻辑。考虑模块之间的通信和数据共享方式,避免单点故障和性能瓶颈。 4.负载均衡设计:考虑系统的并发访问量和负载情况,设计合适的负载均衡策略,将请求均匀分布到各个模块或节点上,提高系统的稳定性和性能。 5.数据一致性设计:在分布式系统中,数据一致性是一个重要的挑战。设计合理的数据复制和同步机制,确保不同节点之间的数据一致性和可靠性。 6.故障容错设计:考虑系统中可能出现的故障和异常情况,设计相应的容错机制,如备份节点、自动恢复、故障转移等,降低系统的风险和损失。 7.安全性设计:确保分布式系统的安全性,包括数据安全、访问控制、身份认证等方面的设计。采用合适的加密算法和安全协议,防范潜在的安全威胁。 8.性能优化设计:对系统进行性能测试和评估,识别潜在的性能瓶颈并进行优化。使用合适的缓存机制、并发控制策略等,提高系统的性能和响应速度。 9.监控和调优设计设计合理的监控系统,实时监测系统的运行状态和性能指标。根据监控数据进行系统调优,优化资源利用和性能表现。 以上是分布式项目架构设计流程图的主要步骤,每个步骤都需要仔细考虑和权衡各种因素,以确保分布式系统的稳定性、可靠性和性能优化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值