微服务体系操做日志如何记录？

提到日志 ，做为java开发人员，第一反应向导的应该都是log4j、logback等技术组件，可是在微服务体系中，系统进行拆分以后，造成多个模块以后，如何用统一的标准进行记录操做日志，业界没有统一的标准，也没有统一的组件进行记录，缘由主要是各业务系统对操做日志的定义要求、定义级别不一样，例如：

案例1：对用户操做的全部记录进行记录，尤为是增删改模型实体业务数据；

案例2：对用户操做的全部记录记录进行记录，尤为是操做时机、操做结果；

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

方案一：业务网关进行记录。针对微服务分布式应用，先后端交互、系统之间交互，都是经过业务网关进行交易转发。所以，能够在业务网关经过拦截器的方式进行记录，这种记录只能记录操做时间、操做人、操做类型、操做结果、入参、出参等，没法记录数据实体模型的变化状况。这种方案的各应用无需单独实现，只须要在业务网关进行解析记录便可，后期改造难度小、影响小；缺点没法记录数据实体自己记录，且模块信息以及操做类型只能经过规范性进行约束。

方案二：在业务实体变动时进行记录。这种记录须要在开发时，经过监听数据实体模型变化进行记录，这须要在应用开发时就考虑，后期改造难度大，影响大。这种方案优势是能够记录的很详细，包括实体模型先后变化状况等，缺点是开发须要彻底按照规范进行，而且微服务涉及多数据源或须要引入消息队列概念，复杂度较高。

方案三：在具体操做方法时进行记录。这种记录方式能够经过自定义注解的方式进行，在注解中进行标记模块信息及操做类型，而后经过AOP中解析注解中的参数进行记录。这种方式优势是日志记录模块及操做信息是经过手工设置，针对开发人员来讲简单，缺点是微服务涉及多数据源或须要引入消息队列概念，总体架构较复杂。

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