微服務體系操做日誌如何記錄？

提到日誌 ，做爲java開發人員，第一反應嚮導的應該都是log4j、logback等技術組件，可是在微服務體系中，系統進行拆分以後，造成多個模塊以後，如何用統一的標準進行記錄操做日誌，業界沒有統一的標準，也沒有統一的組件進行記錄，緣由主要是各業務系統對操做日誌的定義要求、定義級別不一樣，例如：

案例1：對用戶操做的全部記錄進行記錄，尤爲是增刪改模型實體業務數據；

案例2：對用戶操做的全部記錄記錄進行記錄，尤爲是操做時機、操做結果；

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

方案一：業務網關進行記錄。針對微服務分佈式應用，先後端交互、系統之間交互，都是經過業務網關進行交易轉發。所以，能夠在業務網關經過攔截器的方式進行記錄，這種記錄只能記錄操做時間、操做人、操做類型、操做結果、入參、出參等，沒法記錄數據實體模型的變化狀況。這種方案的各應用無需單獨實現，只須要在業務網關進行解析記錄便可，後期改造難度小、影響小；缺點沒法記錄數據實體自己記錄，且模塊信息以及操做類型只能經過規範性進行約束。

方案二：在業務實體變動時進行記錄。這種記錄須要在開發時，經過監聽數據實體模型變化進行記錄，這須要在應用開發時就考慮，後期改造難度大，影響大。這種方案優勢是能夠記錄的很詳細，包括實體模型先後變化狀況等，缺點是開發須要徹底按照規範進行，而且微服務涉及多數據源或須要引入消息隊列概念，複雜度較高。

方案三：在具體操做方法時進行記錄。這種記錄方式能夠經過自定義註解的方式進行，在註解中進行標記模塊信息及操做類型，而後經過AOP中解析註解中的參數進行記錄。這種方式優勢是日誌記錄模塊及操做信息是經過手工設置，針對開發人員來講簡單，缺點是微服務涉及多數據源或須要引入消息隊列概念，總體架構較複雜。

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