通过之前的学习,我们大概了解到Dubbo服务在启动的时候会全量从注册中心获取所有的服务信息,但是我们不可能每次每次都是全量的从注册中心获取,否则会导致注册中心的压力很大,所以增量是一个关键的话题。我们在写业务代码也是同样的道理,要合理的利用cache这种理念,将80%的非关键流量拦截在cache层面。Dubbo册中心的缓存是实现在AbstractRegistry抽象类中的。同时其缓存机制将服务信息进行了落地存储,在此基础上将服务信息放到notified对象中。

服务启动时,AbstractRegistry首先从磁盘中获取注册数据,并读到properties对象中,然后加载到内存中。

linux dubbo 本地缓存文件位置查找 dubbo本地缓存更新_设计模式

缓存的保存有同步和异步两种方式,异步会使用线程池异步保存,

linux dubbo 本地缓存文件位置查找 dubbo本地缓存更新_spring_02

如果获取某个服务信息失败,会调用retry进行重试。

Dubbo注册中心使用的设计模式

1.模板模式

注册中心的逻辑部分使用了模板模式,这个跟Spring的refresh方法一样。模板模式的核心是在抽象类中定好执行的流程,而降具体的实现放到子类中。最后在具体执行的时候调用抽象类的方法,将所有流程串联起来完成整体业务。

2.工厂模式

所有注册中心的实现,都是通过相应的工厂创建的。工厂模式也是日常开发中比较常见的,概况来说是抽象一个接口,让不同特性的同属性类去实现,并通过一些条件去决定最终的对象是那个,同时用首相的接口去承载最后的对象。如此,对外的业务无需关注实例化的具体逻辑,相当于对业务透明了。Dubbo的工厂判断条件是通过@Adaptive注解实现的,这个后边我们再研究。