我們已經(jīng)不用AOP做操作日志了输硝！

文章來源于公眾號JAVA葵花寶典垢揩，作者努力減肥的胖子

前言

用戶在操作我們系統(tǒng)的過程中玖绿，針對一些重要的業(yè)務(wù)數(shù)據(jù)進行增刪改查的時候，我們希望記錄一下用戶的操作行為叁巨，以便發(fā)生問題時能及時的找到依據(jù)斑匪，這種日志就是業(yè)務(wù)系統(tǒng)的操作日志。

本篇我們來探討下常見操作日志的實現(xiàn)方案和可行性

常見的操作日志類型

用戶登錄日志
重要數(shù)據(jù)查詢?nèi)罩?（但電商可能不重要的數(shù)據(jù)也做埋點锋勺，比如在淘寶上你搜索什么商品蚀瘸，即使不買，一段時間內(nèi)首頁也會給你推薦類似的東西）
重要數(shù)據(jù)變更日志（如密碼變更庶橱，權(quán)限變更贮勃，數(shù)據(jù)修改等）
數(shù)據(jù)刪除日志
......

總結(jié)來說，就是重要的增刪改查根據(jù)業(yè)務(wù)的需要來做操作日志的埋點苏章。

實現(xiàn)方案對比

基于AOP（切面）傳統(tǒng)的實現(xiàn)方案

優(yōu)點：實現(xiàn)思路簡單寂嘉；
缺點：增加數(shù)據(jù)庫的負擔，強依賴前端的傳參枫绅，不方便拓展泉孩，不支持批量操作，不支持多表關(guān)聯(lián)并淋；

基于數(shù)據(jù)庫Binlog

優(yōu)點：解除了數(shù)據(jù)新舊變化的耦合寓搬，支持批量操作，方便多表關(guān)聯(lián)拓展县耽，不依賴開發(fā)語言句喷；
缺點：數(shù)據(jù)庫表設(shè)計需要統(tǒng)一的約定；

方案實現(xiàn)細節(jié)

一兔毙、基于AOP切面+注解的傳統(tǒng)方案

傳統(tǒng)的做法就是切面+注解的方式唾琼，這種對代碼的侵入性不強，通常記錄ip瞒御、業(yè)務(wù)模塊父叙、操作賬號、操作場景肴裙、操作來源等等趾唱，一般在注解+攔截器里這些值都拿得到，如下圖所示：

image

這種常見的我們在通用方法都可以處理蜻懦，但是在數(shù)據(jù)變更方面甜癞，一直沒有較好的實現(xiàn)方式，比如數(shù)據(jù)在變更前是多少宛乃，變更后是多少悠咱。

以我們以前實現(xiàn)的一套方案來說蒸辆，基于數(shù)據(jù)變更的記錄方式不僅要和需求方約定好模板（上百個字段的不可能都做展示和記錄），也要和前端做一些約定析既，比如在修改之前的值是多少躬贡，修改后的值是多少，如下代碼客官請看：

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

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

存在的問題：

1.舊值如果不多查詢一次數(shù)據(jù)庫則需要依賴前端把舊值封裝到oldData對象中眼坏，很有可能已經(jīng)不是修改前的值拂玻；
2.無法處理批量的List數(shù)據(jù)；
3.不支持多表操作宰译；

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

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

二沿侈、基于數(shù)據(jù)庫Binlog 方案

系統(tǒng)架構(gòu)圖如下：

image

「主要分為3塊：」

1：業(yè)務(wù)應(yīng)用生成每次操作的traceid闯第，并更新到操作的業(yè)務(wù)表中，發(fā)送1條業(yè)務(wù)消息缀拭，包含當前操作的操作人相關(guān)的信息咳短；
2：日志收集應(yīng)用對業(yè)務(wù)日志和轉(zhuǎn)換后的binlog日志做整合，提供對外的日志查詢搜索API智厌；
3：日志處理應(yīng)用
利用canal采集和解析業(yè)務(wù)庫的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日志轉(zhuǎn)換后的操作日志诚卸，如下：

  {
  "id":"120716921250250776",
  "relevanceInfo":"XX0000097413282,",
  "remark":"簽收財務(wù)網(wǎng)點編碼由【】改為【380000】，
  簽收網(wǎng)點名稱由【】改為【泉州南安網(wǎng)點】绘迁，簽收網(wǎng)點code由【】改為【2534104】合溺，運單狀態(tài)code由【204】改為【205】，簽收財務(wù)網(wǎng)點名稱由【】改為【福建代理區(qū)】缀台，簽收網(wǎng)點id由【0】改為【461】棠赛，簽收標識,1是，0否由【0】改為【1】膛腐，簽收時間由【null】改為【2020-04-24 21:09:47】睛约，簽收財務(wù)網(wǎng)點id由【0】改為【400】，",
  "traceId":"120716921250250775"
  }

庫表設(shè)計

1：所有業(yè)務(wù)系統(tǒng)表需要添加trace_id字段哲身，每次操作生成一個隨機字符串并保存到業(yè)務(wù)表中辩涝；
2：日志收集應(yīng)用庫表設(shè)計

    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 '數(shù)據(jù)庫名',
  `table_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ' 數(shù)據(jù)庫表名',
  PRIMARY KEY (`id`),
  UNIQUE KEY `unq_data_name_table_name` (`database_name`,`table_name`) USING BTREE COMMENT '數(shù)據(jù)庫名表名聯(lián)合索引'
) ENGINE=InnoDB AUTO_INCREMENT=35 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='數(shù)據(jù)庫配置表';

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 '字段 數(shù)據(jù)庫',
  `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 '是否是關(guān)聯(lián)字段(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='數(shù)據(jù)庫字段配置表';

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='數(shù)據(jù)字典配置表';

image

效果

image

基于binlog實現(xiàn)方案未來規(guī)劃

優(yōu)化發(fā)送業(yè)務(wù)消息的實現(xiàn)，使用切面攔截減少對業(yè)務(wù)代碼的侵入勘天；
目前暫時不支持對多表關(guān)聯(lián)操作日志記錄怔揩，需要拓展捉邢；

總結(jié)

本文以操作日志為題材討論了操作日志的實現(xiàn)方案和可行性，并且都已經(jīng)在功能上進行實現(xiàn)商膊，其中使用aop方案也是大部分中小企業(yè)的首選實現(xiàn)方案伏伐，但是在一些金融領(lǐng)域以及erp相關(guān)系統(tǒng)，對操作日志記錄明細要求極高晕拆，常見技術(shù)方案很難滿足秘案，即使能夠滿足也會帶來一些代碼強侵入以及性能問題，所以我們又討論了基于binlog實現(xiàn)的方案潦匈，該方案雖然比對aop來說增強了技術(shù)的復雜性阱高，但是對于有一定技術(shù)積累的團隊來說不算什么難事，并且該方案我們都實現(xiàn)了上線茬缩，并且解決了代碼層面上的侵入赤惊，屬于跨語言級別的，相信對讀者還是有一定的啟發(fā)凰锡。

我們已經(jīng)不用AOP做操作日志了始绍！

我們已經(jīng)不用AOP做操作日志了！

前言

常見的操作日志類型

實現(xiàn)方案對比

基于AOP（切面）傳統(tǒng)的實現(xiàn)方案

基于數(shù)據(jù)庫Binlog

方案實現(xiàn)細節(jié)

一兔毙、基于AOP切面+注解的傳統(tǒng)方案

存在的問題：

二沿侈、基于數(shù)據(jù)庫Binlog 方案

庫表設(shè)計

基于binlog實現(xiàn)方案未來規(guī)劃

總結(jié)