dubbo知识点

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

Dubbo在spring中的启动加载过程

  1. 在spring启动过程中，通过applicationContext去扫描配置项，扫描到Dubbo.xml，这个时候的dubbo就会初始化成一个bean对象，和其他bean本身没有区别，并且此时的dubbo还没有注册到注册中心暴露出去，只是一个最普通的bean存在

  2. 而一切顺利完成后，接下来就是暴露的过程。会调用bean中的导出export方法。然后找到所有的provide端中的服务，既我们的dubbo:service ，然后把里面的配置项，包括接口名，接口路径等一系列参数封装成一个url

  3. 然后找到我们dubbo。Xml中的protocol配置，一般这里都配的是zk以及zk的注册地址address，然后发送暴露，而暴露及时把这些url数据，封装成一个key-value的结构，然后存入一个全局的currentHashMap中

  4. 完成上述步骤后，暴露就完成了。接下来就是启动一个netty服务监听消费者消费；

 

Consumer和provide的通信过程

首先明确一点，dubbo是采用socket长连接双工模式的，传输方式的单连接NIO异步传输。

  1. 客户端发起dubbo调用请求时，此时dubbo会生成一个随机的唯一标识key

  2. 将调用信息（接口、方法名、参数）以及期望的一个callback响应组成一个object对象

  3. 将id和Object对象，以key-value的形式，存储进一个全局的currentHashMap中

  4. 然后再把id和Object对象组成一个request类，使用IOsession.write（）方法异步发送出去

  5. 然后客户端就会调用callback方法的get来获取响应结果，首先通过synchronize获取锁，然后检测时候已经有响应结果了，若是没有获取到，通过wait方法先把锁释放，进入到线程等待状态中

  6. 服务端获取接收到客户端发来的请求以后，开始按照request对象里的信息，进行逻辑处理。然后处理完毕后，并将结果回传给客户端

  7. 客户端socket连接上专门监听的线程收到服务端的回传信息以后，获取到id，然后从map里取出object对象，再将callback结果设置进去

  8. 然后监听线程会再次调用synchronize获取callback的锁，再notify（）。唤醒当前处于等待的线程，继续执行后续逻辑。

当时我就产生疑问了，为什么客户端socket获取到response响应结果时，没有立马去唤醒对应线程去执行，而是在第7、8步骤多走了一圈呢。我后来自己思考了一下，给出两种理由

  • socket获取到response以后，只知道id和Object，至于这是哪个线程发起的请求它并不清楚，即使去追溯也比较麻烦。

  • 解耦型考虑，如果一定去追溯线程，可能也能追溯到，但是dubbo在生产环节中socket接收不同线程的响应是非常频繁的，此时，又要接收响应，还要让线程继续执行，反而嵌套太深了，不利于扩展性的考量。。此处的socket就是做了一个接收响应，并往map中存放的过程。后续唤醒线程等操作，让监听自己去不断获取锁，这样可以达到解耦考虑

Zk宕机对dubbo的影响

Zk宕机以后，dubbo的服务还是能调用的到的。但是此时无法再往注册新的服务上去。之所以能调用到的原因是因为启动dubbo服务成功后，会在本地保存一份缓存，zk宕机后，本地的缓存可以继续使用。

 

 

Dubbo的核心组件

总共四个核心组件：Registry(注册中心)、Provider(服务提供方)、Consumer(服务消费方)、Monitor(监控)

  1. Registry(注册中心)：服务注册中心，默认是zk

  2. Provider(服务提供方)：服务提供方<dubbo:service />

  3. Consumer(服务消费方)<dubbo:reference />

  4. Monitor(监控):统计服务的调用次和监控中心 <dubbo:monitor>,一般同样配置为zk

 

Dubbo的负载均衡策略

  1. 权重策略，随机选取提供者的方式，根据权重值比例，权重值越高的服务，调用的概率越高（默认策略）

  2. 轮询策略，平均循环分不请求

  3. 最少活跃调用策略，解决慢提供者接收更少的情况

  4. Iphash一致性策略，使得相同参数请求总是指向同一台服务器

 

Dubbo集群容错机制

  1. 失败自动切换，自动尝试其他机器（默认机制，常用与读操作）

  2. 一旦失败就立即失败（常用与写操作）

  3. 出现异常直接忽略

  4. 失败了记录，然后定时重发操作

  5. 并行调用多个服务提供方，一旦有一个成功立即返回

  6. 逐个调用所有的提供方

 

Dubbo的服务发现过程

  1. comsumer 、producter、zk三者之间都是长连接的形式

  2. zk作为注册中心，当监听到服务端变更或是新的服务提供时，会讲新的服务列表推送到consumer端

  3. 本地缓存存储的是一个服务端的调用ip列表

以上是 dubbo知识点 的全部内容， 来源链接： utcz.com/z/514136.html

回到顶部