公司的架构师要求把日志封装成 LogUtil 类，提供 sdk 给各团队使用，并且不允许使用 slf4j 直接打印日志，请问各位这么做有哪些好处（我还没想到任何好处）？

[WillingXyz]

所有的日志打印都通过 LogUtil 类，并且日志上还得加上 code 来区分，比如 LogUtil.info("code101", "xxx")。 不能直接使用 slf4j 的 log.info("xxx")。

我完全不能理解这种操作，和他讨论了很多次，我觉得这样没有任何好处，因为 slf4j 本来就是一个门面，并且 logback 等实现提供了 Filter ，Coverter ，Appender 等扩展，完全可以通过 logback 来实现扩展，而不是侵入业务代码，并且业务也很难都改成这种方式啊。

他说是为了统一入口，便于以后扩展。但给不出具体的例子。工作了十几年了，都没产生好处，还要坚持封装。

ps：此人是我 leader 的 leader 。

请问：封装成 LogUtil 是否真的有好处，且相比 logback 扩展实现的更好，只是我没有想到，欢迎各位指点

[ppllss]

@RightHand 没有毛病

[Feiex]

在#85 楼的基础上补充一下，
1. 不管是 log4j2 还是 logback ，在生产环境都会有一些坑（比如打 error 日志把 CPU 打满的），这时候没必要每个团队都去写 error 限流代码，让 Util 团队升级即可
2. 很多时候实体和异常的日志序列化并不尽如人意（例如三方包的实体 toString 缺很多东西、toJson 性能又很差），这时候也需要 Util 出手统一解决
3. 最重要的还有 trace 、channel 、position 、region 等等这种链路上下文的参数打印，每个人写一遍 format 也是没必要的，需要 Util 出手统一处理

[exmario]

你 Leader 的 Leader 这种级别你就别折腾了，他脾气已经足够好了，还和你讨论很多次

[jobsssss]

这是我最近的感悟，只要使用了第三方库，尽量都 不要直接使用三方库提供的方法；而是自己抽象一套接口出来供业务使用。

因为我遇到了第三方库作者把库给删了的情况，我需要更换第三方库；如果我自己做了抽象的话，那就只用在抽象层换下适配驱动就可以了；如果是直接使用的第三方库那麻烦真大了。

[Foxkeh]

可以私聊去问问设计目的是什么?
是要在远程记录日志? 统一处理数据脱敏? 还是特殊格式要求便于采集分析?

[testHu]

“他说是为了统一入口，便于以后扩展。但给不出具体的例子。”
这是和架构师对话的一个好话题，楼主为啥不和他多沟通呢？

大型互联网公司，做统一的日志工具是很常见的操作，因为日志都汇总到监控系统和大数据分析平台了。

[WillingXyz]

@Foxkeh
@testHu 沟通几次了，每次讲一个小时，他只是之前习惯是这么做的，所以觉得应该这么做，但这么做的好处讲不出来

[sharpless]

v2 还是闲人多啊，打起来 赶紧 打起来

[SWALLOWW]

入戏太深
这事跟你一点关系没有
朋友

听领导就对了，何况是这种也跟你没有关系的活，

[Kaiv2]

LogUtil.get(业务场景 Enum).info(fmt, msg);
如果是我想的这样，可能是为了方便后续的日志分析

[vhcn]

使用统一接口当然是方便拓展咯，比如现在你们日志写文件，日后假如想统一传阿里云 sls 是不是就不用挨个业务去部署上传脚本了，更新一下你这个库就行了；后续再有海外的业务了，做数据隔离是不是也直接都能对接海外的云服务了；假如你们日志中可能有用户敏感信息需要脱敏后落盘的，是不是也可以统一做脱敏规则不需要各自业务方自己注意规则了

[kehuduanbuxing]

实际效果没差别，通过各种拓展肯定都能实现。
但是从架构的角度看，依赖关系得到了优化。第三方包变为二次封装包的依赖，而非项目的依赖。
理论上一堆二次封装包就可以形成公司的核心依赖 XX Foundation （虽然实际上也没什么用，增加了稳定性也降低了灵活性）增加了稳定性就降低了工作门槛，可控也就可随时换人

[chenliangcl02]

这个是架构管理的问题，站得位置不同看到的视角不一样，站在你自己的角度是没好处，但是在管理角度，就是全局统一，对人加约束，避免五花八门的问题出现

[layxy]

我们就统一使用 LogUtil,日志调整啥的基本都是工具类内部统一调整,打印日志的地方不需要调整, 比如统一日志格式,日志降级都在 util 中做的

[LFL]

你太菜鸡了，这个都不懂，执行就行了

[k9982874]

@lucasdev
@bk201
你俩可能是有误会，可以使用 slf4j 作为底层输出，这没问题。
上层封装 LogUtil 底层随便换实现，没人说要从头再造轮子。
人家架构师也没不让用 slf4j ，再仔细读读原文。

[sagaxu]

@Feiex 102# slf4j 只是个接口，如果 log4j2 和 logback 不行，那就做一个同层面的 logutil 实现，不用侵入接口。项目里有一堆第三方库用到了 slf4j ，你不可能把那些库全都 fork 一遍改掉，做个平替的 implementation 正好统一解决问题。

[weixind]

多次讲，每次一个小时 ，还是你的 +2 ，依旧说服不了你。

1. 你 +2 脾气也太好。
2. v2 那么多人竟然还想着讲道理能够说服你。

[BeforeTooLate]

1.OP 不想做自己认为没有意义的事情
2.OP 一定要问出 CTO 这么做的意义
3.要么 OP 当 CTO ，要么还是劝你不要这么闲。既然你已经和 CTO 讨论过 2 次了，还有必要继续这个话题吗？就服从安排工作不就行了。你要什么结果，要 CTO 认输，说好的，经过几轮友好协商认为 OP 同学对的，暂时不要封装了。

[canvascat]

不要反驳领导，领导说怎么做就怎么做