Utilisez-vous toujours AOP pour les journaux d'opérations?!

Préface

Dans le processus d'exploitation de notre système, lorsque les utilisateurs ajoutent, suppriment, modifient et vérifient certaines données commerciales importantes, nous espérons enregistrer le comportement opérationnel de l'utilisateur afin que nous puissions trouver la base à temps lorsqu'un problème se produit. Ce journal est le journal des opérations du système commercial.

Dans cet article, nous discuterons de la mise en œuvre et de la faisabilité des journaux d'opérations communs

Types de journaux d'opérations courants

  • Journal de connexion de l'utilisateur
  • Journal de requêtes de données importantes (mais le commerce électronique peut ne pas être des données importantes à enterrer, telles que les produits que vous recherchez sur Taobao, même si vous n'achetez pas, la page d'accueil vous recommandera des choses similaires pendant un certain temps)
  • Journal des changements de données importants (comme le changement de mot de passe, le changement d'autorisation, la modification de données, etc.)
  • Journal de suppression des données
  • ......

En résumé, il est important d'ajouter, supprimer, modifier et vérifier le journal des opérations en fonction des besoins de l'entreprise.

Comparaison du plan de mise en œuvre

Basé sur le schéma de mise en œuvre traditionnel AOP (Aspect)

  • Avantages: idées de mise en œuvre simples;
  • Inconvénients: augmenter la charge de la base de données, s'appuyer fortement sur le transfert de paramètres frontaux, expansion peu pratique, ne prend pas en charge les opérations par lots, ne prend pas en charge l'association multi-table;

Basé sur la base de données Binlog

  • Avantages: Le couplage entre les nouvelles et anciennes modifications des données est libéré, l'opération par lots est prise en charge et l'expansion d'association multi-table est pratique et ne dépend pas des langages de développement;
  • Inconvénients: la conception des tables de base de données nécessite un accord unifié;

Détails de la mise en œuvre du schéma

1. Solution traditionnelle basée sur l'aspect AOP + annotation

L'approche traditionnelle est la méthode aspect + annotation, qui n'est pas très intrusive pour le code, enregistre généralement ip, module métier, compte d'opération, scénario d'opération, source d'opération, etc., généralement ces valeurs sont obtenues dans l'annotation + intercepteur ,Comme indiqué ci-dessous:

Nous pouvons gérer cette méthode courante en général, mais en termes de modification des données, il n'y a pas eu de meilleure façon de l'implémenter, comme la quantité de données avant la modification et la quantité après la modification.

En prenant un ensemble de solutions que nous avons implémentées auparavant, la méthode d'enregistrement basée sur les changements de données doit non seulement convenir d'un modèle avec le côté de la demande (il est impossible d'afficher et d'enregistrer des centaines de champs), mais aussi de conclure un accord avec le front-end , comme dans Quelle est la valeur avant modification et quelle est la valeur après modification, veuillez consulter le code suivant:

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

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

Problèmes existants:

  • 1. Si l'ancienne valeur n'interroge pas la base de données plus d'une fois, vous devez vous fier au frontal pour encapsuler l'ancienne valeur dans l'objet oldData, qui n'est probablement pas la valeur avant la modification;
  • 2. Impossible de traiter des lots de données de liste;
  • 3. Ne prend pas en charge le fonctionnement multi-table;

Prenons une autre scène comme exemple. Avant de supprimer, vous devez enregistrer la valeur avant de supprimer. Devez-vous la vérifier à nouveau ~

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

Deux, basé sur le programme Binlog de base de données

Le diagramme d'architecture du système est le suivant:

"Principalement divisé en 3 parties:"

  • 1: l'application métier génère le traceid de chaque opération, le met à jour dans la table métier de l'opération et envoie un message métier contenant des informations sur l'opérateur de l'opération en cours;
  • 2: L'application de collecte de journaux intègre les journaux d'activité et les journaux binlog convertis, et fournit des API de requête et de recherche de journal externes;
  • 3: L'application de traitement des journaux utilise canal pour collecter et analyser le journal des fichiers binaires de la bibliothèque d'entreprise et le livrer à Kafka. L'enregistrement analysé enregistre le type d'opération de l'opération en cours, comme l'enregistrement de suppression, de modification, d'ajout et de nouveau et anciennes valeurs, formatez comme suit:
{"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"}

Le journal des opérations après le traitement de la conversion du journal binlon est le suivant:

  {
  "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"
  }

Conception de table de bibliothèque

  • 1: Toutes les tables du système métier doivent ajouter le champ trace_id, et chaque opération génère une chaîne aléatoire et l'enregistre dans la table métier;
  • 2: conception de la table de la bibliothèque d'applications de collecte de journaux
    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='数据字典配置表';

effet

Basé sur binlog pour réaliser le futur plan du programme

  1. Optimiser la réalisation de l'envoi de messages commerciaux, et utiliser l'interception d'aspect pour réduire l'intrusion du code métier;
  2. Actuellement, il ne prend pas en charge les enregistrements du journal des opérations d'association multi-table et doit être développé;

Je suppose que tu aimes

Origine blog.csdn.net/baidu_39322753/article/details/106079759
conseillé
Classement