1. 程式人生 > >微服務體系操作日誌如何記錄?

微服務體系操作日誌如何記錄?

提到日誌 ,作為java開發人員,第一反應嚮導的應該都是log4j、logback等技術元件,但是在微服務體系中,系統進行拆分之後,形成多個模組之後,如何用統一的標準進行記錄操作日誌,業界沒有統一的標準,也沒有統一的元件進行記錄,原因主要是各業務系統對操作日誌的定義要求、定義級別不同,例如:

案例1:對使用者操作的所有記錄進行記錄,尤其是增刪改模型實體業務資料;

案例2:對使用者操作的所有記錄記錄進行記錄,尤其是操作時機、操作結果;

針對操作日誌,每個系統或企業經營業務領域不同、負責人知識面不同、以及系統等級不同,要求差異也很大,那如何在服務開發過程中,根據使用者自定義的需求進行統一記錄呢,本文將親身經歷進行講述,廢話不多說,我們開始!

方案一:業務閘道器進行記錄。針對微服務分散式應用,前後端互動、系統之間互動,都是通過業務閘道器進行交易轉發。因此,可以在業務閘道器通過攔截器的方式進行記錄,這種記錄只能記錄操作時間、操作人、操作型別、操作結果、入參、出參等,無法記錄資料實體模型的變化情況。這種方案的各應用無需單獨實現,只需要在業務閘道器進行解析記錄即可,後期改造難度小、影響小;缺點無法記錄資料實體本身記錄,且模組資訊以及操作型別只能通過規範性進行約束。

方案二:在業務實體變更時進行記錄。這種記錄需要在開發時,通過監聽資料實體模型變化進行記錄,這需要在應用開發時就考慮,後期改造難度大,影響大。這種方案優點是可以記錄的很詳細,包括實體模型前後變化情況等,缺點是開發需要完全按照規範進行,並且微服務涉及多資料來源或需要引入訊息佇列概念,複雜度較高。

方案三:在具體操作方法時進行記錄。這種記錄方式可以通過自定義註解的方式進行,在註解中進行標記模組資訊及操作型別,然後通過AOP中解析註解中的引數進行記錄。這種方式優點是日誌記錄模組及操作資訊是通過手工設定,針對開發人員來說簡單,缺點是微服務涉及多資料來源或需要引入訊息佇列概念,整體架構較複雜。

針對三種方案,對於不同層次的實施團隊,選擇方式或許不同。其中,方案一即適用於後期補救方式記錄,也適用於統一入口方式記錄;方案二,適用於開發團隊技能較高,業務系統對操作日誌要求較高的團隊;方案三,適用於傳統團隊轉混合團隊使用。具體使用何種方案,可以根據實際情況進行選擇。正所謂“沒有最好的,只有最適合的