在日常业务需求开发中，经常有对关键业务功能做操作日志记录，即某用户在某一时间操作某功能，操作前后的数据记录。尤其是在按业务功能模块拆分成多个project时，就会面临记录操作日志与业务逻辑之间解耦、记录操作日志更加简单、操作前后业务数据（字段）对比等问题。
接下来我们将介绍一种易于理解、简单接入操作日志的方法，同时提供一个通用的接口，方便前端开发者进行页面展示。
2. 预期目标
设计并实现一种通用的数据变更追踪和动态展示（对象描述）实践方案，该解决方案允许开发人员通过简单的注解来标记需要追踪的业务数据。该系统能够自动捕获所有标记数据的添加、修改等操作，并详细记录数据变更的每一步。同时，提供的动态展示接口，可以清晰、直观地展示数据的变更明细，让数据的前后差异一目了然。具体包括：
- 提供通用数据结构的接口，无需给前端额外定义接口字段描述。
- 低成本、快速记录数据Model的每一个字段变更前后的值。
3. 技术选型与对比
3.1业务代码嵌套
在应用层面，可以在业务代码中添加日志，记录下关键操作和数据的变更以及字段描述。例如，可以在每个数据库操作前后添加日志，记录下操作名称、时间、影响的数据等信息。这种方案需要改变业务代码（散弹式），增加编码的复杂性，麻烦且不够通用。
3.2Canal
Canal 是阿里巴巴开源的一款基于 MySQL 二进制日志（binlog）的增量数据订阅和消费组件。其主要功能是提供对 MySQL 数据库变更的实时监听，包括表结构或数据变动等。Canal 记录数据变更时，它捕获的是数据库层面上的原始变更事件，即 insert、update 和 delete 操作。这些事件是基于单个数据库事务的，Canal 本身并不处理关联数据的变更。当一个业务模型关联了多个表的数据时，订阅 binlog，需要根据业务的实际情况对获取的 binlog 数据进行正确组装和解析，包括正确的将多个表的变更合并到一个业务对象中。
这种方案的优点是和业务逻辑完全解耦。缺点也很明显，缺点是只能对数据库的更改做记录。
3.3触发器
触发器会增加数据库的复杂性和维护成本，如果处理不当，触发器可能导致性能问题，不考虑。
3.4AOP
面向切面编程（Aspect-Oriented Programming，AOP）是一种编程范式，主要用于将那些与业务逻辑无关，但在多个地方都需要使用的公共操作（如日志记录、安全检查、事务处理等）分离出来，降低系统的耦合度。AOP的运行需要动态生成代理类和织入切面，本实现方案一部分基于AOP实现。
4. 系统设计与实现
本实现方案基于Annotation+AOP+SpringEL+Swagger实现，AOP用于拦截配置自定义注解的Controller方法执行前后记录操作前后的数据。鉴于多数业务系统中，每一个业务模块都有根据ID查询明细数据，由此在记录数据时回调此业务的getById方法获取明细数据。SpringEL默认为调用业务模块的Service的getById方法，如果是uuid等其他条件获取数据时可以自定义配置。Swagger用于获取模型定义，在引入此类库的项目启动时，会扫描带有@ApiModel注解的模型并缓存，当模型发生变更时，找到相对应的模型定义一同存储。为这种不确定的实体字段存储，本方案采用MongoDB作为数据库。
图片
4.1定义Filter（TrackingAccessFilter）
图片
说明：初始化请求Context，并解析request相关信息。
4.2定义注解（@TrackingPoint）
定义操作类型与注解，操作类型为便于搜索，注解用于标记需要追踪变更的 Controller 方法。
图片
图片
说明：
- TrackingType 操作类型。
- moduleAlias 接口对应的模块名称，moduleClass接口对应的模块名称枚举类，如配置modelClass时，moduleAlias必为枚举类中的字段。主要为了方便模块名称的管理。
- title，，此次操作类型的简单描述，通常为接口功能描述。
- login，接口是否是登录后访问，如登录后访问，会回调AccessUserService获取当前用户信息。
- id，业务模型ID，也可以是UUID获其他。
- tracker：业务模块的对应Service的Bean，结合id最终拼接成SpringEL表达式，如Expression描述。
- preEvent：即在controller执行前执行的表达式，如为空时则默认使用Expression定义。当默认表达式不满足需求时可自定义。
- postEvent：与preEvent相同，只是在controller执行后执行。
4.3定义Tracker，业务模型回调接口
图片
说明：业务模块Service实现此接口，这样就能获取到业务实体Model。通过Spring EL表达式调用业务基础 Service 的 getById或listByIds等方法，分别获取方法执行前后的数据快照。将两次数据快照进行对比，然后获取相对应的Model描述，并生成详细的变更记录存储到MongoDB中。为不污染原业务Service代码，建议适配Tracker接口并注入原Service来实现getById、listByIds方法。虽增加了实现类，但对于 项目中一个模块的业务确是一劳永逸。
4.4定义AccessUserService用户信息回调接口
图片
说明：当注解中login为true时，回调此接口，获取当前登录用户信息，如为false时，回调getAnonymousUser()方法。
4.5定义TrackingPointAspect拦截请求
图片
图片
说明：
- 此切面用于在带有自定义注解的 Controller 方法执行前后进行拦截。主要功能解析注解内容生成SpringEL并执行，获取数据模型。
- before同步执行。当为修改操作时，为避免出现数据不一致，所以同步查询数据修改前的快照。
- afterReturing方法中，当业务执行完成后，发送事件，异步执行以提高效率。
4.6日志存储
图片
图片
说明：因预期目标想做到通用，业务字段的变更不确定，故而采用NoSQL数据库存储，本实现方案内置以MongoDB为默认存储数据库，仅对埋点的接口追踪日志存储，业务方可自定义日志处理器。如业务方自定义实现存储，实现AccessLogPersist接口并且配置为Bean即可，默认存储即失效。
4.7定义通用接口规则
为兼容不同业务Model不同的字段定义，接口返回变更前后的数据同时，将字段描述同时返回，以用户修改为例定义接口如下：
图片
图片
说明：
- oldObject：变更前数据节点。
- newObject：变更后数据节点。
- objectDescription：数据字段自释义节点，key为对象节点key，value值即是字段的含义。
- user: 修改人的信息。
- 如节点为object对象节点，同级节点下会自动添加 *Description后缀关键词，说明该对象描述，支持多级。
- 通用数据展示某一条修改日志明细
- 日志接口数据中含有数据节点的字段描述，以实现一个数据变更明细的动态展示，后文加以示例。
- module：模块
- title：
- type：操作类型
5. 实战案例
5.1以修改用户信息请求为例，执行时序图
图片
本节将以一个简单的用户（User）和任务（Task）的修改操作为例，介绍如何使用本方案实现数据变更追踪和动态展示功能。
5.2引入pom
图片
5.3实现用户信息回调接口
图片
说明：项目中实现权限，当为登录接口时，自动回调此方法将LoginUser设置到AccessLog.user对象中。
5.4业务接口回调实现
图片
图片
图片
说明：任务模块Service同理
5.5业务接口埋点
图片
5.6修改请求
分别修改User和Task id为1的User和Task,分别提交修改数据如下：
{
"age": 32,
"id": 1,
"username": "姜强"
}
{
"contractName": "jturbo",
"id": 1,
"name": "任务名称2"
}说明：returncode为0说明业务接口返回成功。
5.7通用展示
由上面两条日志，根据接口规则定义，前端查看变更明细时展示如下：
用户模块时：
图片
任务模块时：
图片
前端可忽略业务，根据接口规则动态渲染，也可使用JSONDiff，高亮差异。
6. 总结与展望
通过以上实践，我们可以实现对业务系统中数据变更的追踪和记录，通过通用的接口规则，可以动态地展示不同业务数据模型变更过程。这种方案的核心是将数据变更的追踪和记录与业务逻辑分离，使其成为一个通用的、可复用的服务。通过注解和 AOP技术，我们可以轻松地在业务系统中引入这种服务，而无需修改原有的业务代码。不仅可以提高代码的可维护性，而且记录用户的操作日志也更加优雅。
虽然当前已经能够满足大部分需求，但在未来，还计划增加功能：
在业务场景允许的情况下增加一键回退功能。
对于此方案大家有更好的建议，欢迎留言讨论。
作者简介
姜强强
经销商技术部-商业资源团队
016年加入汽车之家，目前主要负责经销商事业部内创新商业项目的研发工作，热衷于业内新技术的探索与实践。
