在一個(gè)完整的項(xiàng)目中，不僅僅是要完成正常的業(yè)務(wù)開發(fā)。同時(shí)為了提高一些開發(fā)效率、系統(tǒng)異常的追蹤、系統(tǒng)功能的擴(kuò)展等等因素，往往會(huì)用到系統(tǒng)在開發(fā)、運(yùn)行過程中所產(chǎn)生的日志。這就需要我們有一個(gè)完善的日志系統(tǒng)來存儲(chǔ)這些數(shù)據(jù)。本文將分享如何設(shè)計(jì)一個(gè)高可用、可擴(kuò)展的分布式日志系統(tǒng)。

　　本文是一種理論性的方案探索，當(dāng)然各種方案也是在實(shí)際的生產(chǎn)環(huán)境中經(jīng)過實(shí)踐總結(jié)而來的。

　　本文是分布式日志存儲(chǔ)系列的理論篇。也有實(shí)戰(zhàn)篇，將會(huì)分享從0到1的整個(gè)過程，從0環(huán)境的搭建到真正的實(shí)踐落地。文章會(huì)定期的完善，最終文章地址。

　　文章中相應(yīng)的試題，整理在小程序中，點(diǎn)擊獲取。

　　日志的重要性

　　在一個(gè)系統(tǒng)中，日志常常在下面的一些場(chǎng)景中占著非常大的作用：

　　項(xiàng)目開發(fā)階段的調(diào)試、線上服務(wù)異常排查。

　　系統(tǒng)異常的監(jiān)控。

　　系統(tǒng)數(shù)據(jù)分析。

　　對(duì)應(yīng)日志，主要分為下面三大類型：

　　日志服務(wù)的演進(jìn)

　　通過上面幾點(diǎn)，大致明白了一個(gè)日志系統(tǒng)的重要性。接下來，我們將進(jìn)一步了解如何設(shè)計(jì)一個(gè)日志系統(tǒng)。

　　單節(jié)點(diǎn)部署

　　在項(xiàng)目早期，由于項(xiàng)目用戶量小、業(yè)務(wù)數(shù)據(jù)少等特點(diǎn)，一般項(xiàng)目都會(huì)采用單節(jié)點(diǎn)的方式進(jìn)行部署。此時(shí)的日志，一般會(huì)以文件的方式存儲(chǔ)在對(duì)應(yīng)服務(wù)器上。如下圖：

Snipaste_2022-05-05_16-37-38

　　當(dāng)客戶端向服務(wù)端發(fā)送請(qǐng)求，對(duì)應(yīng)的服務(wù)器處理業(yè)務(wù)并將日志記錄到日志文件中。這也是傳統(tǒng)的日志記錄方式，很多的后端框架默認(rèn)的日志記錄方式也如此。如下面PHP的Hyperf框架，默認(rèn)將MySQL的操作日志記錄到日志文件中。

　　優(yōu)點(diǎn)

　　按照這種傳統(tǒng)的單節(jié)點(diǎn)部署，有什么好處呢？

　　系統(tǒng)架構(gòu)單一、部署簡(jiǎn)單。不用擔(dān)心各種服務(wù)之間調(diào)用問題。

　　技術(shù)成本低、易維護(hù)。直接使用開發(fā)語言的文件操作函數(shù)，寫人即可。

　　性能高、穩(wěn)定。不需要調(diào)用其他的服務(wù)組件，直接調(diào)用系統(tǒng)接口寫入磁盤即可。

　　缺點(diǎn)

　　當(dāng)日志文件過大時(shí)，需要對(duì)日志文件做切割，避免寫入性能降低。

　　不便于日志排查。對(duì)應(yīng)開發(fā)人員來說，可以直接分析日志內(nèi)容。如果對(duì)于非開發(fā)人員來說，對(duì)日志存儲(chǔ)的就有一定的要求。

　　存在安全問題。對(duì)應(yīng)服務(wù)器一般都有設(shè)置權(quán)限，需要對(duì)服務(wù)器用戶設(shè)置嚴(yán)格的權(quán)限。

　　分布式部署（文件）

　　這里的分布式部署（文件）指的是，系統(tǒng)服務(wù)采用分布式部署時(shí)，日志存儲(chǔ)還是采用文件存儲(chǔ)。大致的邏輯圖如下：

　　優(yōu)點(diǎn)

　　這樣的部署方案有什么好處，和上面提到的單節(jié)點(diǎn)部署一樣。

　　缺點(diǎn)

　　在分布式部署中，還是同樣的會(huì)遇到單節(jié)點(diǎn)部署所遇到的問題。

　　不便于系統(tǒng)排查。當(dāng)系統(tǒng)出現(xiàn)異常時(shí)，由于是分布式部署，我們不知道最終的日志存儲(chǔ)在那一臺(tái)服務(wù)器上，就需要挨個(gè)服務(wù)器的排查。降低了問題排查效率。

　　分布式部署（日志系統(tǒng)）

　　上面提到了分布式系統(tǒng)，使用文件存儲(chǔ)日志的幾個(gè)弊端。因此這里推出使用獨(dú)立的日志系統(tǒng)，存儲(chǔ)系統(tǒng)日志。大致邏輯圖如下：

　　當(dāng)客戶單發(fā)送請(qǐng)求到服務(wù)器，服務(wù)器處理對(duì)應(yīng)的業(yè)務(wù)邏輯和記錄日志服務(wù)。

　　為了提高系統(tǒng)的響應(yīng)速度、高可用，在記錄日志時(shí)，先將日志寫入到MQ消息隊(duì)列中，開啟獨(dú)立的線程將隊(duì)列中的日志寫入到磁盤中。常見的MQ消息隊(duì)列有，RabbitMQ，RocketMQ，ActiveMQ，ZeroMQ，Kafka，IBM WebSphere等。可以根據(jù)系統(tǒng)的實(shí)際需要選擇合適的MQ服務(wù)。

　　寫入對(duì)應(yīng)的日志系統(tǒng)之后，可以獨(dú)立開發(fā)一套系統(tǒng)，來做日志的顯示、查詢、刪除等操作。

　　優(yōu)點(diǎn)

　　解決了分布式部署中采用文件存儲(chǔ)的弊端。

　　提高了系統(tǒng)的可用性。在寫日志時(shí)，開發(fā)人員只需要將日志寫入到對(duì)應(yīng)的MQ消息隊(duì)列中即可。做持久化直接讓單獨(dú)的線程執(zhí)行。

　　提高了系統(tǒng)的擴(kuò)展性。如果團(tuán)隊(duì)中，其他的項(xiàng)目需要增加日志功能，我們不需要單獨(dú)的增加服務(wù)器，直接寫入原有的MQ消息隊(duì)列系統(tǒng)即可。

　　缺點(diǎn)

　　系統(tǒng)部署復(fù)雜。增加了MQ服務(wù)，也意味著在項(xiàng)目前期增加了運(yùn)維成本。

　　對(duì)開發(fā)人員要求高。需要熟悉MQ消息服務(wù)技術(shù)棧。

　　系統(tǒng)架構(gòu)要求高。在項(xiàng)目前期一定要搭建一個(gè)高可用、高擴(kuò)展的架構(gòu)，當(dāng)業(yè)務(wù)變得越來越復(fù)雜時(shí)以及各種服務(wù)之間的調(diào)用，影響正常的業(yè)務(wù)邏輯。

　　日志系統(tǒng)

　　上面針對(duì)日志服務(wù)做了一個(gè)架構(gòu)演進(jìn)的總結(jié)。接下來，就來具體的探討如何設(shè)計(jì)一個(gè)高可用、高擴(kuò)展的日志系統(tǒng)。對(duì)應(yīng)日志系統(tǒng)，我個(gè)人如下幾個(gè)觀點(diǎn)：

　　可用性強(qiáng)，不能影響正常業(yè)務(wù)的執(zhí)行。日志的作用最大的意義在于我們排查問題、分析問題以及解決問題。要保證在這個(gè)過程中，即使日志服務(wù)不可用的狀態(tài)下，仍然不能影響到正常業(yè)務(wù)的日志。

　　擴(kuò)展性強(qiáng)。在設(shè)計(jì)日志系統(tǒng)時(shí)，不能只針對(duì)當(dāng)前的系統(tǒng)做設(shè)計(jì)，還需要考慮到后期其他項(xiàng)目日志的接入。

　　針對(duì)日志系統(tǒng)，我們可以采用自研的方式，也可以采用開源系統(tǒng)部署。在本文總，分享兩種較為簡(jiǎn)單的日志服務(wù)系統(tǒng)。大致的邏輯圖如下：

　　MongoDB存儲(chǔ)

　　系統(tǒng)日志最終的落地，肯定是磁盤。因此，第一種方案我們使用MongoDB來記錄日志。為什么采用MongoDB作為日志存儲(chǔ)服務(wù)器呢？

　　MongoDB嚴(yán)格來說是一個(gè)非關(guān)系型的數(shù)據(jù)庫系統(tǒng)。它支持的數(shù)據(jù)結(jié)構(gòu)非常松散，類似json格式的bson格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類型。如果采用MySQL、SQLserver、oracle這樣的具有嚴(yán)格數(shù)據(jù)結(jié)構(gòu)要求的數(shù)據(jù)庫，在日志統(tǒng)計(jì)緯度變化時(shí)，對(duì)應(yīng)的數(shù)據(jù)表結(jié)構(gòu)也會(huì)隨著變化。

　　查詢效率高。MongoDB最大的特點(diǎn)是它支持的查詢語言非常強(qiáng)大，其語法有點(diǎn)類似于面向?qū)ο蟮牟樵冋Z言，幾乎可以實(shí)現(xiàn)類似關(guān)系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對(duì)數(shù)據(jù)建立索引。

　　業(yè)務(wù)拆分、提高業(yè)務(wù)數(shù)據(jù)庫性能。如果把日志也存儲(chǔ)在MySQL中，必然會(huì)降低MySQL的高并發(fā)性能問題。一個(gè)系統(tǒng)中，日志內(nèi)容肯定非常的多，日志的讀寫搶占了對(duì)應(yīng)的操作必然是會(huì)降低業(yè)務(wù)讀寫的操作。

　　使用MongoDB作為日志存儲(chǔ)服務(wù)，大致的邏輯可以采用如下結(jié)構(gòu)：

　　業(yè)務(wù)系統(tǒng)處理日志，再調(diào)用MQ消息服務(wù)，先將日志數(shù)據(jù)存在MQ消息服務(wù)中。

　　開啟異步線程，將MQ服務(wù)的消息同步到MongoDB服務(wù)中，以達(dá)到持久化的目的。

　　Web頁面則是用于日志數(shù)據(jù)的展示。

　　ELK存儲(chǔ)

　　ELK是Elasticsearch+Logstash +Kibana 這種架構(gòu)的簡(jiǎn)寫。這是一種開源日志分析平臺(tái)的架構(gòu)。ELK是開源的，社區(qū)活躍，用戶眾多，這樣的架構(gòu)也得到廣泛的使用。大致的邏輯圖如下：

ELK常用架構(gòu)

　　Elasticsearch + Logstash + Kibana 這是一種最簡(jiǎn)單的架構(gòu)。這種架構(gòu)，通過logstash收集日志，Elasticsearch分析日志，然后在Kibana（web界面）中展示。這種架構(gòu)雖然是官網(wǎng)介紹里的方式，但是往往在生產(chǎn)中很少使用。

　　Elasticsearch + Logstash + filebeat + Kibana 與上一種架構(gòu)相比，這種架構(gòu)增加了一個(gè)filebeat模塊。filebeat是一個(gè)輕量的日志收集代理，用來部署在客戶端，優(yōu)勢(shì)是消耗非常少的資源（較logstash）， 所以生產(chǎn)中，往往會(huì)采取這種架構(gòu)方式，但是這種架構(gòu)有一個(gè)缺點(diǎn)，當(dāng)logstash出現(xiàn)故障， 會(huì)造成日志的丟失。

　　Elasticsearch + Logstash + filebeat + redis（也可以是其他中間件，比如kafka（集群化）） + Kibana這種架構(gòu)是上面那個(gè)架構(gòu)的完善版，通過增加中間件，來避免數(shù)據(jù)的丟失。當(dāng)Logstash出現(xiàn)故障，日志還是存在中間件中，當(dāng)Logstash再次啟動(dòng)，則會(huì)讀取中間件中積壓的日志。目前我司使用的就是這種架構(gòu)，我個(gè)人也比較推薦這種方式。

　　總結(jié)

　　對(duì)于上面提高的幾種方案，在實(shí)際過程中，還需要結(jié)合自身的項(xiàng)目情況，選擇合適的架構(gòu)，而不是為了追求技術(shù)的復(fù)雜度而忽略了自身的實(shí)際情況。