操作日志、审计日志解决方案和思路

操作日志

现在大部分公司一般使用SpringCloud这条技术栈，操作日志通过网关Gateway提供的Globalfilter统一拦截请求解析请求是比较好的选选择。

优点：相对于传统的过滤器、拦截器同步阻塞方案，SpringCloud Gateway使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架，提高了性能。

缺点：请求的解析与传统过滤器、拦截器有所不同，特别是获取请求参数与响应参数这块。

具体方案：在Globalfilter初始化时将需要拦截的路径加载到内存当中，解析请求和响应后构建日志实体，通过mq发送到消息队列，再通过mq监听器将数据落库。拦截路径和一些描述信息可配合swagger api来配置。

虽然请求和响应是异步，但是经过实践，一个Globalfilter就可以完成请求与响应参数的解析。思路是在请求时请求头解析和设置参数，响应时构建日志实体发送mq。

细节补充：注意请求头中直接设置中文会乱码，需要在网关编码和使用的地方解码。请求和响应流是一次性的，获取后需要重新构建，可自行搜索方案。响应流处理有不同方式，区别在于适用大量数据还是少量数据的返回，大量数据这种方式会对DataBuffer进行拼接，可避免少量中文乱码问题。

审计日志

审计日志与使用的数据持久层框架有关，如果使用mybatis，就可以通过mybatis拦截器来实现。方案是解析查询语句，将审计变更前数据缓存到redis，并根据登录token过期时长设置过期时间。拦截修改、逻辑删除等入参以及sql语句，通过入参及sql语句解析，去redis拿到变更前以及参数中变更后的数据生成审计日志实体，发送到mq指定队列，再通过mq监听消息落库。

优点：相对传统的注解解析方案，基本无业务侵入，并且数据库压力减小（无需查询变更前数据）。

缺点：审计粒度不够，对于关联id、状态字段这种，如果需要审计，仍需定制化一些逻辑。风险稍高，mybatis拦截器会对整个系统的sql进行了拦截，解析sql以及参数等需要谨慎实现。对于Mapper.xml定义的一些复杂的查询，不好处理。

细节补充：页面增、删、改基本是在查询后操作，这是方案可行的根本原因。审计字段来源为自己配置，存储方案自己选择，可在mybatis拦截器初始化是放到内存中；格式为系统标识-表名-字段名-id：数据。对于新增、删除这种如果要审计直接去redis拿数据即可。逻辑删除这种只有id参数的通过sql解析出表名扫描映射实体的包，获取字段信息，通过当前系统、表名、字段名、id信息再去redis拿数据即可。

具体代码实现暂不便透露。

后续补充：

操作日志这种最终做成了接口关键词过滤配置，只需要配置少量配置就可以达到记录操作日志效果，无需再关心配置问题。问题是接口描述信息如何获取？

在服务中添加HandlerInterceptor拦截器，在preHandler方法中获取swagger注解信息（不在postHandler是可能存在统一异常处理器），将接口描述放到响应头中（中文需要编解码）。

审计日志做成页面可配置，扫描数据源表和字段信息后页面勾选要审计字段。关联id的数据可扩展字段关联表、展示字段来处理。当关联表、字段单独提取出来，便于拦截器拦截数据存入redis。审计id类型变更时若关联表和字段不为空，则根据id拿到redis中的关联字段数据覆盖掉变更前后的id值。