目錄

• 1、設計目標
• 2、日誌流程
• 3、串聯請求事務
• 3.1 請求ID
• 3.2 處理服務器、服務
• 3.3 處理接口名
• 3.4 日誌的發生時間
• 3.5 接口返回狀態碼
• 4、記錄結構
• 5、RabbitMq隊列
• 6、落盤
• 7、性能優化
• 8、簡單統計
• 引用鏈接

1、設計目標

1. 對各個微服務的訪問進行請求追蹤，註重排查開發、線上問題
2. 消息隊列發送、多服務落盤，事後分析
3. 日誌分析
4. 性能優化

2、日誌流程

3、串聯請求事務

3.1 請求ID

請求id：唯一標識一個Api請求鏈路。

為了分析前端的一條Api請求，需要在Api網關請求時產生一個guid，標識api的請求，並按照調用次序傳遞給微服務，微服務間可以互相調用，因此請求id按照調用次序依次傳遞。

3.2 處理服務器、服務

請求鏈路會穿越不同的服務器以及不同的服務，因此，需要記錄服務器的IP或名稱，服務的名稱，這樣在分析問題時可以快速找到故障點。

3.3 處理接口名

api的入口是唯一接口，但穿越不同節點後，實際執行接口會隨著調用而改變，因此接口名需要被記錄下來。

3.4 日誌的發生時間

可提供時間索引，可按照時間進行分區分表等

3.5 接口返回狀態碼

狀態碼簡單判斷接口是否工作正常，有無錯誤，錯誤描述等

4、記錄結構

5、RabbitMq隊列

6、落盤

日誌落盤采用RabbitMq的拉模式，考慮到日誌的規模，如果采用推模式，很可能導致落盤阻塞，因此這裏采用拉取模式，以落盤介質的流速為限制。
落盤可以采用多個微服務進行拉取，這樣可以保證某個落盤服務故障後，仍然可以繼續落盤。
落盤采用一個線程拉取隊列，並存儲在內存隊列中，三個不同的落庫線程，從內存隊列中拉取並落庫。

 public static void Init()
        {
            _event = new AutoResetEvent(false);
            _queue = new ConcurrentQueue<LogBase>();

            new Thread(SaveLogInfo){IsBackground = true}.Start();
            new Thread(SaveLogStat) { IsBackground = true }.Start();
            new Thread(SaveLogBussiness) { IsBackground = true }.Start();
            new Thread(SaveLogToDb) { IsBackground = true }.Start();
        }     

落庫失敗，可以降級到文件落盤。

7、性能優化

考慮到寫庫的性能限制，可以批量寫庫，使用insert value value批量方式能極大提高落庫速度。

8、簡單統計

可以快速分析api接口的訪問次數以及響應的平均時間。

在此我向大家推薦一個微服務架構學習交流群。交流學習群號：864759589 裏面會分享一些資深架構師錄制的視頻錄像：高並發、高性能、分布式、微服務架構的原理，分布式架構等這些成為架構師必備的知識體系。

引用鏈接

1. 口袋代碼倉庫
2. 在線計算器
3. 本節源碼：github

.net core 微服務之日誌落盤設計