Alibaba-技术专区-Dubbo3总体技术体系介绍及技术指南(序章)
Dubbo的背景介绍
Apache Dubbo 是一款微服务开发框架(是一款高性能、轻量级的开源 Java 服务框架),它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着,使用 Dubbo 开发的微服务,将具备相互之间的远程发现与通信能力, 同时利用 Dubbo 提供的丰富服务治理能力,可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的,用户几乎可以在任意功能点去定制自己的实现,以改变框架的默认行为来满足自己的业务需求。
Dubbo的功能特性
面向接口代理的高性能RPC调用;
服务自动注册与发现;
智能负载均衡策略;
高度可扩展能力;
运行期流量调度;
可视化的服务治理与运维;
Dubbo的框架结构
Dubbo的发展历程
2011/10/27: 阿里巴巴巴宣布 Dubbo 开源。
2012/10/23: 发布最后一个版本 2.5.3 并停止维护更新。
2017/07/31: 起死回生,官方宣布开启重新更新,并会得到重点维护,参考:Dubbo 宣布重新开始维护。
2017/09/07: 发布起死回生的第一个版本:dubbo-2.5.4。
2018/01/08:
Dubbo 团队透露 Dubbo 3.0 宣布正式开工,参考:重大利好,Dubbo 3.0要来了。
发布了 dubbo-2.6.0 版本,主要合并了由当当网开源的 dubbox 项目分支。PS:dubbo停止维护期间,当当网基于 dubbo 开源了dubbox。
2018/01/22: Dubbo Spring Boot 版正式发布:dubbo-spring-boot-starter v1.0.0 公测版。
2018/02/09: Dubbo 通过投票正式进入 Apache 基金会孵化器,更新了 Apache 官方域名,也不再仅限于 Java 语言。
2019/05/20: Apache 软件基金会宣布 Dubbo 正式毕业,成为 Apache 的顶级项目。
Dubbo3.0诞生归来
Dubbo3 基于 Dubbo2 演进而来,在保持原有核心功能特性的同时, Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配等几大方向上进行了全面升级。 以下文档都将基于 Dubbo3 展开。
Dubbo3.0扩展延伸
从功能上看,Dubbo3.完成后的功能将涵盖从开发人员直接接触的 API 层到底层传输的完整链路。
API层将包括基于IDL的完整数据交换格式打通,这会带来两方面的好处:
一是统一的 IDL 模型可以生成统一的 client stub 和 server stub,这些 stub 能直接进行非反射调用,会在性能上有很大的提升;
二是对异步和 streaming 的原生支持能够给用户更多的选项,根据不同的业务场景选择更方便的用法。
第二层是对于注册中心、元数据中心和配置中心的扩展。
- 注册中心和配置中心基本支持了所有业界主流的实现,元数据中心是 Dubbo 2.7 新抽象出的组件,负责元数据的存取。这里的元数据包括服务的调用配置,如超时时间,序列化方式,协议等,以及对服务方法签名的抽象,方便 Dubbo 实现跨框架和跨语言调用。
集群层是Dubbo的一个主要亮点,除了支持各种重试策略外,Dubbo 也提供了各种场景下的负载均衡器,比如随机和权重。值得一提的是,Dubbo3.0 将带来 pull-based 的自适应负载均衡,这将显著提升分布式集群的性能和效率。
再下一层是协议层,协议层是 RPC 框架的内核部分,一般分为应用层协议和传输层协议。应用层协议 Dubbo3.0 支持 GRPC / Redis / REST 等主流协议以及 Dubbo 原生的 Dubbo2.0 协议。
传输层支持 HTTP / HTTP2 和一些自定义的协议如 RSOCKET。序列化方面,Dubbo 除了支持 hessian 、Java 外,还支持 protobuf,这对于性能和跨语言都有着巨大的意义。
Maven 依赖
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo</artifactId>
<version>3.0.0</version>
</dependency>
Dubbo3 是在云原生背景下诞生的,使用Dubbo构建的微服务遵循云原生思想,能更好的复用底层云原生基础设施、贴合云原生微服务架构。
Dubbo 3.0.0 几乎兼容 2.7.x 所有行为。 因为,Dubbo3 是基于 Dubbo2 演进而来,在保持原有核心功能特性的同时, Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配等几大方向上进行了全面升级。
Dubbo3官方文档
Dubbo3核心功能
- 应用级服务发现机制;
- 同时 Dubbo 3.0.0 改变以前的接口级服务注册而是采用应用级服务注册,什么意思呢?比如在3.0.0版本前所有的服务都是以接口形式的元数据进行注册如下元数据:
dubbo://192.168.101.8:20880/com.example.demo.async.api.BookFacade?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.example.demo.async.api.BookFacade&metadata-type=remote&methods=queryByName,queryAll&pid=53639&release=3.0.0&side=provider×tamp=1624889509797
- 可以看到如果我们以接口级进行服务注册会存在大量的重复数据,这样就会导致注册中心数据与接口数量成正比,接口越多注册的元数据就越多。而如果我们以应用级服务注册会是怎样的?下面是应用级服务注册的共享元数据:
{
"name": "demo-provider",
"id": "192.168.101.8:20880",
"address": "192.168.101.8",
"port": 20880,
"sslPort": null,
"payload": {
"@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance",
"id": null,
"name": "demo-provider",
"metadata": {
"anyhost": "true",
"application": "demo-provider",
"deprecated": "false",
"dubbo": "2.0.2",
"dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
"dubbo.metadata-service.url-params": "{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"3.0.0\",\"port\":\"20880\",\"protocol\":\"dubbo\"}",
"dubbo.metadata.revision": "525892dddd25ea459ee539d0734b2f1a",
"dubbo.metadata.storage-type": "remote",
"dynamic": "true",
"generic": "false",
"interface": "com.example.demo.async.api.BookFacade",//多个服务接口只保存一个
"metadata-type": "remote",
"methods": "queryByName,queryAll",
"pid": "63941",
"release": "3.0.0",
"side": "provider",
"timestamp": "1624891074206"
}
},
"registrationTimeUTC": 1624891075236,
"serviceType": "DYNAMIC",
"uriSpec": null
}
从这些共享元数据可以看出应用级注册减少了大量重复的元数据,能最大幅度的减轻注册中心的存储、推送压力,进而减少 Dubbo 消费端的地址计算压力。集群规模也开始变得可预测、可评估(与 RPC 接口数量无关,只与实例部署规模相关)。
Dubbo3之前注册发现都是接口级别的。也就是同一个应用发布的多个服务会在注册中心注册多份数据,这些数据彼此独立,方便进行服务化改造和接口迁移。为什么要提出应用级注册发现呢?
主要有两个原因:
一是现有生态系统的互通,包括 Spring cloud 和 K8s 都是基于实例,也就是应用级别进行的注册发现,Dubbo 要成为连接异构系统最好用的 RPC 框架就需要支持实例粒度;
二是从规模上看,更大规模的增长会带来元数据的极速膨胀,这会给注册中心和客户端带来更大的内存占用。按照现有数据分析,如果升级到应用级注册发现,以平均发布 50 个服务的应用为例,将减少 60% 的内存占用和注册中心数据。以发布超过 10k 接口的平台型应用为例,这些数据可降低 90%。
如何保证平滑迁移,用户基于接口的配置怎么映射到应用上去。
抽象出了元数据中心来管理接口到应用的映射以及应用级的元数据。
- 在部署态,Dubbo 框架会自动上报这个关系到元数据中心。
- 运行态用户侧的配置和服务治理则通过这份映射关系重新将应用粒度映射到接口粒度。涉及到最核心的部分——选址也是分为两部分,应用级选址和接口级选址同时存在,方便进行服务治理。应用级注册发现带来的优化是十分显著的。
下一代RPC协议:Triple:Triple 协议是 Dubbo3 的主力协议,完整兼容 gRPC over HTTP/2,并在协议层面扩展了负载均衡和流量控制相关机制。
全新的路由规则;
显著提升性能;
Kubernetes 服务集成:
Dubbo3主要在云服务能力上做了新的能力提升。为什么这么说呢?因为作者之前在工作中集成 Kubernetes 时候服务注册中心这个组件能力就非常的尴尬,因为 Kubernetes 本身就提供了服务注册与发现能力,但是不能和 Dubbo 完美整合起来。
Dubbo3之前我们的实现方式可能就是在Kubernetes部署一个 zookeeper 服务集群来进行服务注册与发现。但这样的实现方式在云服务应用来说并不是太合适,这种服务注册和发现能力交给基础服务组件来实现比较合适。
- 一是需要对齐 K8s 的生命周期,能够让 Dubbo 服务原生的在 K8s 体系内注册和发现;
- 二是对 Mesh 的支持。上面在协议那里我们已经讲到,新协议通过使用 HTTP2 进行 header / payload 分离解决了网关需要解析完整协议的问题。另外一个问题则是服务注册发现和治理,注册发现需要 Dubbo 能够在 Mesh 的 xDS 体系内作为数据面打通。治理则需要将原有的规则逐步迁移至基于 YAML 的剔除 IP 依赖的规则。最终的形态将是原生的 Dubbo 服务能够和基于 thin SDK 的 Dubbo + Mesh 完美互通和进行服务治理。
Dubbo3.0原生微服务
承接上面对K8s整合之后,Dubbo3.0 -下一代云原生微服务。
一个新架构或新技术的出现一定会伴随特定的发展趋势。
目前我们可以看到的几个趋势是 K8s 成为资源调度的事实标准、Mesh 化成为主流以及规模上的急速增长。这些趋势的存在对 Dubbo 提出了更高的要求:
- 首先,用户如何在 K8s 上更方便的部署和调用 Dubbo 服务是必须要解决的问题,要解决这个问题,统一的协议和数据交换格式是必须前提;
- 其次,Mesh 化的流行带来了多元化问题,即原生 Dubbo 和 Mesh 化 Dubbo 如何共存,多语言的场景如何支持;
- 第三点,规模的增长会给整个 Dubbo 架构带来更大的挑战,无论是注册中心等组件,还是客户端,都会有更多的数据和调用量。如何在保持稳定的前提下,提供更高效的服务是 Dubbo 演进的重中之重。
- 这些云原生时代带来的挑战,促成了 Dubbo 的下一代定义。新协议、K8s 基础架构支持、多语言支持和规模化支持四个子项目共同组成了 Dubbo3.0 。下面我们将走进 Dubbo3.0,看看具体有哪些新特性。
Dubbo3扩展分离
Dubbo 核心不再提供第三方 SDK 扩展,需要通过 dubbo-spi-extensions 项目来支持。
Dubbo3多样化注册
Zookeeper 作为注册中心、元数据报告、配置中心;
Nacos 作为注册中心、元数据报告、配置中心;
Kubernetes 作为注册中心;
Redis 作为元数据报告;
Apollo 作为配置中心;
Hessian2 和 jdk 作为默认序列化器;
Triple 协议支持 Protobuf;
Dubbo3的升级提醒
基于 Spring 的相关配置列表可能会发生变更,请留言官方升级文档;
为了高度兼容性,Dubbo 3 早期版本会默认开启多重注册,多重订阅;
Dubbo3.0柔性增强
柔性增强要解决的问题有两个:
- 一是在节点异常的情况下,分布式服务能够保持稳定,不出现雪崩等问题;
- 二是对于大规模的应用,能够以最佳态运行,提供较高的吞吐量和性能。
从方法上看,Dubbo3.0 的柔性增强会以面向失败设计为理念,提供包括精准容量评估、自适应限流、自适应负载均衡的支持,自底向上的分步构建大规模可靠应用。从单一服务的视角看,服务是压不垮的,稳定的。
从分布式视角看,复杂的拓扑不会带来性能的下降,分布式负载均衡能够以最优的方式动态分配流量,保证异构系统能够根据运行时的准确服务容量合理分配请求,从而达到性能最优。
Dubbo3代表下一代RPC协议
Dubbo2.x的协议报文头
大家可以看到,这是 Dubbo2.0 的协议。从功能上看, Dubbo2.0 提供了 RPC 的核心语义,包括协议头、标志位、请求 ID 以及请求/响应数据。在云原生时代,2.0 协议主要面临两个挑战:
一是生态不互通,用户很难直接理解二进制的协议;
二是对 Mesh 等网关型组件不够友好,需要完整的解析协议才能获取到所需要的调用元数据,如一些 RPC 上下文,从性能到易用性方面都会面临挑战。
Dubbo3的协议报文头
首先,协议需要解决跨语言互通的问题,传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式;
其次,协议应该提供更完善的请求模型,除了 Request/Response 模型,还应该支持 Streaming 和 Bidirectional;
再次,在性能上,新的协议应该保留 request Id 机制,以避免 HOL 带来的性能损耗;
最后,新协议应该易扩展,包括但不限于 Tracing/ Monitoring 等支持,也应该能被各层设备识别,降低用户理解难度。
基于这些需求,HTTP2/protobuf 的组合是最符合的。提到这两个,大家可能很容易想到 GRPC 协议。那新一代的协议和 GRPC 的关系是什么呢?
首先,Dubbo 新协议是基于 GRPC 扩展的协议,这也保证了在生态系统上新协议和 GRPC 是能够互通和共享的;
其次,在这个基础上,Dubbo 新协议将更原生地支持 Dubbo 的服务治理,提供更大的灵活性;
在序列化方面,由于目前大多数应用方还没有使用 Protobuf ,所以新协议会在序列化方面给予足够的支持,平滑的适配现有序列化,方便迁移到 Protobuf;
在请求模型上,新协议将原生支持 Reactive,这也是 GRPC 协议所不具备的。
Dubbo3发展路线
Alibaba-技术专区-Dubbo3总体技术体系介绍及技术指南(序章)的更多相关文章
- Alibaba-技术专区-Dubbo3总体技术体系介绍及技术指南(目录)
Dubbo3开题简介 如开篇所述,Dubbo 提供了构建云原生微服务业务的一站式解决方案,可以使用 Dubbo 快速定义并发布微服务组 件,同时基于 Dubbo 开箱即用的丰富特性及超强的扩展能力,构 ...
- JAVAEE——淘淘商城第一天:电商行业的背景和技术特点,商城的介绍、技术的选型、系统架构和工程搭建
1. 学习计划 1.电商行业的背景. 2.电商行业的技术特点 3.商城的介绍 a) 常用的名词介绍 b) 系统功能介绍 4.淘淘商城的系统架构 a) 传统架构 b) 分布式架构 c) 基于服务的架构 ...
- spring框架:(一) 技术说明(技术介绍,技术优势以及发展史等)
一.技术说明(技术介绍,技术优势以及发展史等) 1.1.什么是spring 1.2.spring由来(发展历程) 1.3.spring核心 1.4.spring优点 1.5.spring体系结构 1. ...
- ar技术序章-SDK介绍和选择
转自: http://blog.csdn.net/kun1234567/article/details/10402535 ar技术序章-SDK介绍和选择 分类: Augmented Reality20 ...
- Redis基础知识补充及持久化、备份介绍(二)--技术流ken
Redis知识补充 在上一篇博客<Redis基础认识及常用命令使用(一)--技术流ken>中已经介绍了redis的一些基础知识,以及常用命令的使用,本篇博客将补充一些基础知识以及redis ...
- 腾讯技术分享:微信小程序音视频技术背后的故事
1.引言 微信小程序自2017年1月9日正式对外公布以来,越来越受到关注和重视,小程序上的各种技术体验也越来越丰富.而音视频作为高速移动网络时代下增长最快的应用形式之一,在微信小程序中也当然不能错过. ...
- 关于华为高斯数据库 GaussDB 版本及认证体系介绍
目录 你需要知道的 技术有国界 从它的名称说起 你听到过的版本 你听到过的流言蜚语 各个版本的区别 版本未来名称 华为 GaussDB 认证体系介绍 GaussDB 其他资料相关链接 你需要知道的 任 ...
- C蛮的全栈之路-序章 技术栈选择与全栈工程师
目录 C蛮的全栈之路-序章 技术栈选择与全栈工程师C蛮的全栈之路-node篇(一) 环境布置C蛮的全栈之路-node篇(二) 实战一:自动发博客 博主背景 985院校毕业,至今十年C++开发工作经验, ...
- 音视频编解码技术(二):AAC 音频编码技术
一.AAC编码概述 AAC是高级音频编码(Advanced Audio Coding)的缩写,出现于1997年,最初是基于MPEG-2的音频编码技术,目的是取代MP3格式.2000年,MPEG-4标准 ...
随机推荐
- 4、saltstack的使用
官方文档地址:http://repo.saltstack.com/#rhel 4.1.saltstatck介绍: 用户要一致,这里使用的是root用户: 用于批量管理成百上千的服务器: 并行的分发,使 ...
- zset如何解决内部链表查找效率低下
zset作为有序集合,内部基于跳表或者说索引的方式实现了数据的快速查找.解决了链表查询效率低下的痛点 前言 紧接前文我们学习了Redis中Hash结构.在里面我们梳理了字典这个重要的内部结构并分析了h ...
- Nginx:Nginx配置文件详解
Nginx是一款面向性能设计的HTTP服务器,相较于Apache.lighttpd具有占有内存少,稳定性高等优势. 如下是Nginx的配置详解: ######Nginx配置文件nginx.conf中文 ...
- weblogic项目转为tomcat之后出现的问题
解决java - JAX-WS和版本冲突 itPublisher分享于2017-03-19 推荐:JWS,JAX-WS,JAX-RS,REST,Restlet,SOAP(JAVA Web Servic ...
- 基于Ryu的流量采集代码实现
1 from __future__ import division 2 import time 3 import math 4 import xlwt 5 from ryu.controller im ...
- golang开发:Error的使用
Error是Go语言开发中最基础也是最重要的部分,跟其他语言的try catch的作用基本一致,想想在PHP JAVA开发中,try catch 不会使用,或者使用不灵活,就无法感知到程序运行中出现了 ...
- c语言:putchar
函数:1.C语言是一门函数语言,由多个函数组成,至少有一个主函数.2.主函数的写法:下面四种写法都正确 main() main(void) int main() int main(void):int表 ...
- C语言:fopen函数
在C语言中,操作文件之前必须先打开文件:所谓"打开文件",就是让程序和文件建立连接的过程.打开文件之后,程序可以得到文件的相关信息,例如大小.类型.权限.创建者.更新时间等.在后续 ...
- Appearance-Based Loop Closure Detection for Online Large-Scale and Long-Term Operation
Abstract: 本文提出一种用于大规模的长期回环检测,基于一种内存管理方法:限制用于回环检测的位置数目,以满足实时性要求. introduction: 大场景存在的最关键问题:随着场景增大,回环检 ...
- python基础之面向对象OOP
#类(面向对象) PageObject设计模式 unittest 知识体系#函数式编程import datetimebook_info = { "title":"Pyth ...