Dubbo框架学习-02-Duboo概念&&架构

本文详细介绍了Dubbo 3.0的升级亮点,包括应用级服务发现、Triple协议的优势、流量管理和配置动态性。重点讨论了服务发现机制的转变,协议选择的灵活性,以及在性能、可伸缩性和安全性方面的提升。

Dubbo介绍

    Apache Dubbo |ˈdʌbəʊ| 是阿里巴巴开发的一款高性能、轻量级开源的Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

    Dubbo致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案

dubbo官网: (http://dubbo.apache.org)

1.服务发现

    服务发现,即消费端自动发现服务地址列表的能力,是微服务框架需要具备的关键能力,借助于自动化服务发现,微服务之间可以无须感知对端部署位置与IP地址的情况下实现通信。

    实现服务发现的方式有多种,Dubbo提供的是一种Client-Based的服务发现机制,通常还需要部署额外的第三方注册中心组件来协调服务发现过程,常用的注册中心我们一般选择Zookeeper。

基于消费端的自动服务发现原理
在这里插入图片描述

角色说明:

  • 服务提供者(Provider):暴露服务的服务提供方,服务提供者在启动时,向注册中心注册自己提供的服务。

  • 服务消费者(Consumer):调用远程服务的服务消费方,服务消费者在启动时,向注册中心订阅自己所需的服务,服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。

  • 注册中心(Registry):注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者

  • 监控中心(Monitor):服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心

调用说明
调用关系说明

l 服务容器负责启动,加载,运行服务提供者。

l 服务提供者在启动时,向注册中心注册自己提供的服务。

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

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

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

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

服务发现的一个核心组件是注册中心,Proivider注册地址到注册中心,Consumer从注册中心读取和订阅Provider地址列表。启动服务发现时,我们要为Dubbo增加注册中心配置

Dubbo3和Dubbo2之间的服务发现的区别:

  • Dubbo3应用级服务发现,以应用力度组织地址数据
  • Dubbo2接口级服务发现,以接口粒度组织地址数据

Dubbo接口级

    RPC接口的信息融合在了地址发现过程中,而这部分信息是和具体的业务定义密切相关的。
在这里插入图片描述
Dubbo3应用级
   &enspj接入了云原生基础设施后,基础设施融入了微服务概念的抽象,容器化微服务被编排,调度的过程即完成了在基础设施层面的注册。基础设施承担了注册中心的责任,又完成了服务注册的动作,而“RPC接口”这部分的信息,由于与具体的业务相关,不可能也不适合被基础设施托管。
在这里插入图片描述

应用级服务发现的优势

  • 适配云原色微服务变革
  • 提升性能与可伸缩性

可以参考官方文档

    Dubbo3对于注册中心、订阅方的存储压力都是一个极大的释放。地址发现容量彻底与业务 RPC 定义解耦开来,整个集群的容量评估对运维来说将变得更加透明:部署多少台机器就会有多大负载,不会像 Dubbo2 一样, 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

2.协议

RPC的通信协议
    Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协议,这是 Dubbo 框架的原生协议。

    Dubbo3 也对众多第三方协议进行了集成, 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。

Triple 协议

    Triple是基于云原生基础设施的Dubbo新协议。

RPC协议的选择

协议是 RPC 的核心,它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外,通常还会包含额外控制数据,如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。

协议的内容包含三部分

  • 数据交换格式: 定义 RPC 的请求和响应对象在网络传输中的字节流内容,也叫作序列化方式
  • 协议结构: 定义包含字段列表和各字段语义以及不同字段的排列方式
  • 协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC 需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致,就会出现鸡同鸭讲,无法满足远程通信的需求。

RPC协议的设计主要
考虑以下方面:

  • 通用性: 统一的二进制格式,跨语言、跨平台、多传输层协议支持
  • 拓展性 协议增加字段、升级、支持用户扩展和附加业务元数据
  • 高性能:高性能能帮助我们更快的响应
  • 穿透性:能够被各种终端设备识别和转发

HTTP/1.1

    是构建于HTTP之上的远程调用解决方案,相比于直接构建于TCP传输层的私有RPC协议,能够更好的满足RPC调用需求,且HTTP协议几乎网络所有设备都支持,协议穿透性好。

存在的问题:

  • 一个链路上一次只有能一个等待的Requeat请求.
  • 使用头部传输格式,性能差
  • 无直接Server Push支持,需要使用Polling Long-Polling等变通模式

gRPC

    Google将gRPC直接定义在HTTP/2协议之上,协议简单,用户学习成本低,天然有server push/ 多路复用/流量控制能力,提供强大的统一跨语言能力,符合云原生的事实协议标准。


存在的问题:

  • 协议层缺少必要的统一定义,用户的可用性差。
  • 强绑定 protobuf 的序列化方式,需要较高的学习成本和改造成本。

Triple
    Triple协议兼容了gRPC,以HTTP2作为传输层构建的协议。

背景
    容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议( RESTFUL或其他基于 HTTP 的自定义协议)难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。

在这里插入图片描述

解决的问题:

  • 性能上: Triple 协议采取了 metadata 和 payload 分离的策略,这样就可以避免中间设备,如网关进行 payload 的解析和反序列化,从而降低响应时间。
  • 路由支持上,由于 metadata 支持用户添加自定义 header ,用户可以根据 header 更方便的划分集群或者进行路由,这样发布的时候切流灰度或容灾都有了更高的灵活性。
  • 安全性上,支持双向TLS认证(mTLS)等加密传输能力。
  • 易用性上,Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外,使用通用的方式支持了 Hessian / JSON 等其他序列化,能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言,修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可,改造成本几乎为 0。

特点和优势:

1.具备跨语言互通的能力,
2.提供更完善的请求模型
3.易扩展、穿透性高
4.多种序列化方式支持、平滑升级
5.支持 Java 用户无感知升级

3.流量管理

    通过路由规则,实现对流量分布的控制,流量管理的本质是请求根据制定好的路由规则分发到应用服务上,如下图所示:
在这里插入图片描述
说明

  • 路由规则可以有多个,不同的路由规则之间存在优先级。
  • 一个路由规则可以路由到多个不同的应用服务
  • 多个不同的路由规则可以路由到同一个应用服务。
  • 路由规则可以不路由到任何应用服务。
  • 应用服务可以是单个的实例,也可以是应用集群。

    Dubbo提供了支持mesh方式的流量管理策略,可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。

在这里插入图片描述

4.配置

描述Dubbo的动态配置能力,Dubbo配置分为:

  • 启动阶段配置项
    配置方式:
    1.Spring中的xml配置和注解配置
    2.SpringBoot的key-value属性配置
  • 服务治理准则
    主要作用是改变运行时服务的行为和选址逻辑,达到限流,权重配置等目的,包括覆盖规则、标签路由、条件路由。
  • 动态配置项
    一般用于控制动态开关
    Dubbo启动后监听动态配置项,当配置发生变化时,会自动进行相应的处理。

5.部署架构

    为了在分布式环境下实现各个微服务组件间的协作, Dubbo 定义了一些中心化组件

  • 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
  • 配置中心。
    存储 Dubbo 启动阶段的全局配置,保证配置的跨环境共享与全局一致性
    负责服务治理规则(路由规则、动态配置等)的存储与推送。
  • 元数据中心。
    接收 Provider 上报的服务接口元数据,为 Admin 等控制台提供运维能力(如服务测试、接口文档等)
    作为服务发现机制的补充,提供额外的接口/方法级别配置信息的同步能力,相当于注册中心的额外扩展

在这里插入图片描述
通常情况下,所有用户都会以独立的注册中心 开始 Dubbo 服务开发,而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

参考文档

6.拓展性

什么是可拓展性?

    可扩展性是一种设计理念,代表了我们对未来的一种预想,我们希望在现有的架构或设计基础上,当未来某些方面发生变化的时候,我们能够以最小的改动来适应这种变化。

可拓展性的优点

    模块之间解耦,它符合开闭原则,对扩展开放,对修改关闭。当系统增加新功能时,不需要对现有系统的结构和代码进行修改,仅仅新增一个扩展即可。

Dubbo的可拓展性:

  • 实现平等。
  • 每个拓展只封装一个变化因子,最大化复用。符合单一变量原则

Dubbo拓展加载流程:

在这里插入图片描述
说明:

  1. 读取并解析配置文件
  2. 缓存所有扩展实现
  3. 基于用户执行的扩展名,实例化对应的扩展实现
  4. 进行扩展实例属性的 IOC 注入以及实例化扩展的包装类,实现 AOP 特性

Dubbo可拓展方向:
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值