导读 针对操作日志,每个系统或企业经营业务领域不同、负责人知识面不同、以及系统等级不同,要求差异也很大,那如何在服务开发过程中,根据用户自定义的需求进行统一记录呢,本文将亲身经历进行讲述,废话不多说,我们开始!

提到日志 ,作为java开发人员,第一反应向导的应该都是log4j、logback等技术组件,但是在微服务体系中,系统进行拆分之后,形成多个模块之后,如何用统一的标准进行记录操作日志,业界没有统一的标准,也没有统一的组件进行记录,原因主要是各业务系统对操作日志的定义要求、定义级别不同,例如:

案例1:对用户操作的所有记录进行记录,尤其是增删改模型实体业务数据;

案例2:对用户操作的所有记录记录进行记录,尤其是操作时机、操作结果;

方案一:业务网关进行记录。针对微服务分布式应用,前后端交互、系统之间交互,都是通过业务网关进行交易转发。因此,可以在业务网关通过拦截器的方式进行记录,这种记录只能记录操作时间、操作人、操作类型、操作结果、入参、出参等,无法记录数据实体模型的变化情况。这种方案的各应用无需单独实现,只需要在业务网关进行解析记录即可,后期改造难度小、影响小;缺点无法记录数据实体本身记录,且模块信息以及操作类型只能通过规范性进行约束。

方案二:在业务实体变更时进行记录。这种记录需要在开发时,通过监听数据实体模型变化进行记录,这需要在应用开发时就考虑,后期改造难度大,影响大。这种方案优点是可以记录的很详细,包括实体模型前后变化情况等,缺点是开发需要完全按照规范进行,并且微服务涉及多数据源或需要引入消息队列概念,复杂度较高。

方案三:在具体操作方法时进行记录。这种记录方式可以通过自定义注解的方式进行,在注解中进行标记模块信息及操作类型,然后通过AOP中解析注解中的参数进行记录。这种方式优点是日志记录模块及操作信息是通过手工设置,针对开发人员来说简单,缺点是微服务涉及多数据源或需要引入消息队列概念,整体架构较复杂。

针对三种方案,对于不同层次的实施团队,选择方式或许不同。其中,方案一即适用于后期补救方式记录,也适用于统一入口方式记录;方案二,适用于开发团队技能较高,业务系统对操作日志要求较高的团队;方案三,适用于传统团队转混合团队使用。具体使用何种方案,可以根据实际情况进行选择。正所谓“没有最好的,只有最适合的”。

原文来自:https://www.cnblogs.com/pengteng/p/13458936.html

本文地址:https://www.linuxprobe.com/record-microservice-system.html编辑:薛鹏旭,审核员:逄增宝

Linux命令大全:https://www.linuxcool.com/

Linux系统大全:https://www.linuxdown.com/

红帽认证RHCE考试心得:https://www.rhce.net/