之前大群里有小伙伴在讨论用户IP日志记录的一些方案，也有小伙伴在做这个需求，私底下跟我咨询过，所以在此特地汇总梳理一下。

方案1

在登录业务中直接记录用户每次登录的IP日志，如下图所示：

用户请求登录的Controller，原先用户直接调用登录的service，这里假设用户登录校验都没问题，这个时候新增一个业务方法用于保存用户的ip，这个ip需要通过Controller的方法获得请求参数Request的IP后传入到Service，如此就可以保存。这里的数据库可以用MySql这样的关系型数据库，也可以使用MongoDB，个人建议后者。

这种方案简单粗暴，但是有个缺点，就是耦合太高了。对原先的代码有了侵入性，Controller与Service的方法都需要进行修改后方可生效。

方案2

为了降低耦合，使用消息队列，消息队列可以在controller中发、也可以在service中发，如下图所示

如果不考虑事务，并且不修改service的情况下，可以直接在controller中发消息即可。消费监听到消息后，调用service的保存ip方法即可。

使用消息队列方案也有一个很大的缺点，那就是太重了，很多公司一开始可能并没有消息队列，额外增加MQ也会提高运维的复杂度。所以这个方案看情况而定，没有必要为了一个非主线任务而增加中间件。

方案3

同样是解耦，由于MQ太重，所以可以采用Spring的异步任务来做。如下图所示：

此处也不考虑事务，因为没必要，直接在Controller中调用异步任务就可以。通过在异步任务中进行IP保存。

这么做其实没啥问题，但是有的公司的技术Leader或架构师不喜欢这种方式，因为这仍然对原有代码进行了破坏，也就是Controller需要修改代码，也依然会存在一定的耦合度。所以请看方案4。

方案4

使用Spring的AOP切面，如下图所示：

通过AOP，可以直接针对某个指定的方法进行切入，结合AOP的多种通知机制来做，如此针对性的方法可以在AOP中实现，只要切到登录业务方法，那么就会进入AOP的通知，在通知中调用IP业务进记录保存即可。

使用AOP切面也会存在小缺点，从长远考虑，Service中的方法小概率被其他业务或其他子项目调用，如此便会生成不必要的日志。短期的话AOP简单方便可以直接用，也降低代码的耦合，对原有业务代码零侵入。

方案5

使用拦截器(有些框架叫做过滤器)，本质上这也类似于切面，只不过这是针对请求的入口，在进入到controller之前进行IP数据的获取与记录。也许有小伙伴会问，AOP也可以直接切controller呀，直接用AOP也行吧？没错，但是习惯性不这么做，AOP一般对service的切入较多。相对而言，使用拦截器则更佳。参考如下图所示：

通过拦截器注册，指定分配给某个url的路由(如：/user/login)即可。如此每次请求经过该路由，则进入拦截器中，通过ip的获得并且调用IpService进行记录保存即可。

本方案相对可以实现，并且有的小伙伴也在这么用。所以如果在Java后端代码中实现的话，比较推荐方案5。当然处理方案5之外，还有一个比较好的方式，请参看方案6。

方案6

网关记录用户登录的IP日志。方案1~5都需要经过java代码的编写，并且重新打包发布版本，而且开发和运维还都需要走流程走工单。那么假设技术经理提出不从java代码层面来做的话，这个时候其实也可以。请参看如下图所示：

OpenResty目前在很多公司都是作为业务网关来使用，而且在高并发场景中出现的很多，几乎都在用，比如多级缓存架构都需要借助于OpenResty来实现。在图中，OpenResty可以作为业务网关来控制请求的走向，请求进来如果匹配到登录url(如：/user/login)，则进行lua脚本的转发，请求会进入到lua脚本中进行控制，lua脚本可以获得用户的ip以及用户id，如此就可以直接在lua中进行数据的存储，不管是mysql、mongodb或是redis，都可以进行存取。此处可以直接结合mongodb来进行日志记录的保存即可。

可以看到，本方案只需要修改网关增加lua脚本即可生效，对后端的Java代码是0侵入的，并且也降低业务代码的复杂度。当然缺点也有，那就是需要和运维人员协调，让运维来进行网关的业务编写。当然有些公司是由Java开发来实现OpenResty的相关代码，那么这样就更方便了，减少沟通成本。