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

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

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

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

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

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

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

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