操作记录对于一个系统来说重要性不言而喻，轻则供系统用户简单查看历史操作信息，重则能用来排查系统故障原因。而如何实现操作记录呢？这个问题一经抛出，我脑海中能浮现出来的内容有三点：直接植入操作记录逻辑、面向切面编程、消息中间件。这也是我想谈的操作记录“三步走”的问题。
直接植入操作记录逻辑，这是我想谈的操作记录“一步走”。例如在营销门户的用户登录、用户登出、新增用户等这些模块方法中直接植入操作记录逻辑，由植入的操作记录逻辑进行写表入库来完成当前操作的记录数据持久化。下面以用户登录场景为例，流程请见图1.1。
这种记录操作信息的方式是很“直白”的，起码在以前我很“推崇”这种实现方式，因为这很容易想得到，易于按着正常的思维逻辑来逐步进行编码实现。当然，这种处理方式在今天看来简直不可思议，因为有点“蠢”。“蠢”在哪里？用比较关键字眼来描述就是：强耦合、低复用率等，业务逻辑与操作记录逻辑之间的强耦合、操作记录逻辑代码的低复用率，将操作记录代码逻辑融入到具体业务逻辑中，这样一来，操作记录稍有改动，牵一发而动全身，所有的业务逻辑代码都要改动，如果工程模块数量很大，这个改造会浪费很多原本不必要的工作量。
这个问题能解决吗？能。既然强耦合、低复用率，那我怎么样来调整业务与非业务之间的处理逻辑呢？怎样来解决这个在喉之鲠呢？随着营销门户的项目规模逐渐庞大，这一需求越发明晰与强烈，面向切面编程这一重要思想，开始发挥了作用。
上面已经提到，我们的关注点落在了业务逻辑与非业务逻辑之间如何平衡、如何调整的问题上，那么，面向切面编程思想就是为此而来，操作记录的实现方式就有了"二步走"。Spring AOP通过面向切面技术将与业务无关却被业务模块所共用的逻辑代码封装起来，以提高代码的复用率，降低模块之间的耦合度。Spring AOP将应用分为核心关注点与横切关注点两部分，业务处理逻辑为核心关注点，被业务逻辑所依赖的公共部分为横切关注点。横切关注点的特点是其行为经常发生在核心关注点的多处，而多处操作基本类似。
这里还以上面提到的用户登录、用户登出、新增用户场景为例，对于这三个场景我都需要持久化操作记录，并且操作记录的代码逻辑是基本一致的，所以这里我们就可以把操作记录这块处理逻辑给抽象成切面给摘出来，如图2.1所示。此外，面向切面思想在具体模块中的体现，请见图2.2。
图2.1 用户登录、登出与新增用户场景及切面抽象关系图
图2.2 用户登录通过切面写入操作记录流程图
利用面向切面编程思想实现操作记录，既解决了业务逻辑与非业务逻辑之间强耦合，又提高了操作记录模块的代码复用率，倘若某天随着需求的变化，对操作记录的记录字段等提出了新的要求，那我们只需要关注并调整操作记录这个模块的代码即可，而不需要对其他业务逻辑代码进行调整，既能解决突出问题，又能提高效率。
不得不说，面向切面编程这种思想用到操作记录的实现上，堪称是特定场景采用特定解决办法的典范，通过操作记录切面，统一处理各个涉及操作记录的业务模块，优点十分明显。仔细想来，还有没有能够优化的地方呢？还是有的。
我们看到，通过面向切面编程这种方式，通过操作记录切面统一处理操作记录，并在切面逻辑中实现写表入库的操作，这样就实现了业务逻辑与非业务逻辑的解耦，可以将核心业务逻辑摆在更加突出而重要的位置。细细想来，这样不就够了吗？不已经实现我们的目的了吗？事实上，操作记录与业务逻辑处理相比，业务逻辑处理自然是要求实时响应的，越快越好，但是对于操作记录的写表入库则一般没这么高的要求，换句话说，只要我的业务服务能够实时响应，我并不是特别关心操作记录写表入库的时效，甚至在我业务处理完毕后一段时间再写入操作记录也没问题。这就引出了新的可以改进的地方，那就是按照我们设想，业务逻辑处理优先，相关的操作记录写表入库慢慢来。换个说法就是我们希望业务逻辑执行后，异步处理操作记录的写表入库。这就是接下来要谈的"三步走"。
"三步走"阶段主要想谈的是异步操作记录写表入库的问题，为啥提到异步操作记录会写到消息中间件呢？事实上，消息中间件在实现异步操作记录写表入库方便，堪称一大利器。大致的逻辑是这样的， 捡重点说就是用户登录成功后，会通过操作记录的切面，统一整合本次需要写表入库的操作数据，整合后并不直接完成写表入库这一动作，而是将整合后的操作记录数据直接发送给MQ，然后操作记录切面就完成了自身的任务。接下来，就有监听程序消费MQ中的操作记录的数据，有监听程序来实际完成操作记录写表入库这一动作。这样一来，我们就完成了重复呢的解耦，做到了"职能界限"分明。业务逻辑专注于自身业务处理、操作记录切面专注于整合待写表入库的记录数据并发给MQ、监听程序则专注于通过消费MQ中的操作记录数据并完成操作记录的写表入库动作。流程如图所示。
图3.1 用户登录MQ异步写入操作记录流程图
基于面向切面编程与消息中间件，实现操作记录参数的统一处理与操作记录的异步写表入库，这既能将业务核心逻辑给突显出来，又能满足高并发的需要，在很大程度上能够提高业务系统的性能。
本文阐述的操作记录实现方式的演变过程可以说是系统建设过程的一个缩影，“一步走”阶段我们解决从无到有的问题，“二步走”阶段我们解决从有到好的问题，“三步走”阶段我们解决从好到优的问题。无论是业务的探索、技术的适配，还是到系统的建设，每个环节都能寻得到“三步走”的影子，但是仅有“三步走”往往不够，我们还要持续探索。
随着时间的推移，可能出现的业务发展新模式、技术热点甚至创新点，都会在无形中敦促我们持续探索，持续适配，持续优化，为此，我们不能满足于现阶段的“三步走”，而要一直走。
