微服務之日志落盤設計

目錄

• 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接口的訪問次數以及響應的平均時間。

轉載：https://www.cnblogs.com/lonelyxmas/p/10286277.html