关键词:
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.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 3.0.0 改变以前的接口级服务注册而是采用应用级服务注册,什么意思呢?比如在3.0.0版本前所有的服务都是以接口形式的元数据进行注册如下元数据:
-
如何保证平滑迁移,用户基于接口的配置怎么映射到应用上去。
- 抽象出了元数据中心来管理接口到应用的映射以及应用级的元数据。
- 在部署态,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扩展分离
Dubbo3多样化注册
-
Zookeeper 作为注册中心、元数据报告、配置中心;
-
Nacos 作为注册中心、元数据报告、配置中心;
-
Kubernetes 作为注册中心;
-
Redis 作为元数据报告;
-
Apollo 作为配置中心;
-
Hessian2 和 jdk 作为默认序列化器;
- Triple 协议支持 Protobuf;
Dubbo3的升级提醒
-
基于 Spring 的相关配置列表可能会发生变更,请留言官方升级文档;
- 为了高度兼容性,Dubbo 3 早期版本会默认开启多重注册,多重订阅;
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发展路线
在dubbo3.0上服务治理的实践
...; Dubbo3.0是在云原生背景下诞生的,使用Dubbo构建的微服务遵循云原生思想,能更好的复用底层云原生基础设施、贴合云原生微服务架构。Dubbo3.0介绍作者|十眠自从ApacheDubbo在2011年开源以来,经过多年一众大规模互联... 查看详情
springcloud系列springcloud概述及微服务技术栈的使用(代码片段)
SpringCloud概述及微服务技术栈的使用1、SpringCloud的简介1.1、SpringCloud中的五大核心组件1.2、SpringCloud的架构1.3、微服务与微服务架构1.4、微服务技术栈概括1.5、为什么选择SpringCloud作为微服务架构?1.6、SpringCloud与SpringBoot的关... 查看详情
阿里云首发dubbo3.0+nacos2.0
简介:2021.9.1,阿里云微服务引擎(MSE)支持Dubbo3.0+Nacos2.0,扩展性提升10倍,支持服务网格生态,标准、灵活、精准的控制流量,提升系统整体可用性。阿里云微服务引擎(MSE)支持Dubbo3... 查看详情
aibabelx-shop大型微服务架构系列实战之技术选型
...项目涉及编程语言java,scala,python,涉及的技术如下:1.微服务架构:springbootspringcloudmybatisplusshiro2.全文检索技术solr3.日志系统技术elk4.消息中间件kafka5.数据库技术mysqlredismongoDBmycat6.缓存技术redismemcache7.大数据系列技术hadoophbasehivefl... 查看详情
微服务-架构选型记录2022年微服务技术架构选型
...栈套用互联网上的一句话,在java领域里面躲不过去的alibaba,所以本次微服务架构选型还是基于SpringCloudAlibaba做为基础。在SpringCloud众多的实现方案中,SpringCloudAlibaba凭借其支持组件最多,方案最完善,在SpringC... 查看详情
alibaba-技术专区-开源项目之nacos功能特性(代码片段)
...o;云原生(CloudNative)”的新概念粉墨登场。 SpringCloudAlibaba就是其中之一。 这个概念的一个核心价值就是:平滑上云,赋能运维。最明显的业务表象就是,会提供一套OpenAPI,甚至是贴心的提供一个可视化控制台,傻瓜式... 查看详情
阿里集团业务驱动的升级——dubbo3.0的演进思路
...0年底提出了“三位一体”理念,目标是希望将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系,令技术的价值可以达到最大化。Dubbo3.0作为三位一体架构的首推方案,在集团内被寄予了厚望。它完美... 查看详情
微服务
1、微服务是分布式架构的一种。 2、微服务技术栈 然后利用Jenkins对一系列微服务进行自动化编译,接着利用Docker进行打包,形成镜像,最后用Kubernetes、RANCHER等技术进行自动化部署。 SpringCloud只是微服务中... 查看详情
阿里集团业务驱动的升级——聊一聊dubbo3.0的演进思路
...0年底提出了“三位一体”理念,目标是希望将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系,令技术的价值可以达到最大化。Dubbo3.0作为三位一体架构的首推方案,在集团内被寄予了厚望。它完美... 查看详情
深入浅出springcloud原理及实战「springcloud-alibaba系列」微服务模式搭建系统基础架构实战指南及版本规划踩坑分析
前提介绍SpringCloud-Alibaba致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用服务的必需组件,方便开发者通过SpringCloud编程模型轻松使用这些组件来开发分布式应用服务。依托SpringCloudAlibaba,您只需要... 查看详情
技术解析系列|pouchcontainer支持lxcfs实现高可靠容器隔离
...和原理,对LXCFS感兴趣的同学不要错过引言PouchContainer是Alibaba开源的一款容器运行时产品,当前最新版本是0.3.0,代码地址位于:https://github.com/alibaba/pou 查看详情
云计算技术系列文章
目录文章目录目录云计算云原生云原生思想容器技术Dockercontainerd微服务架构APIGWServiceCombETCDDevOps自动化运维监控告警日志审计CI/CDServiceMeshServerlessDDDOpenShiftPaaSKubernetesCaaS 查看详情
之四-总结
...虑的因素之一,它通常是指,通过设计减少系统不能提供服务 查看详情
quarkus技术系列「云原生架构基建」打造基于quarkus的云原生微服务框架实践(代码片段)
...c;我们的分享主题是“如何打造一个基于Quarkus的云原生微服务架构”,无论你之前是否了解或者熟悉Quarkus,希望通过今天的技术分享可以让你认识和知道Quarkus。进入前奏:好了,我们废话不多说,进入主题... 查看详情
云原生技术系列:深入浅出了解kubernetes
...业深度实践Kubernetes后的一些体会:作为一个有过数年微服务编写、运维经历的工程师,我认为使用Kubernetes可以最大化增益微服务的可靠性及服务治理工作。作为一个有过数年在团队提倡和推行DevOps持续交付理念的技术管理者,... 查看详情
技术解析系列|pouchcontainer支持lxcfs实现高可靠容器隔离
...和原理,对LXCFS感兴趣的同学不要错过引言PouchContainer是Alibaba开源的一款容器运行时产品,当前最新版本是0.3.0,代码地址位于:https://github.com/alibaba/pouch。PouchContainer从设计之初即支持LXCFS,实现高可靠容 查看详情
《java生态圈技术总结》之微服务架构蓝图总览
目录导航一、微服务定义1.1定义一1.2定义二二、微服务利弊2.1优点2.2缺点三、微服务的适用性3.1康威法则3.2生产力3.3架构演进四、服务分层五、服务注册发现六、微服务网关七、微服务配置中心八、微服务通信九、服务监控9.1监... 查看详情
【springcloud-alibaba系列教程】13.gateway网关结合sa-token进行登录鉴权
参考技术A在介绍【SpringCloud-Alibaba系列教程】10.gateway网关的时候文章末尾简单说了一下实现的鉴权功能,本文结合比较火的sa-token权限框架,进行整合,实现登录逻辑。看到本文,建议按照发文顺序阅读,方便理解我写的部分以... 查看详情