关于dubbo的理解

关于dubbo的理解

文章目录

• Dubbo 的基本资料
• • 1. 技术出现的背景
  • 2. Dubbo要解决的需求
  • 3. Dubbo的技术架构
  • 4. 入门案例
  • 5. 常见用法
  • • 5.1 启动时检查
    • 5.2 重试次数配置&超时
    • 5.3 负载均衡
    • • Random LoadBalance
      • RoundRobin LoadBalance
      • LeastActive LoadBalance
      • ConsistentHash LoadBalance
    • 5.4 并发控制
  • 6. 几个问题
  • • 6.1 `Dubbo` 的性能为什么高？
    • 6.2 Dubbo中的协议？
• 附录
• • 1 文档&资料
  • 2 几种注册中心的比较
  • 3 Dubbo 中常见的问题
  • 4 致谢

Dubbo 的基本资料

Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

词条来自百度

1. 技术出现的背景

网站应用的演进

• 单一应用架构

  ​ 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM：Object Relational Mapping)是关键。

  优点：开发简单，调试方便，部署方便。

  缺点：项目臃肿代码复杂，耦合度高，难维护。资源无法隔离（共享数据库、内存等），任何一个功能出现问题，整个系统就不能正常运作。无法做到单独扩展某一单独模块，比如订单模块。交付期长，需要完成所有功能。

• 垂直应用架构

  ​ 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发（或客户端）的Web框架(MVC)是关键。

  优点：解决了单一架构时的系统模块扩展问题，系统拆分实现了流量分担，解决了并发问题。可以针对某一系统扩容、优化。方便水平扩展。系统见独立。

  缺点：相同的逻辑代码不能复用，冗余度高。性能方面扩展时，主要靠部署集群的方式，成本高。

• 分布式服务架构

  ​ 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

  优点：业务复用。

  缺点：应用间互相调用，系统逻辑复杂。特别是应用很多时。

• 流动计算架构

  ​ 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

2. Dubbo要解决的需求

在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。

当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

以上是 Dubbo 最基本的几个需求。

基本功能：

透明化的远程方法调用

• 就像调用本地方法一样调用远程方法
• 只需简单配置，没有任何API侵入。

软负载均衡及容错机制

• 可在内网替代F5等硬件负载均衡器

服务自动注册与发现

• 不再需要写死服务提供方地址，注册中心基于接口名查询服务提
  供者的IP地址，并且能够平滑添加或删除服务提供者

3. Dubbo的技术架构

1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

4. 入门案例

CSDN Dubbo Zookeeper 的入门案例

CSDN Dubbo Nacos的入门案例

5. 常见用法

参考：https://dubbo.apache.org/zh/docsv2.7/user/examples/

5.1 启动时检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。

可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check="false"，总是会返回引用，当服务恢复时，能自动连上。

使用注解的方式，在消费者端：

@Reference(check = false)

属性文件方式：

# 某个接口
dubbo.reference.com.foo.BarService.check=false
dubbo.reference.check=false
# 关闭所有服务的启动时检查 (没有提供者时报错)
dubbo.consumer.check=false
# 关闭注册中心启动时检查 (注册订阅失败时报错)
dubbo.registry.check=false

5.2 重试次数配置&超时

Dubbo 服务在尝试调用一次之后，如出现非业务异常(服务突然不可用、超时等)，Dubbo 默认会进行额外的最多2次重试。

当消费者调用提供者时由于网络等原因有可能会造成长时间拿不到响应,而请求还在不断的发过来这就有可能造成线程阻塞,使用timeout设置超时时间当超过该时间就会抛出异常；

使用注解的方式在消费者端：

@Reference(retries=3, timeout=3000)

针对所有消费者时：

dubbo.consumer.retries=2
dubbo.consumer.timeout=3000

5.3 负载均衡

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。

Random LoadBalance

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只对第一个参数 Hash，如果要修改，请配置
• 缺省用 160 份虚拟节点，如果要修改，请配置

使用注解的方式在消费者端配置：

@Reference(loadbalance = "roundrobin")

loadbalance 的值即为四种负载均衡的名称,全部小写。

另外：

Dubbo推荐在Provider上尽量多配置Consumer端属性,原因如下：

1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

配置优先级：方法级优先，接口级次之，全局配置再次之；如果级别一样，则消费方优先，提供方次之。

​ 让 Provider 的实现者一开始就思考 Provider 端的服务特点和服务质量等问题。

5.4 并发控制

每客户端并发执行（或占用连接的请求数）不能超过 10 个：

使用注解在消费者端配置：

@Reference(actives=10)

Xml 配置方式：

在Provider 端常见的还有：

1. threads：服务线程池大小
2. executes：一个服务提供者并行执行请求上限，即当 Provider 对一个服务的并发调用达到上限后，新调用会阻塞，此时 Consumer 可能会超时。在方法上配置 dubbo:method 则针对该方法进行并发限制，在接口上配置 dubbo:service，则针对该服务进行并发限制

关于线程模型，这里不做赘述，官方参考文档：线程模型、并发控制

6. 几个问题 6.1 Dubbo 的性能为什么高？

Rpc 框架中，最关键和最耗时的是网络通信和序列化。

• **序列化：**我们学习 Java 网络开发的时候知道，本地的对象要在网络上传输，必须要实现Serializable 接口，也就是必须序列化。我们序列化的方案很多：xml、json、二进制流…其中效率最高的就是二进制流（因为计算机就是二进制的）。然而 Dubbo 采用的就是效率最高的二进制。

• **网络通信：**不同于 HTTP 需要进行 7 步走（三次握手和四次挥手），Dubbo 采用 Socket 通信机制，一步到位，提升了通信效率，并且可以建立长连接，不用反复连接，直接传输数据。

6.2 Dubbo中的协议？

1. 采用单一长链接和NIO异步通讯，适合小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

2. Dubbo协议底层默认使用的是netty，性能非常优秀，官方推荐使用此协议。

3. 不适合传输大数据量的服务，如传输文件，传视频等，除非请求量很低。

• 1.dubbo 单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步，Hessian 序列化。
• 2.rmi 采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现Serializable 接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。多个短连接，TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互 *** 作。在依赖低版本的 Common-Collections 包，java 序列化存在安全漏洞。
• 3.webservice 基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互 *** 作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；
• 4.http 基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实 现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消 费者，需要给应用程序和浏览器 JS 调用。
• 5.hessian 集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互 *** 作。多个短连接，同步 HTTP 传输，Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
• 6.memcache 基于 memcached 实现的 RPC 协议
• 7.redis 基于 redis 实现的 RPC 协议

附录 1 文档&资料

• zookeeper 下载
• dubbo2.7版本官方中文用户文档
• 百度搜索 Dubbo
• CSDN 架构演变及优缺点
• Nacos Server 下载
• Nacos 官方文档
• 博客园Dubbo注解常见配置
• CSDN 注册中心对比

2 几种注册中心的比较

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：保证每个请求不管成功或者失败都有响应。

分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

3 Dubbo 中常见的问题

• Dubbo 常见问题 - 信仰的文章 - 知乎 https://zhuanlan.zhihu.com/p/378310761

4 致谢

文中有些图、文来自个人博客、百度、Dubbo官方等网络资源，在附录的 【文档&资料】 中写了来处。感谢各位的付出。