1 回答

TA贡献1770条经验 获得超3个赞
直接解决您的问题
从技术上讲,我看到这种方法有两个问题:
所有控制器方法都需要清理本地线程。这足以让某个地方的某个人忘记将这个 finally 块放在某个控制器中 - 事情将开始崩溃。如果不清理 StringBuilder,也会发生内存泄漏。因此,对于通过“泄漏”控制器的所有线程,数据将越来越多地累积。
如果由于某种原因 BL 在另一个线程中生成/执行,代码将中断。
现在关于功能本身。我看到了这样一个要求的两个可能的理由:
审计
计量
如果我们谈论的是计量,考虑到您已经在使用 spring boot,您可以使用 Dropwizard 指标(spring boot 1.x)或 Micrometer(spring boot 2.x,带有可向后移植到 1.5.x)
如果我们谈论的是审计,那么与支持清理所有控制器中的内容的日志记录的耦合可能会很脆弱,正如我上面所说的那样。
我想引起您注意的最后一件事是“3 行”要求。一般来说,一起检查 3 条消息并不容易,通常人们只处理 1 行日志(搜索、计数、grep 等等),而不是同时处理 3 行。我提出这个问题,因为也许它可以指出它也可以将请求日志记录和审计应用程序业务事件的要求分开。在这种情况下,也许可以使用一种技术(过滤器、tomcat 阀等)记录请求,而审计本身可以使用其他技术甚至技术来完成。
如果您必须使用现有的解决方案,一种有趣的方法可能是将日志记录重构为某些 AOP 方面/过滤器或其他一些众所周知的点,以便所有控制器都不必处理您描述的代码
添加回答
举报