Dubbo简介
Apache Dubbo是一款RPC服务开发框架，那何为RPC呢？全称为Remote Procedure Call，翻译过来就是远程过程调用。
使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。
1，什么是dubbo
阿里巴巴开发的云原生微服务架构框架，类似于springcloud，两者之间各有优势。那什么又是云原生？很早之前就已经提出了云原生的思想，在计算机领域中，思想重要，技术的变革，一定是思想先行。云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
Dubbo开发相较于Springcloud具有一些优势：
开箱即用
- 易用性高，如 Java 版本的面向接口代理特性能实现本地透明调用
- 功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力
面向超大规模微服务集群设计
- 极致性能，高性能的 RPC 通信协议设计与实现
- 横向可扩展，轻松支持百万规模集群实例的地址发现与流量治理
高度可扩展
- 调用过程中对流量及协议的拦截扩展，如 Filter、Router、LB 等
- 微服务治理组件扩展，如 Registry、Config Center、Metadata Center 等
企业级微服务治理能力
- 国内共有云厂商支持的事实标准服务框架
2，Dubbo的一些概念
RPC通信
在Dubbo3中，RPC通信主要是使用Triple协议，Triple协议构建于HTTP/2协议上，兼容gRPC（gRPC协议是Google开发的基于HTPP/2和protobuf的RPC协议框架），提供提供 Request Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型；从 Triple 协议开始，Dubbo 还支持基于 IDL 的服务定义。
此外，Dubbo 还集成了业界主流的大部分协议，使得用户可以在 Dubbo 框架范围内使用这些通信协议，为用户提供了统一的编程模型与服务治理模型，这些协议包括 rest、hessian2、jsonrpc、thrift 等，注意不同语言 SDK 实现支持的范围会有一些差异。
服务发现
服务发现，是消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间在无需感知对端部署位置与IP地址的情况下实现通信。
实现的方式有多种，一种是Dubbo提供的Client-Based服务发现机制，同时也需要第三方注册中心来协调服务发现过程，比如Nacos/Zookeeper等。
基本原理图：
流量治理
Dubbo2开始，Dubbo就提供了丰富的服务治理规则，包括路由规则/动态配置等。
一方面 Dubbo3 正在通过对接 xDS 对接到时下流行的 Mesh 产品如 Istio 中所使用的以 VirtualService、DestinationRule 为代表的治理规则，另一方面 Dubbo 正寻求设计一套自有规则以实现在不通部署场景下的流量治理，以及灵活的治理能力。
Dubbo Mesh
Mesh网络可以理解为WiFi路由器覆盖不到一些死角，可以在死角覆盖得到的地方，放一台中继WIFI，形成MESH网络，就可以覆盖到死角。
Dubbo Mesh 的目标是提供适应 Dubbo 体系的完整 Mesh 解决方案，包含定制化控制面（Control Plane）、定制化数据面解决方案。Dubbo 控制面基于业界主流 Istio 扩展，支持更丰富的流量治理规则、Dubbo应用级服务发现模型等，Dubbo 数据面可以采用 Envoy Sidecar，即实现 Dubbo SDK + Envoy 的部署方案，也可以采用 Dubbo Proxyless 模式，直接实现 Dubbo 与控制面的通信。
3，Dubbo 架构图
整体上来看，Dubbo首先是一款RPC框架，用户在使用 Dubbo 时首先需要定义好 Dubbo 服务；其次，是在将 Dubbo 服务部署上线之后，依赖 Dubbo 的应用层通信协议实现数据交换，Dubbo 所传输的数据都要经过序列化，而这里的序列化协议是完全可扩展的。 使用 Dubbo 的第一步就是定义 Dubbo 服务，服务在 Dubbo 中的定义就是完成业务功能的一组方法的集合，可以选择使用与某种语言绑定的方式定义，如在 Java 中 Dubbo 服务就是有一组方法的 Interface 接口，也可以使用语言中立的 Protobuf Buffers IDL 定义服务。
定义好服务之后，服务端（Provider）需要提供服务的具体实现，并将其声明为 Dubbo 服务，而站在服务消费方（Consumer）的视角，通过调用 Dubbo 框架提供的 API 可以获得一个服务代理（stub）对象，然后就可以像使用本地服务一样对服务方法发起调用了。
在消费端对服务方法发起调用后，Dubbo 框架负责将请求发送到部署在远端机器上的服务提供方，提供方收到请求后会调用服务的实现类，之后将处理结果返回给消费端，这样就完成了一次完整的服务调用。如图中的 Request、Response 数据流程所示。
需要注意一点，在Dubbo中，服务指的是RPC粒度的，和读者印象中的泛指的功能型服务不是同一概念。
在分布式系统中，服务越来越多，应用之间的部署越来越繁杂，用户作为RPC的消费方，如何动态知道服务提供方地址，因此Dubbo引入了注册中心来协调提供方和消费方的地址。提供者启动之后向注册中心注册自身地址，消费方通过拉取或订阅注册中心特定节点，动态的感知提供方地址列表的变化。
注册中心可以使用：
- 如 Nacos、Zookeeper、Consul、Etcd 等。
- 将服务的组织与注册交给底层容器平台，如 Kubernetes，这可以理解为更加云原生的使用方式。
Dubbo的部署架构图：
Dubbo微服务组件包含三个中心组件：
- 注册中心，协调Consumer与Provider之间的地址与发现
配置中心
- 存储Dubbo启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- 负责服务治理规则（路由规则/动态配置等）的存储与推送
元数据中心
- 接收Provider上报的服务接口元数据，为Admin等控制台提供运维能力（如服务测试/接口文档等）
- 也作为注册中心的额外扩展，作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力
注册中心
不依赖于配置中心和元数据中心，主要承载的作用是服务注册和服务发现的职责，Dubbo支持接口级别和应用级别的两种粒度的服务发现和服务注册。
如果Dubbo仅仅是使用RPC直连服务，可以不部署注册中心。在接口或者应用级别，可以选择部署对应的注册中心。在Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo + Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。
metadata(元数据中心)
- 对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 —— 实例列表”结构的数据组织形式，不再是以往的“接口 —— 实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
- 为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。
如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。
元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：
配置中心
整个部署架构中，整个集群内实例（无论是Provider还是Consumer）都会共享该配置中心集群中的配置。
三大中心不一定是Dubbo应用服务必须使用的，但是如果集成了三大部署中心，还是会遇到可用性问题，比如多个注册中心，多个配置中心，多个元数据中心，系统该如何运行。
Dubbo对三大中心都支持了Multiple模式：
- 多注册中心：Dubbo 支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，比如可以注册到ZK集群和Nacos集群中，Consumer也能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。
- 多配置中心：Dubbo支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。
- 多元数据中心：Dubbo 支持多元数据中心：用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。
如遇到多个注册中心的话，部署架构如下：
机房A，机房B，两个Registry，Provider A会通过Dubbo SDK把地址注册到Registry A，Consumer A会和注册中心A进行一个互相订阅地址。机房B原理和机房A原理一样。机房AB中的注册中心会进行数据同步，这样机房A的consumer A也可以看作和机房B的Registry进行订阅地址同步。
4，Dubbo可扩展性
为什么要在系统中强调可扩展性呢？一个很大的原因是，比如一个系统设计好之后，后期又需要加入一些功能代码或者插件，如何最小化改变原有代码加入功能代码或者插件，这个就是扩展性，Dubbo在架构时期也一直重视可扩展性。
在市面上，有成熟的可扩展技术，比如SPring的IOC容器，或者是Factory，Dubbo在设计之初，不想强依赖于Spring的IOC，又不想大费周章开发出来一个IOC容器，因此使用了最简单的Factory。
Dubbo扩展加载流程如图：
主要步骤为 4 个：
- 读取并解析配置文件
- 缓存所有扩展实现
- 基于用户执行的扩展名，实例化对应的扩展实现
进行扩展实例属性的 IOC 注入以及实例化扩展的包装类，实现 AOP 特性
欢迎关注我的公众号：我只是个码字的
本文由博客一文多发平台 OpenWrite 发布！