Apache Dubbo 官方版 v3.0

更新时间：2022-06-10 09:44:29

软件介绍

Apache Dubbo是一款RPC服务框架，可以用户建立分布式网站服务方案，让网站和通讯更加快速，降低网站负载，避免大量流的时候网站崩溃，软件基于JA开发，可以选择以 XML 配置的方式来配置你的Dubbo应用，可以选择以属配置的方式编辑你的应用，可以选择以API的方式配置应用，可以选择以注解配置的方式来配置您的Dubbo，软件提供的集群负载均衡策略，方便用户配置集群工作方案，新版修复对uilder的不正确处理会导致错误的L被错误地显示，增强为Apache许可证添加一个构建工具模块！

Apache Dubbo软件功能

1、面向接口代理的高能RPC调用

提供高能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

2、智能负载均衡

内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

3、服务自动注册与发现

支持多种注册中心服务，服务实例上下线实时感知。

4、高度可扩展能力

遵循微内核+插件的设计原则，所有核心能力如Ptocol、Transport、Sealization被设计为扩展点，平等对待内置实现和第三方实现。

5、运行期流量调度

内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

6、可视化的服务治理与运维

提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

Apache Dubbo软件特色

启动时

在启动时依赖的服务是否可用

集群容错

集群调用失败时，Dubbo 提供的容错方案

负载均衡

Dubbo 提供的集群负载均衡策略

线程模型

配置 Dubbo 中的线程模型

直连提供者

Dubbo 中点对点的直连方式

只订阅

只订阅不注册

多协议

在 Dubbbo 中配置多协议

多注册中心

在 Dubbo 中把同一个服务注册到多个注册中心上

服务分组

使用服务分组区分服务接口的不同实现

静态服务

将 Dubbo 服务标识为非动态管理模式

多版本

在 Dubbo 中为同一个服务配置多个版本

分组聚合

通过分组对结果进行聚合并返回聚合后的结果

参数验证

在 Dubbo 中进行参数验证

结果缓存

通过缓存结果加速访问速度

使用泛化调用

实现一个通用的服务测试框架，可通过 GenecService 调用所有服务实现

Ptobuf

使用 IDL 定义服务

GooglePtobuf 对象泛化调用

对 Google Ptobuf 对象进行泛化调用

实现泛化调用

实现一个通用的远程服务 Mock 框架，可通过实现 GenecService 接口处理所有服务请求

回声测试

通过回声测试检测 Dubbo 服务是否可用

上下文

通过上下文存放当前调用过程中所需的环境

隐式参数

通过 Dubbo 中的 Attachment 在服务消费方和提供方之间隐式传递参数

异步执行

Dubbo 服务提供方的异步执行

异步调用

在 Dubbo 中发起异步调用

本地调用

在 Dubbo 中进行本地调用

参数回调

通过参数回调从端调用客户端逻辑

事件

在调用之前、调用之后、出现异常时的时间

本地存根

在 Dubbo 中利用本地存根在客户端执行部分逻辑

本地伪装

如何在 Dubbo 中利用本地伪装实现服务降级

Apache Dubbo使用说明

XML 配置

以 XML 配置的方式来配置你的 Dubbo 应用

pvider.xml 示例

consumer.xml示例

所有标签都支持自定义参数，用于不同扩展点实现的特殊配置，如：

配置之间的关系

不同粒度配置的覆盖关系

以 timeout 为例，下图显示了配置的查找顺序，其它 retes, loadbalance, actives 等类似：

方法级优先，接口级次之，全局配置再次之。

如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过 L 经由注册中心传递给消费方。

（建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置）。

理论上 ReferenceConfig 中除了intece这一项，其他所有配置项都可以缺省不配置，框架会自动使用ConsumerConfig，ServiceConfig, PviderConfig等提供的缺省配置。

1、2.1.0 开始支持，注意声明：xmlns:p="http://www.spngframework.org/schema/p"

2、引用缺省是延迟初始化的，只有引用被注入到其它 Bean，或被 getBean() 获取，才会初始化。如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：dubbo:reference ... init="true" />

动态配置中心

Dubbo 2.7 中的动态配置中心

配置中心（v2.7.0）在 Dubbo 中承担两个职责：

1、外部化配置。启动配置的集中式存储（简单理解为 dubbo.pperties 的外部化存储）。

2、服务治理。服务治理规则的存储与。

启用动态配置，以 Zookeeper 为例

为了兼容 2.6.x 版本配置，在使用 Zookeeper 作为注册中心，且没有显示配置配置中心的情况下，Dubbo 框架会默认将此 Zookeeper 用作配置中心，但将只作服务治理用途。

外部化配置

外部化配置目的之一是实现配置的集中式管理，这部分业界已经有很多成熟的专业配置系统如 Apollo, Nacos 等，Dubbo 所做的主要是保证能配合这些系统正常工作。

外部化配置和其他本地配置在内容和格式上并无区别，可以简单理解为 dubbo.pperties 的外部化存储，配置中心更适合将一些公共配置如注册中心、元数据中心配置等取以便做集中管理。

优先级

外部化配置默认较本地配置有更高的优先级，因此这里配置的内容会覆盖本地配置值，关于各配置形式间的覆盖关系有单独一章说明，你也可通过以下选项调整配置中心的优先级：

-Ddubbo.config-center.highest-poty=false

作用域

外部化配置有全局和应用两个级别，全局配置是所有应用共享的，应用级配置是由每个应用自己且只对自身可见的。当前已支持的扩展实现有Zookeeper、Apollo

Zookeeper

默认所有的配置都存储在 /dubbo/config 节点，具体节点结构图如下：

ame，用于不同配置的环境隔离。

config，Dubbo约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。

dubbo/application，分别用来隔离全局配置、应用级别配置：dubbo是默认gup值，application对应应用名

dubbo.pperties，此节点的node value存储具体配置内容

Apollo

Apollo中的一个核心概念是命名空间 - name（和上面zookeeper的name概念不同），在这里全局和应用级别配置就是通过命名空间来区分的。

默认情况下，Dubbo会从名叫dubbo（由于 Apollo 不支持特殊后缀 .pperties ）的命名空间中读取全局配置（）

由于 Apollo 也默认将会在 dubbo name 中存储服务治理规则（如路由规则），建议通过单独配置 gup 将服务治理和配置文件托管分离开，以 XML 配置方式为例：

这里，服务治理规则将存储在 governance name，而配置文件将存储在 dubbo name，如下图所示：

关于文件配置托管，相当于是把 dubbo.pperties 配置文件的内容存储在了 Apollo 中，应用通过关联共享的 dubbo name 继承公共配置, 应用也可以按照 Apollo 的做法来覆盖个别配置项。

自己加载外部化配置

所谓 Dubbo 对配置中心的支持，本质上就是把 .pperties 从远程拉取到本地，和本地的配置做一次融合。理论上只要 Dubbo 框架能拿到需要的配置就可以正常的启动，它并不关心这些配置是自己加载到的还是应用直接塞给它的，所以Dubbo还提供了以下API，让用户将自己组织好的配置塞给 Dubbo 框架（配置加载的过程是用户要完成的），这样 Dubbo 框架就不再直接和 Apollo 或 Zookeeper 做读取配置交互。

服务治理

Zookeeper

默认节点结构：

name，用于不同配置的环境隔离。

config，Dubbo 约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。

dubbo，所有服务治理规则都是全局的，dubbo 为默认节点

configurators/tag-uter/condition-uter，不同的服务治理规则类型，node value 存储具体规则内容

Apollo

所有的服务治理规则都是全局的，默认从公共命名空间 dubbo 读取和订阅：

属配置

以属配置的方式来配置你的 Dubbo 应用

如果你的应用足够简单，例如，不需要多注册中心或多协议，并且需要在spng容器享配置，那么，我们可以直接使用 dubbo.pperties 作为默认配置。