在日常业务需求开发中，经常有对关键业务功能做操作日志记录，即某用户在某一时间操作某功能，操作前后的数据记录。尤其是在按业务功能模块拆分成多个project时，就会面临记录操作日志与业务逻辑之间解耦、记录操作日志更加简单、操作前后业务数据（字段）对比等问题。
接下来我们将介绍一种易于理解、简单接入操作日志的方法，同时提供一个通用的接口，方便前端开发者进行页面展示。
设计并实现一种通用的数据变更追踪和动态展示（对象描述）实践方案，该解决方案允许开发人员通过简单的注解来标记需要追踪的业务数据。该系统能够自动捕获所有标记数据的添加、修改等操作，并详细记录数据变更的每一步。同时，提供的动态展示接口，可以清晰、直观地展示数据的变更明细，让数据的前后差异一目了然。具体包括：
在应用层面，可以在业务代码中添加日志，记录下关键操作和数据的变更以及字段描述。例如，可以在每个数据库操作前后添加日志，记录下操作名称、时间、影响的数据等信息。这种方案需要改变业务代码（散弹式），增加编码的复杂性，麻烦且不够通用。
Canal 是阿里巴巴开源的一款基于 MySQL 二进制日志（binlog）的增量数据订阅和消费组件。其主要功能是提供对 MySQL 数据库变更的实时监听，包括表结构或数据变动等。Canal 记录数据变更时，它捕获的是数据库层面上的原始变更事件，即 insert、update 和 delete 操作。这些事件是基于单个数据库事务的，Canal 本身并不处理关联数据的变更。当一个业务模型关联了多个表的数据时，订阅 binlog，需要根据业务的实际情况对获取的 binlog 数据进行正确组装和解析，包括正确的将多个表的变更合并到一个业务对象中。
这种方案的优点是和业务逻辑完全解耦。缺点也很明显，缺点是只能对数据库的更改做记录。
触发器会增加数据库的复杂性和维护成本，如果处理不当，触发器可能导致性能问题，不考虑。
面向切面编程（Aspect-Oriented Programming，AOP）是一种编程范式，主要用于将那些与业务逻辑无关，但在多个地方都需要使用的公共操作（如日志记录、安全检查、事务处理等）分离出来，降低系统的耦合度。AOP的运行需要动态生成代理类和织入切面，本实现方案一部分基于AOP实现。
本实现方案基于Annotation+AOP+SpringEL+Swagger实现，AOP用于拦截配置自定义注解的Controller方法执行前后记录操作前后的数据。鉴于多数业务系统中，每一个业务模块都有根据ID查询明细数据，由此在记录数据时回调此业务的getById方法获取明细数据。SpringEL默认为调用业务模块的Service的getById方法，如果是uuid等其他条件获取数据时可以自定义配置。Swagger用于获取模型定义，在引入此类库的项目启动时，会扫描带有@ApiModel注解的模型并缓存，当模型发生变更时，找到相对应的模型定义一同存储。为这种不确定的实体字段存储，本方案采用MongoDB作为数据库。
图片
图片
说明：初始化请求Context，并解析request相关信息。
定义操作类型与注解，操作类型为便于搜索，注解用于标记需要追踪变更的 Controller 方法。
图片
图片
说明：
图片
说明：业务模块Service实现此接口，这样就能获取到业务实体Model。通过Spring EL表达式调用业务基础 Service 的 getById或listByIds等方法，分别获取方法执行前后的数据快照。将两次数据快照进行对比，然后获取相对应的Model描述，并生成详细的变更记录存储到MongoDB中。为不污染原业务Service代码，建议适配Tracker接口并注入原Service来实现getById、listByIds方法。虽增加了实现类，但对于 项目中一个模块的业务确是一劳永逸。
图片
说明：当注解中login为true时，回调此接口，获取当前登录用户信息，如为false时，回调getAnonymousUser()方法。
图片
图片
说明：
图片
图片
说明：因预期目标想做到通用，业务字段的变更不确定，故而采用NoSQL数据库存储，本实现方案内置以MongoDB为默认存储数据库，仅对埋点的接口追踪日志存储，业务方可自定义日志处理器。如业务方自定义实现存储，实现AccessLogPersist接口并且配置为Bean即可，默认存储即失效。
为兼容不同业务Model不同的字段定义，接口返回变更前后的数据同时，将字段描述同时返回，以用户修改为例定义接口如下：
图片
图片
说明：
图片
本节将以一个简单的用户（User）和任务（Task）的修改操作为例，介绍如何使用本方案实现数据变更追踪和动态展示功能。
图片
图片
说明：项目中实现权限，当为登录接口时，自动回调此方法将LoginUser设置到AccessLog.user对象中。
图片
图片
图片
说明：任务模块Service同理
图片
分别修改User和Task id为1的User和Task,分别提交修改数据如下：
{ "age": 32, "id": 1, "username": "姜强"}{ "contractName": "jturbo", "id": 1, "name": "任务名称2"}说明：returncode为0说明业务接口返回成功。
由上面两条日志，根据接口规则定义，前端查看变更明细时展示如下：
用户模块时：
图片
任务模块时：
图片
前端可忽略业务，根据接口规则动态渲染，也可使用JSONDiff，高亮差异。
通过以上实践，我们可以实现对业务系统中数据变更的追踪和记录，通过通用的接口规则，可以动态地展示不同业务数据模型变更过程。这种方案的核心是将数据变更的追踪和记录与业务逻辑分离，使其成为一个通用的、可复用的服务。通过注解和 AOP技术，我们可以轻松地在业务系统中引入这种服务，而无需修改原有的业务代码。不仅可以提高代码的可维护性，而且记录用户的操作日志也更加优雅。
虽然当前已经能够满足大部分需求，但在未来，还计划增加功能：
在业务场景允许的情况下增加一键回退功能。
对于此方案大家有更好的建议，欢迎留言讨论。
作者简介
姜强强
经销商技术部-商业资源团队
016年加入汽车之家，目前主要负责经销商事业部内创新商业项目的研发工作，热衷于业内新技术的探索与实践。
本文链接：http://www.28at.com/showinfo-26-57400-0.html记录业务系统操作日志方案实践
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Elasticsearch 8.X 小技巧：使用存储脚本优化数据索引与转换过程
下一篇： Go语言常见错误—意外的变量隐藏
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号