Alibaba微服务技术系列「Dubbo3.0技术专题」总体技术体系介绍及技术指南（序章）

Posted 2021-08-25 李浩宇Alex

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Alibaba微服务技术系列「Dubbo3.0技术专题」总体技术体系介绍及技术指南（序章）相关的知识，希望对你有一定的参考价值。

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：
1. Dubbo 团队透露 Dubbo 3.0 宣布正式开工，参考：重大利好，Dubbo 3.0要来了。
2. 发布了 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&timestamp=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，看看具体有哪些新特性。