新來的老大,劍走偏鋒,幹掉AOP做操作日誌,實現後我們都驚呆了

友人421發表於2020-05-27

前言

使用者在操作我們系統的過程中,針對一些重要的業務資料進行增刪改查的時候,我們希望記錄一下使用者的操作行為,以便發生問題時能及時的找到依據,這種日誌就是業務系統的操作日誌。

本篇我們來探討下常見操作日誌的實現方案和可行性

常見的操作日誌型別

  • 使用者登入日誌
  • 重要資料查詢日誌 (但電商可能不重要的資料也做埋點,比如在淘寶上你搜尋什麼商品,即使不買,一段時間內首頁也會給你推薦類似的東西)
  • 重要資料變更日誌 (如密碼變更,許可權變更,資料修改等)
  • 資料刪除日誌
  • ......

總結來說,就是重要的增刪改查根據業務的需要來做操作日誌的埋點。

實現方案對比

基於AOP(切面)傳統的實現方案

  • 優點:實現思路簡單;
  • 缺點:增加資料庫的負擔,強依賴前端的傳參,不方便擴充,不支援批量操作,不支援多表關聯;

基於資料庫Binlog

  • 優點:解除了資料新舊變化的耦合,支援批量操作,方便多表關聯擴充,不依賴開發語言;
  • 缺點:資料庫表設計需要統一的約定;

方案實現細節

一、基於AOP切面+註解的傳統方案

傳統的做法就是切面+註解的方式,這種對程式碼的侵入性不強,通常記錄ip、業務模組、操作賬號、操作場景、操作來源等等,一般在註解+攔截器裡這些值都拿得到,如下圖所示:

 

這種常見的我們在通用方法都可以處理,但是在資料變更方面,一直沒有較好的實現方式,比如資料在變更前是多少,變更後是多少。

以我們以前實現的一套方案來說,基於資料變更的記錄方式不僅要和需求方約定好模板(上百個欄位的不可能都做展示和記錄),也要和前端做一些約定,比如在修改之前的值是多少,修改後的值是多少,如下程式碼客官請看:

    @Valid
    @NotNull(message = "新值不能為空")
    @UpdateNewDataOperationLog
    private T newData;

    @Valid
    @NotNull(message = "舊值不能為空")
    @UpdateOldDataOperationLog
    private T oldData;

存在的問題:

  • 1.舊值如果不多查詢一次資料庫則需要依賴前端把舊值封裝到oldData物件中,很有可能已經不是修改前的值;
  • 2.無法處理批量的List資料;
  • 3.不支援多表操作;

再以一個場景為例,再刪除之前需要記錄刪除前的值,是不是還得再查一次~

    @PostMapping("/delete")
    @ApiOperation(value = "刪除使用者資訊", notes = "刪除使用者資訊")
    @DeleteOperationLog(system = SystemNameNewEnum.SYS_JMS_LMDM, module = ModuleNameNewEnum.LMDM_AUTH, table = LogBaseTableNameEnum.TABLE_USER, methodName = "detail")

二、基於資料庫Binlog 方案

系統架構圖如下:

 

「主要分為3塊:」

  • 1:業務應用 生成每次操作的traceid,並更新到操作的業務表中,傳送1條業務訊息,包含當前操作的操作人相關的資訊;
  • 2:日誌收集應用 對業務日誌和轉換後的binlog日誌做整合,提供對外的日誌查詢搜尋API;
  • 3:日誌處理應用
    • 利用canal採集和解析業務庫的binlog日誌並投遞到kafka中,解析後的記錄中記錄了當前操作的操作型別,如屬於刪除、修改、新增,和新舊值的記錄,格式如下:
{"data":[{"id":"122158992930664499","bill_type":"1","create_time":"2020-04-2609:15:13","update_time":"2020-04-2613:45:46","version":"2","trace_id":"exclude-f04ff706673d4e98a757396efb711173"}],
"database":"yl_spmibill_8",
"es":1587879945200,
"id":17161259,
"isDdl":false,
"mysqlType":{"id":"bigint(20)",
"bill_type":"tinyint(2)",
"create_time":"timestamp",
"update_time":"timestamp",
"version":"int(11)",
"trace_id":"varchar(50)"},
"old":[{"update_time":"2020-04-2613:45:45",
"version":"1",
"trace_id":"exclude-36aef98585db4e7a98f9694c8ef28b8c"}],
"pkNames":["id"],"sql":"",
"sqlType":{"id":-5,"bill_type":-6,"create_time":93,"update_time":93,"version":4,"trace_id":12},
"table":"xxx_transfer_bill_117",
"ts":1587879945698,"type":"UPDATE"}

處理完binlon日誌轉換後的操作日誌,如下:

  {
  "id":"120716921250250776",
  "relevanceInfo":"XX0000097413282,",
  "remark":"簽收財務網點編碼由【】改為【380000】,
  簽收網點名稱由【】改為【泉州南安網點】,簽收網點code由【】改為【2534104】,運單狀態code由【204】改為【205】,簽收財務網點名稱由【】改為【福建代理區】,簽收網點id由【0】改為【461】,簽收標識,1是,0否由【0】改為【1】,簽收時間由【null】改為【2020-04-24 21:09:47】,簽收財務網點id由【0】改為【400】,",
  "traceId":"120716921250250775"
  }

庫表設計

  • 1:所有業務系統表需要新增trace_id欄位,每次操作生成一個隨機字串並儲存到業務表中;
  • 2:日誌收集應用庫表設計
    CREATE TABLE `table_config` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `database_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '資料庫名',
  `table_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ' 資料庫表名',
  PRIMARY KEY (`id`),
  UNIQUE KEY `unq_data_name_table_name` (`database_name`,`table_name`) USING BTREE COMMENT '資料庫名錶名聯合索引'
) ENGINE=InnoDB AUTO_INCREMENT=35 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='資料庫配置表';
CREATE TABLE `table_field_config` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `table_config_id` bigint(20) DEFAULT NULL,
  `field` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '欄位 資料庫',
  `field_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '欄位 中文名稱',
  `enum_flag` tinyint(2) DEFAULT NULL COMMENT '是否列舉欄位(1:是,0:否)',
  `relevance_flag` tinyint(2) DEFAULT NULL COMMENT '是否是關聯欄位(1:是,0否)',
  `sort` int(11) DEFAULT NULL COMMENT '排序',
  PRIMARY KEY (`id`),
  KEY `idx_table_config_id` (`table_config_id`) USING BTREE COMMENT '表ID索引'
) ENGINE=InnoDB AUTO_INCREMENT=2431 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='資料庫欄位配置表';
CREATE TABLE `table_field_value` (
  `id` bigint(20) NOT NULL,
  `field_config_id` bigint(20) DEFAULT NULL,
  `field_key` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ' 列舉',
  `filed_value` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '列舉名稱',
  PRIMARY KEY (`id`),
  KEY `ids_field_config_id` (`field_config_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='資料字典配置表';

 

效果

 

基於binlog實現方案未來規劃

  1. 優化傳送業務訊息的實現,使用切面攔截減少對業務程式碼的侵入;
  2. 目前暫時不支援對多表關聯操作日誌記錄,需要擴充;

總結

本文以操作日誌為題材討論了操作日誌的實現方案和可行性,並且都已經在功能上進行實現,其中使用aop方案也是大部分中小企業的首選實現方案,但是在一些金融領域以及erp相關係統,對操作日誌記錄明細要求極高,常見技術方案很難滿足,即使能夠滿足也會帶來一些程式碼強侵入以及效能問題,所以我們又討論了基於binlog實現的方案,該方案雖然比對aop來說增強了技術的複雜性,但是對於有一定技術積累的團隊來說不算什麼難事,並且該方案我們都實現了上線,並且解決了程式碼層面上的侵入,屬於跨語言級別的,相信對讀者還是有一定的啟發。

最後的最後,如果你覺得本文有收穫,來個點贊轉發可好~

相關文章