在现在卷的时代，常常看到招聘上写着要有使用Dubbo的项目开发经验

dubbo还有学习的必要吗_数据


开始对Dubbo的学习

目录

  • 一、什么是Dubbo
  • 二、为什么需要Dubbo
  • 三、Dubbo架构
  • 四、Dubbo注册中心
  • 4.1 Zookeeper
  • 4.1.1 注册程序流程
  • 4.1.2 为什么推荐zookeeper做注册中心?
  • 4.1.3 优势
  • 4.2 Multicast注册中心
  • 4.2.1 注册流程
  • 4.2.2 缺点
  • 4.3 Redis注册中心
  • 4.3.1 发布与订阅
  • 4.3.2 存在的问题
  • 4.4 Simple注册中心


一、什么是Dubbo

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

二、为什么需要Dubbo

Dubbo开始于电商系统，在以前，我们只需要一个服务器，将程序全部打包好就可以，但是，随着流量的增大，常规的垂直应用架构已无法应对，所以，架构就经历了以下的几个阶段：

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

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信 协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。
就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。

三、Dubbo架构

dubbo还有学习的必要吗_分布式_02

节点

角色说明

Provider

暴露服务的服务提供方

Consumer

调用远程服务的服务消费方

Registry

服务注册与发现的注册中心

Monitor

统计服务的调用次数和调用时间的监控中心

Container

服务运行容器

调用流程

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

四、Dubbo注册中心

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

  • Zookeeper注册中心
  • Multicast注册中心
  • Redis注册中心
  • Simple注册中心

官方推荐注册中心是用Zookeeper为注册中心

4.1 Zookeeper

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbox 服务的注册中心，工业强度较高，可用于生产环境.

4.1.1 注册程序流程

  • 服务提供程序启动时：在目录下写入服务URL地址；
  • 服务使用者启动时：订阅提供者的URL地址，同时，写下消费者的URL地址
  • 监控中心启动时：订阅所有提供者和消费者的URL地址。

4.1.2 为什么推荐zookeeper做注册中心?

Zookeeper的数据模型很简单，有一系列被称为ZNode的数据节点组成，与传统的磁盘文件系统不同的是，Zookeeper将全量数据存储在内存中（高性能），而且支持集群（高可用），另外支持事件监听。这些特点决定了Zookeeper特别适合作为注册中心(数据发布/订阅)

4.1.3 优势

  1. 当提供程序意外停止时，注册表服务器可以自动删除其信息。
  2. 注册表服务器重新启动时，可以自动恢复所有注册数据和订阅请求。
  3. 会话过期后，可以自动恢复所有注册数据和订阅请求。

4.2 Multicast注册中心

Multicast 注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。

dubbo还有学习的必要吗_分布式_03

4.2.1 注册流程

  1. 提供方启动时广播自己的地址
  2. 消费方启动时广播订阅请求
  3. 提供方收到订阅请求时，单播自己的地址给订阅者，如果设置了 unicast=false，则广播给订阅者
  4. 消费方收到提供方地址时，连接该地址进行 RPC 调用。

4.2.2 缺点

局域网内使用

4.3 Redis注册中心

通过Redis的发布订阅功能（Redis入门（五）—— 发布与订阅）实现服务的注册。

4.3.1 发布与订阅

在提供者和消费者上线上时，分别会进⾏发布与订阅事件，通过控制失效时间设置提供者的有效期，其主体流程如下:
消费端

  • 启动：注册消费者信息
  • 启动：启动⼀个阻塞线程，订阅(subscribe)该接⼝事件
  • 停⽌：删除接⼝消费信息
  • 停⽌：停⽌订阅线程

提供端

  • 启动：注册提供者信息
  • 启动：推送(publish) 接⼝注册事件
  • 停⽌：删除接⼝提供者信息
  • 停⽌：推送(publish) 接⼝注销事件

4.3.2 存在的问题

  1. 服务的非自然下线需要监护中心来维护
  2. redis做注册中心服务器时间必需同步，否则出现时间不对被强制过期(超出失效时间删除key)
  3. 需要客户端启动多个线程进行订阅监听，对服务器有一定压力

4.4 Simple注册中心

只是简单实现，不支持集群，可作为自定义注册中心的参考，但不适合直接用于生产环境。