Osheep

时光不回头,当下最重要。

Dubbo 是到底是用来做什么的?

这篇文章争取用比较浅显易懂的语言来描述 Dubbo,但是并不涉及具体的操作步骤,本人只是希望大家能对 Dubbo 这个概念有个更好的理解,那么之后你在使用 Dubbo 的时候才不会那么困惑。

Dubbo 是什么?

Dubbo 是阿里出的。为什么 Dubbo 成名了呢?阿里内部使用了它好长时间,一直木有对外公开,后来阿里面的工程师离职了,就把 Dubbo 给带出来了,后来阿里也就把 Dubbo 公开了。

官方说法,Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架,提供服务自动注册、自动发现等高效服务治理方案。RPC 指的是远程调用协议,也就是说两个服务器交互数据。

Dubbo 能做什么?

那么,我们究竟是在什么地方使用到的 Dubbo 呢?大家请看下面的流程图:

《Dubbo 是到底是用来做什么的?》

流程图

简单来说,用户发送的请求转交给 Nginx,然后 Nginx 决定将请求发送那个服务器(此处为 Tomcat),然后 Tomcat 将请求发送给 Dubbo,由它来决定继续调用哪个 service 层去数据库读取数据。

相信大家对于 Dubbo 作用于何处应该有个大体的了解了。

Dubbo 的使用原理解析

官方有提供的 Dubbo 的架构图。

《Dubbo 是到底是用来做什么的?》

架构图
  • Consumer:消费者
  • Provider:生产者
  • Registry:注册中心(相当于之前的等待–wait 和唤醒—notify)
  • Monitor:监控中心
    执行的顺序:
  • 0:先启动生产者;
  • 1:生产者将自己启动的消息报告给注册中心;
  • 2:消费者启动,通知注册中心;
  • 3:注册中心通知消费者有生产者了;
  • 4:消费者消费(调用方法);
  • 5:生产者和消费者将自己的调用信息和被调用信息发送监控中心;

要说明的是,必须要先启动生产者,就像咱们平常生活一样,只有生产了某样东西你才能去消费,对吧。

可能会有读者有疑问,这个生产者、消费者和上面的流程图有什么关系,或者说,生产者、消费者对应流程图中的哪个部分呢?

在这里我想用一些拟人化的手法解释一下,效果或许会更好点。

生产者相当于 service 层,拿上面的流程图来说,可以看成有三个生产者:service、service_2 和 service_3。

随便拿其中一个生产者举例子,比如说 service_2,它能够利用 dao 层去数据库取出数据,也就是说生产者可以拿到他人需要的数据,这也正符合「生产者」这个名词,service_2 可以 “生产” 出消费者需要的东西(数据)。

生产者在产生之后会先去 Registry 这个地方去「报到」,告诉Registry 它能生产哪些物品(即取出哪些数据)。

消费者相当于 controller 层,暂且把消费者叫做 c。如果 c 想要买某样东西(可以把这样东西看成数据库中的数据),但是不知道该去哪里买,那么这个时候,它就会去 Registry 这个地方,告诉 Registry 它需要这个东西。

由于生产者产生之后在这里「报到」过了,所以 Registry 会告诉消费者 c,生产者 service_2 可以给你你想要的东西(数据),然后消费者 c 就会去找生产者 service_2 而不去找其他两个生产者,这样一来 service 层的压力就会小很多。

不知道这么说大家有没有能够明白一点。

还有就是,不论是生产者还是消费者,产生之后都要去 Registry 报到,不然就是黑户哟~

另外,它俩都要受到 Monitor(监控中心)的监控,以监控它俩是否离奇失踪,哈哈。

Dubbo 的存在简单来说就是要减小 service 层的压力。

点赞