共计 3072 个字符，预计需要花费 8 分钟才能阅读完成。
在一个残缺的我的项目中，不仅仅是要实现失常的业务开发。同时为了进步一些开发效率、零碎异样的追踪、零碎性能的扩大等等因素，往往会用到零碎在开发、运行过程中所产生的日志。这就须要咱们有一个欠缺的日志零碎来存储这些数据。本文将分享如何设计一个高可用、可扩大的分布式日志零碎。
- 本文是一种理论性的计划摸索，当然各种计划也是在理论的生产环境中通过实际总结而来的。
- 本文是分布式日志存储系列的实践篇。也有实战篇，将会分享从 0 到 1 的整个过程，从 0 环境的搭建到真正的实际落地。文章会定期的欠缺，最终文章地址。
日志的重要性
在一个零碎中，日志经常在上面的一些场景中占着十分大的作用：
- 我的项目开发阶段的调试、线上服务异样排查。
- 零碎异样的监控。
- 零碎数据分析。
对应日志，次要分为上面三大类型：
日志服务的演进
通过下面几点，大抵明确了一个日志零碎的重要性。接下来，咱们将进一步理解如何设计一个日志零碎。
单节点部署
在我的项目晚期，因为我的项目 用户量小 、 业务数据少 等特点，个别我的项目都会采纳单节点的形式进行部署。此时的日志，个别会以文件的形式存储在对应服务器上。如下图：
当客户端向服务端发送申请，对应的服务器解决业务并将日志记录到日志文件中。这也是传统的日志记录形式，很多的后端框架默认的日志记录形式也如此。如上面 PHP 的 Hyperf 框架，默认将 MySQL 的操作日志记录到日志文件中。
长处
依照这种传统的单节点部署，有什么益处呢？
- 零碎架构繁多、部署简略。不必放心各种服务之间调用问题。
- 技术成本低、易保护。间接应用开发语言的文件操作函数，写人即可。
- 性能高、稳固。不须要调用其余的服务组件，间接调用零碎接口写入磁盘即可。
毛病
- 当日志文件过大时，须要对日志文件做切割，防止写入性能升高。
- 不便于日志排查。对应开发人员来说，能够间接剖析日志内容。如果对于非开发人员来说，对日志存储的就有肯定的要求。
- 存在平安问题。对应服务器个别都有设置权限，须要对服务器用户设置严格的权限。
分布式部署(文件)
这里的分布式部署 (文件) 指的是，零碎服务采纳分布式部署时，日志存储还是采纳文件存储。大抵的逻辑图如下：
长处
- 这样的部署计划有什么益处，和下面提到的单节点部署一样。
毛病
- 在分布式部署中，还是同样的会遇到单节点部署所遇到的问题。
- 不便于零碎排查。当零碎出现异常时，因为是分布式部署，咱们不晓得最终的日志存储在那一台服务器上，就须要挨个服务器的排查。升高了问题排查效率。
分布式部署(日志零碎)
下面提到了分布式系统，应用文件存储日志的几个弊病。因而这里推出应用独立的日志零碎，存储系统日志。大抵逻辑图如下：
- 当客户单发送申请到服务器，服务器解决对应的业务逻辑和记录日志服务。
- 为了进步零碎的响应速度、高可用，在记录日志时，先将日志写入到 MQ 音讯队列中，开启独立的线程将队列中的日志写入到磁盘中。常见的 MQ 音讯队列有，RabbitMQ，RocketMQ，ActiveMQ，ZeroMQ，Kafka，IBM WebSphere 等。能够依据零碎的理论须要抉择适合的 MQ 服务。
- 写入对应的日志零碎之后，能够独立开发一套零碎，来做日志的显示、查问、删除等操作。
长处
- 解决了分布式部署中采纳文件存储的弊病。
- 进步了零碎的可用性。在写日志时，开发人员只须要将日志写入到对应的 MQ 音讯队列中即可。做长久化间接让独自的线程执行。
- 进步了零碎的扩展性。如果团队中，其余的我的项目须要减少日志性能，咱们不须要独自的减少服务器，间接写入原有的 MQ 音讯队列零碎即可。
毛病
- 零碎部署简单。减少了 MQ 服务，也意味着在项目前期减少了运维老本。
- 对开发人员要求高。须要相熟 MQ 音讯服务技术栈。
- 零碎架构要求高。在项目前期肯定要搭建一个高可用、高扩大的架构，当业务变得越来越简单时以及各种服务之间的调用，影响失常的业务逻辑。
日志零碎
下面针对日志服务做了一个架构演进的总结。接下来，就来具体的探讨如何设计一个高可用、高扩大的日志零碎。
对应日志零碎，我集体如下几个观点：
- 可用性强，不能影响失常业务的执行。日志的作用最大的意义在于咱们排查问题、剖析问题以及解决问题。要保障在这个过程中，即便日志服务不可用的状态下，依然不能影响到失常业务的日志。
- 扩展性强。在设计日志零碎时，不能只针对以后的零碎做设计，还须要思考到前期其余我的项目日志的接入。
针对日志零碎，咱们能够采纳自研的形式，也能够采纳开源零碎部署。在本文总，分享两种较为简单的日志服务零碎。大抵的逻辑图如下：
MongoDB 存储
系统日志最终的落地，必定是磁盘。因而，第一种计划咱们应用 MongoDB 来记录日志。
为什么采纳 MongoDB 作为日志存储服务器呢？
- MongoDB 严格来说是一个非关系型的数据库系统。它反对的数据结构十分涣散，相似 json 格局的 bson 格局，因而能够存储比较复杂的数据类型。如果采纳 MySQL、SQLserver、oracle 这样的具备严格数据结构要求的数据库，在日志统计纬度变动时，对应的数据表构造也会随着变动。
- 查问效率高。MongoDB 最大的特点是它反对的查询语言十分弱小，其语法有点相似于面向对象的查询语言，简直能够实现相似关系数据库单表查问的绝大部分性能，而且还反对对数据建设索引。
- 业务拆分、进步业务数据库性能。如果把日志也存储在 MySQL 中，必然会升高 MySQL 的高并发性能问题。一个零碎中，日志内容必定十分的多，日志的读写抢占了对应的操作必然是会升高业务读写的操作。
应用 MongoDB 作为日志存储服务，大抵的逻辑能够采纳如下构造：
- 业务零碎解决日志，再调用 MQ 音讯服务，先将日志数据存在 MQ 音讯服务中。
- 开启异步线程，将 MQ 服务的音讯同步到 MongoDB 服务中，以达到长久化的目标。
- Web 页面则是用于日志数据的展现。
ELK 存储
ELK 是 Elasticsearch+Logstash +Kibana 这种架构的简写。 这是一种开源日志剖析平台的架构。ELK 是开源的，社区沉闷，用户泛滥，这样的架构也失去宽泛的应用。大抵的逻辑图如下：
ELK 罕用架构
- Elasticsearch + Logstash + Kibana
这是一种最简略的架构。这种架构，通过 logstash 收集日志，Elasticsearch 剖析日志，而后在 Kibana(web 界面)中展现。这种架构尽管是官网介绍里的形式，然而往往在生产中很少应用。 - Elasticsearch + Logstash + filebeat + Kibana
与上一种架构相比，这种架构减少了一个 filebeat 模块。filebeat 是一个轻量的日志收集代理，用来部署在客户端，劣势是耗费非常少的资源(较 logstash)，所以生产中，往往会采取这种架构形式，然而这种架构有一个毛病，当 logstash 呈现故障，会造成日志的失落。 - Elasticsearch + Logstash + filebeat + redis(也能够是其余中间件，比方 kafka（集群化）) + Kibana 这种架构是下面那个架构的欠缺版，通过减少中间件，来防止数据的失落。当 Logstash 呈现故障，日志还是存在中间件中，当 Logstash 再次启动，则会读取中间件中积压的日志。目前我司应用的就是这种架构，我集体也比拟举荐这种形式。
总结
- 对于下面进步的几种计划，在理论过程中，还须要联合本身的我的项目状况，抉择适合的架构，而不是为了谋求技术的复杂度而疏忽了本身的理论状况。
- 对于分布式日志的实践在这里就介绍完结了，接下来的内容将实战演示分布式日志设计方案。感兴趣的能够继续关注。对于文章提到的计划，存在有余的中央，也欢送大家指教。
