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

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

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

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

案例2：对用户操作的所有记录记录进行记录，尤其是操作时机、操作结果；

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

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