微服务体系操作日志如何记录?

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

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

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

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

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

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

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

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

本站资源均源自网络,若涉及您的版权、知识产权或其他利益,请附上版权证明邮件告知。收到您的邮件后,我们将在72小时内删除。
若下载资源地址错误或链接跳转错误请联系站长。站长q:770044133。

» 微服务体系操作日志如何记录?

发表评论

免登录下载网,提供全网最优质的资源集合!