Dubbo入门(一)

待我称王封你为后i 2023-09-27 14:31 64阅读 0赞

**目录**

1.应用服务的发展

2.什么是Dubbo？

3. Dubbo能做什么？解决了什么问题？

4. dubbo的架构

4.1.模块简介

4.2.Dubbo注册中心

5.Dubbo是怎么实现远程调用的

6.Dubbo优缺点

7.总结

8.面试集

参考资料

--------------------

**Dubbo官方手册：**[Dubbo 文档 | Apache Dubbo][Dubbo _ _ Apache Dubbo]

**Dubbo面试手册：**[Dubbo 常见面试题总结][Dubbo]

## 1.应用服务的发展 ##

很多时候，其实我们使用这个技术的时候，可能都是因为项目需要，所以，我们就用了，但是，至于为什么我们需要用到这个技术，可能自身并不是很了解的，但是，其实了解技术的来由及背景知识，对于理解一项技术还是有帮助的，那么，dubbo是怎么被提上日程的呢？

随着互联网的发展，网站的规模越来越大，用户数量越来越多。单一应用架构 、垂直应用架构无法满足我们的需求，这个时候分布式服务架构就诞生了。

分布式服务架构下，系统被拆分成不同的服务比如**短信服务、安全服务等**，每个服务独立提供系统的某个核心服务。

1.  **单体应用架构**
2.  **应用、数据库单独部署**
3.  **应用、数据库集群部署**
4.  **数据库压力变大，读写分离**
5.  **使用缓存技术加快速度**
6.  **数据库分库分表**
7.  **应用分为不同的业务类型拆分**

发展到这个阶段的时候，我们发现，应用与应用之间的关系已经十分的复杂了，就会出现以下几个问题：

1）当服务越来越多时，服务 ***URL 配置管理变得非常困难***，一个项目需要调用多个项目服务，需要配置多个项目的服务地址路径，配置在yml中，或者写入到数据库，不同的服务有不同的地址，一旦地址变更需要重新配置部署

2）硬件负载均衡器的***单点压力也越来越大***。  
3）***服务之间存在依赖关系***：分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。  
4）接着，***服务的调用量越来越大***，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

为了解决这由于架构的演变所产生的问题，于是，dubbo 应运而生

## 2.什么是Dubbo？ ##

**Dubbo是一个分布式服务框架，**Dubbo 是一款微服务开发框架，它提供了 **RPC通信** 与 **微服务治理** **两大关键能力**。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

没有分布式的需求，其实是不需要用的；只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

> **总结：**
> 
> Dubbo是阿里巴巴开源的基于 Java 的高性能RPC（一种远程调用） 分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
> 
> **Dubbo是：**
> 
>  *  一款分布式服务框架
>  *  高性能和透明化的RPC远程服务调用方案
>  *  SOA服务治理方案

## 3. Dubbo能做什么？解决了什么问题？ ##

> **Dubbo的核心功能**

**1). 透明化的远程方法调用**，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。  
 **2). 软负载均衡及容错机制：**同一个服务部署在不同的机器时该调用哪一台机器上的服务，降低成本，减少单点。  
 **3). 服务自动注册与发现：****不再写死接口地址**，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者，接口消费者也不再为服务提供者更换接口ip而重新配置或部署，总的来说就是**解耦，**解决通信层与服务治理层耦合严重的问题。

**4). 容错重试机制：**服务 Mock 数据，重试次数、超时机制等

**5****). 服务治理中心：**路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等手动配置

**6****). 性能日志监控：** Monitor 统计服务的调用次调和调用时间的监控中心

> **dubbo解决了什么问题？微服务组件之间的通信问题；****解决通信层与服务治理层耦合严重的问题**

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

## 4. dubbo的架构 ##

dubbo架构图如下所示：

![20131224140734734][]

**节点角色说明：**

*  **Container：** 服务运行容器，负责加载、运行服务提供者。必须。
 *  **Provider：** 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
 *  **Consumer：** 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
 *  **Registry：** 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
 *  **Monitor：** 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。 非必须

**调用流程：**

1）服务容器负责启动，加载，运行服务提供者。

2）服务提供者在启动时，向注册中心注册自己提供的服务。

3）服务消费者在启动时，向注册中心订阅自己所需的服务。

4）注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5）服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

6） 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

那么，整个发布-订阅的过程就非常的简单。

*  启动容器，加载，**运行服务提供者**。
 *  服务提供者在启动时，在注册中心**发布注册**自己提供的**服务**。
 *  服务消费者在启动时，在注册中心**订阅**自己所需的**服务**。

> 小结：服务消费者不再关心服务提供者的ip地址，只需要根据服务名称查找自己需要的服务

### 4.1.模块简介 ###

> dubbo-common 公共逻辑模块，包括Util类和通用模型。
> 
> dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
> 
> dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
> 
> dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
> 
> dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
> 
> dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
> 
> dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
> 
> dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

### 4.2.Dubbo注册中心 ###

**对于服务提供方**，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；  
**对于服务消费方**，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。  
而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。

通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。

Dubbo提供的注册中心有如下几种类型可供选择：

*  Zookeeper
    
     *  **统一命名服务**
     *  **配置管理：统一管理配置文件**
     *  **集群管理：**检测是否有机器退出或加入
     *  **分布式锁**：协调多个分布式进程之间的活动
 *  Nacos
 *  Consul
 *  Eureka 
 *  Polaris
 *  Sofa

zookeeper了解可以参考：

[https://blog.csdn.net/weixin\_43950588/article/details/108024709][https_blog.csdn.net_weixin_43950588_article_details_108024709]

[https://www.cnblogs.com/jxxblogs/p/12318779.html][https_www.cnblogs.com_jxxblogs_p_12318779.html]

## 5.Dubbo是怎么实现远程调用的  ##

![bd29ab70214585e4569c3d56057e5dfc.png][]

## 6.Dubbo优缺点 ##

**优点：**

**1）透明化的远程方法调用**  
\- 像调用本地方法一样调用远程方法；只需简单配置，没有任何API侵入。  
**2）软负载均衡及容错机制**  
可在内网替代nginx lvs等硬件负载均衡器。  
**3）服务注册中心自动注册 & 配置管理**  
\-不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip。  
使用类似zookeeper等分布式协调服务作为服务注册中心，可以将绝大部分项目配置移入zookeeper集群。  
**4）服务接口监控与治理**  
\-Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行 多版本，多协议，多注册中心管理。  
**缺点：**

只支持JAVA语言

## 7.总结 ##

看到这里，初学dubbo的朋友们可能会有疑问，为什么不出一个dubbo+zookeeper的结合体，我不管你内部实现，对于使用者而言就是一个整体，这样的框架有没有，答案是有的。

**Dubbo不提供注册中心功能，而是配合其他组件搭建项目，主要有以下几点原因：**

**1）解耦：Dubbo是一个有原则的组件，**Dubbo的核心设计思想是解耦，将各个组件拆分成独立的模块，注册中心也是其中之一。这样可以让用户**根据自己的需求选择合适的注册中心**实现，而不是被强制使用Dubbo自带的注册中心

**2）可扩展性：**Dubbo如果提供注册中心功能，不支持扩展其他中心，如果提供的注册中心功能不足以满足需求，那注定会被淘汰；**反而，**Dubbo支持多种注册中心，如Zookeeper、Redis、Multicast等，用户可以根据自己的需求选择适合自己的注册中心。

3）**高可用性：**Dubbo的注册中心是整个分布式系统的核心，如果Dubbo本身提供注册中心功能，那么一旦注册中心出现故障，整个系统就会瘫痪。而使用第三方注册中心，可以采用多节点部署等方式提高注册中心的可用性，从而提高整个系统的可靠性。

**再来说说Dubbo+zookeeper的替代方案**

可选方案如果还在dubbo框架内的话，可以有：

*  Nacos+Dubbo
 *  Etcd3+Dubbo
 *  Consul+Dubbo

如果不在dubbo框架内的话，可选方案为：

*  SpringCloud全家桶
 *  Vert.X
 *  Etcd+GRPC
 *  腾讯Tars
 *  .......

## 8.面试集 ##

> **面试官：我看你简历上写的精通Dubbo，那你能说一下Dubbo是什么吗？**

> 我：Dubbo最开始是一款RPC框架，随着功能越来越完善，现在Dubbo是一款Java服务框架。

> **面试官：嗯，既然你说到了RPC，那么他是什么呢？**

> 我：RPC是远程过程调用，RPC同时也是一种计算机通信协议，他可以从A机器调用B机器的程序，调用的时候就类似于调用本地程序一样方便。

> **面试官：嗯，那你说一下Dubbo都有哪些特性吧？**

> Dubbo具有负载均衡、服务超时处理、集群容错、服务降级、本地存根、本地伪装、参数回调、异步调用等特性。

> **面试官：嗯，那你说一下Dubbo的负载均衡是怎么实现的吧？**

> 我：在Dubbo中，消费者调用服务者的时候会记录服务者的active，比如现在有一个消费者，有A、B两个服务者。

> 当消费者向A服务发送一条消息的时候，消费者自身会记录A服务的active会加1，当消费者接收到服务者A的相应结果后会将A服务的active减1。

> 而在消费者选择使用哪个服务者的时候正是根据每个服务者active的大小来判断的，首先选择active小的来调用。

> **面试官：嗯，那你说一下Dubbo服务超时怎么设置吧，有什么要注意的吗？**

> Dubbo可以在消费者和服务端都设置超时时间，消费者的超时时间是消费者发出消息后到消费者接收到消息的时间。

> 服务端的超时时间是服务端接收消息后到处理完毕后发出的时间。

> 需要注意的是消费端的时间尽量设置的要比服务端的时间要长，因为如果消费端设置的是2秒，服务端设置的是5秒，而服务执行就需要3秒，那么消费端肯定是超时了，但是这个时候服务端并没有超时，不会发生异常。

> **面试官：嗯，那你说一下Dubbo的集群容错吧？**

> 集群容错是服务端有多个提供者，他们构成集群，当消费者调用服务端的时候服务端通过负载均衡策略选出一个提供者来提供服务，当调用这个服务者发生错误的时候，Dubbo后续采取了一系列策略。

> Dubbo提供了多种集群容错模式。

> Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

> Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

> Failsafe Cluster ：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

> Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

> Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

> Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

## 参考资料： ##

https://blog.csdn.net/noaman\_wgs/article/details/70214612

[https://juejin.cn/post/7104055656411299877][https_juejin.cn_post_7104055656411299877]

[Dubbo _ _ Apache Dubbo]: https://cn.dubbo.apache.org/zh-cn/overview/home/
[Dubbo]: https://javaguide.cn/distributed-system/rpc/dubbo.html
[20131224140734734]: https://img-blog.csdn.net/20131224140734734
[https_blog.csdn.net_weixin_43950588_article_details_108024709]: https://blog.csdn.net/weixin_43950588/article/details/108024709
[https_www.cnblogs.com_jxxblogs_p_12318779.html]: https://www.cnblogs.com/jxxblogs/p/12318779.html
[bd29ab70214585e4569c3d56057e5dfc.png]: https://img-blog.csdnimg.cn/img_convert/bd29ab70214585e4569c3d56057e5dfc.png
[https_juejin.cn_post_7104055656411299877]: https://juejin.cn/post/7104055656411299877