Dubbo日志打印剖析(自适配)
Dubbo 的日志打印机制
在以往的业务系统项目中,经常引入我们想接入的日志输出POM依赖, 利用相应的Logger API 输出日志或想打印的信息。但在依赖Spring Framework,Dubbo 或者其他项目时发现,只需要引入Logger相关Jar包依赖,就可以自适配Log 输出,利用适配后的日志输出系统打印相关信息。 它们的自适配是如何实现的呢?
这些框架是如何实现不同的日志系统与日志API解耦的
- Dubbo自己实现了自己的日志打印系统
- Spring Framework使用了 apache 的 commons-logging 来实现不同方式的日志打印与获取日志对象的解耦
首先分析下Dubbo源码的日志实现
Dubbo日志的调用方式,针对不同的日志打印系统,采用统一的API调用及输出,如:
/** * ChannelListenerDispatcher * * @author william.liangf */ public class ChannelHandlerDispatcher implements ChannelHandler { private static final Logger logger = LoggerFactory.getLogger(ChannelHandlerDispatcher.class); ........ }
LoggerFactory.getLogger 就可以获取这个类的统一的调用对象。
接下来查看日志相关源码位置
Dubbo 日志相关代码在common.logger下,分模块分包也是Dubbo模块化分层的方式之一。
日志系统UML图如下所示:
用到的设计模式:
装饰者模式
适配器模式
核心源码
Dubbo采用的日志输出方式是首先从dubbo.application.logger 系统变量中获取属性值,来判断到底采用哪种日志输出方式,如果没设置则按照默认的加载顺序加载相应的日志输出类,直到成功加载:
顺序为:log4jLogger > slf4jLogger > JclLogger > JdkLogger 。
接下来看LoggerFactory在类加载过程中变量的初始化过程:
static { String logger = System.getProperty("dubbo.application.logger"); if ("slf4j".equals(logger)) { setLoggerAdapter(new Slf4jLoggerAdapter()); } else if ("jcl".equals(logger)) { setLoggerAdapter(new JclLoggerAdapter()); } else if ("log4j".equals(logger)) { setLoggerAdapter(new Log4jLoggerAdapter()); } else if ("jdk".equals(logger)) { setLoggerAdapter(new JdkLoggerAdapter()); } else { try { setLoggerAdapter(new Log4jLoggerAdapter()); } catch (Throwable e1) { try { setLoggerAdapter(new Slf4jLoggerAdapter()); } catch (Throwable e2) { try { setLoggerAdapter(new JclLoggerAdapter()); } catch (Throwable e3) { setLoggerAdapter(new JdkLoggerAdapter()); } } } } }
可以看出相关加载过程。
LoggerFactory中有两个静态变量
private static final ConcurrentMap<String, FailsafeLogger> LOGGERS = new ConcurrentHashMap<String, FailsafeLogger>(); private static volatile LoggerAdapter LOGGER_ADAPTER;
LOGGER_ADAPTER 保存输出方式对应的适配器对象。(切换日志输出时,保证内存的可见)
LOGGERS 存有不同Service业务类对象的Logger对象。 避免同一业务类的Logger对象频繁创建问题。 (避免了业务人员对每次业务方法都通过LoggerFactory.getLogger 获取Logger对象,导致的Logger对象的频繁创建问题)
Dubbo通过这种方式在系统初始化(类加载)期间,完成了Logger的选型工作。
注: Logger 的选中根 dubbo.application.logger 系统变量设定 和 类加载顺序相关
赞赏支持

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
在yii2中,让你action参数支持POST数据的小方法
我们先来看一段代码 class RaController extends Controller { public $enableCsrfValidation = false; public function actionSay($username = '',$city = ''){ echo "{$username} 来自 {$city}"; } } 这里actionSay对应的url为index.php?r=ra/say,而 $username 和 $city 值的获取来自于url的参数,比如 index.php?r=ra/say&username=abei2017&city=洛阳 总结 在yii2中,action参数都是来自于GET。 但是有的时候你可能需要让action的参数来自于POST请求,怎么办? 重载runAction即可,yii2为控制器提供了runAction方法,它负责生成一个具体的Action对象并传递参数,我们可以通过复写它来实现,你可以看下yii2的生命周期来对其进行更好的了解。 那就开始干吧~,对上面的代码复写runAction class ...
- 下一篇
记Structured Streaming 2.3.1的OOM排查过程
记Structured Streaming 2.3.1的OOM排查过程 缘起 最近在使用Structured Streaming开发一套自助配置SQL的来生成流式作业的平台,在测试的过程中发现有些作业长时间运行后会有Executor端的OOM,起初以为是代码的问题,几经review和重构代码,都没有解决,无奈开始了这次OOM的问题排查之路。 干货 出现的问题 Structured Streaming 作业长时间运行后,会出现如下问题 可以看到spark为我们提供的统计信息,Task的GC时间占到了Task执行时间的70%,起初以为配置的内存不够,但是反复调大内存均出现此问题。 出现这种问题之后,紧接着就会出现Executor和Driver间心跳异常,或者Executor假死的状态,一般出现这类假死、jvm没有响应的问题大都可初步判断为是因为Jvm的Full GC而造成的Stop the World现象。 紧接着再过一段时间之后,在Executor的日志中会出现java.lang.OutOfMemoryError: Java heap space这类异常,导致Executor挂掉。 综上...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker快速安装Oracle11G,搭建oracle11g学习环境