记录业务系统操作日志方案实践

在日常业务需求开发中，经常有对关键业务功能做操作日志记录，即某用户在某一时间操作某功能，操作前后的数据记录。尤其是在按业务功能模块拆分成多个project时，就会面临记录操作日志与业务逻辑之间解耦、记录操作日志更加简单、操作前后业务数据（字段）对比等问题。

         接下来我们将介绍一种易于理解、简单接入操作日志的方法，同时提供一个通用的接口，方便前端开发者进行页面展示。

设计并实现一种通用的数据变更追踪和动态展示（对象描述）实践方案，该解决方案允许开发人员通过简单的注解来标记需要追踪的业务数据。该系统能够自动捕获所有标记数据的添加、修改等操作，并详细记录数据变更的每一步。同时，提供的动态展示接口，可以清晰、直观地展示数据的变更明细，让数据的前后差异一目了然。具体包括：

         1. 提供通用数据结构的接口，无需给前端额外定义接口字段描述。

         2. 低成本、快速记录数据Model的每一个字段变更前后的值。

Canal 是阿里巴巴开源的一款基于 MySQL 二进制日志（binlog）的增量数据订阅和消费组件。其主要功能是提供对 MySQL 数据库变更的实时监听，包括表结构或数据变动等。Canal 记录数据变更时，它捕获的是数据库层面上的原始变更事件，即 insert、update 和 delete 操作。这些事件是基于单个数据库事务的，Canal 本身并不处理关联数据的变更。当一个业务模型关联了多个表的数据时，订阅 binlog，需要根据业务的实际情况对获取的 binlog 数据进行正确组装和解析，包括正确的将多个表的变更合并到一个业务对象中。

这种方案的优点是和业务逻辑完全解耦。缺点也很明显，缺点是只能对数据库的更改做记录。

说明：初始化请求Context，并解析request相关信息。

说明：

说明：业务模块Service实现此接口，这样就能获取到业务实体Model。通过Spring EL表达式调用业务基础 Service 的 getById或listByIds等方法，分别获取方法执行前后的数据快照。将两次数据快照进行对比，然后获取相对应的Model描述，并生成详细的变更记录存储到MongoDB中。为不污染原业务Service代码，建议适配Tracker接口并注入原Service来实现getById、listByIds方法。虽增加了实现类，但对于 项目中一个模块的业务确是一劳永逸。

说明：当注解中login为true时，回调此接口，获取当前登录用户信息，如为false时，回调getAnonymousUser()方法。

说明：

1.此切面用于在带有自定义注解的 Controller 方法执行前后进行拦截。主要功能解析注解内容生成SpringEL并执行，获取数据模型。

2.before同步执行。当为修改操作时，为避免出现数据不一致，所以同步查询数据修改前的快照。

3.afterReturing方法中，当业务执行完成后，发送事件，异步执行以提高效率。

说明：

1.oldObject：变更前数据节点。

2.newObject：变更后数据节点。

3.objectDescription：数据字段自释义节点，key为对象节点key，value值即是字段的含义。

4.user: 修改人的信息。

5.如节点为object对象节点，同级节点下会自动添加 *Description后缀关键词，说明该对象描述，支持多级。

6.通用数据展示某一条修改日志明细

7.日志接口数据中含有数据节点的字段描述，以实现一个数据变更明细的动态展示，后文加以示例。

8.module：模块

9.title：标题

10.type：操作类型

由上面两条日志，根据接口规则定义，前端查看变更明细时展示如下：

用户模块时：

通过以上实践，我们可以实现对业务系统中数据变更的追踪和记录，通过通用的接口规则，可以动态地展示不同业务数据模型变更过程。这种方案的核心是将数据变更的追踪和记录与业务逻辑分离，使其成为一个通用的、可复用的服务。通过注解和 AOP技术，我们可以轻松地在业务系统中引入这种服务，而无需修改原有的业务代码。不仅可以提高代码的可维护性，而且记录用户的操作日志也更加优雅。

虽然当前已经能够满足大部分需求，但在未来，还计划增加功能：

在业务场景允许的情况下增加一键回退功能。