Apache Dubbo(开源RPC框架)

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

软件功能

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

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

　　2、智能负载均衡

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

　　3、服务自动注册与发现

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

　　4、高度可扩展能力

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

　　5、运行期流量调度

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

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

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

软件特色

　　启动时检查

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

　　集群容错

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

　　负载均衡

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

　　线程模型

　　配置 Dubbo 中的线程模型

　　直连提供者

　　Dubbo 中点对点的直连方式

　　只订阅

　　只订阅不注册

　　多协议

　　在 Dubbbo 中配置多协议

　　多注册中心

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

　　服务分组

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

　　静态服务

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

　　多版本

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

　　分组聚合

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

　　参数验证

　　在 Dubbo 中进行参数验证

　　结果缓存

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

　　使用泛化调用

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

　　Protobuf

　　使用 IDL 定义服务

　　GoogleProtobuf 对象泛化调用

　　对 Google Protobuf 对象进行泛化调用

　　实现泛化调用

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

　　回声测试

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

　　上下文信息

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

　　隐式参数

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

　　异步执行

　　Dubbo 服务提供方的异步执行

　　异步调用

　　在 Dubbo 中发起异步调用

　　本地调用

　　在 Dubbo 中进行本地调用

　　参数回调

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

　　事件通知

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

　　本地存根

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

　　本地伪装

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

使用说明

　　XML 配置

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

　　provider.xml 示例

　　consumer.xml示例

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

　　配置之间的关系

　　不同粒度配置的覆盖关系

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

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

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

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

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

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

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

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

　　动态配置中心

　　Dubbo 2.7 中的动态配置中心

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

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

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

　　启用动态配置，以 Zookeeper 为例

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

　　外部化配置

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

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

　　优先级

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

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

　　作用域

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

　　Zookeeper

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

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

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

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

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

　　Apollo

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

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

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

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

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

　　自己加载外部化配置

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

　　服务治理

　　Zookeeper

　　默认节点结构：

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

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

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

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

　　Apollo

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

　　属性配置

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

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

　　Dubbo 可以自动加载 classpath 根目录下的 dubbo.properties，但是你同样可以使用 JVM 参数来指定路径：-Ddubbo.properties.file=xxx.properties。

　　映射规则

　　可以将 xml 的 tag 名和属性名组合起来，用 ‘.’ 分隔。每行一个属性。

　　dubbo.application.name=foo 相当于

　　dubbo.registry.address=10.20.153.10:9090 相当于

　　如果在 xml 配置中有超过一个的 tag，那么你可以使用 ‘id’ 进行区分。如果你不指定 id，它将作用于所有 tag。

　　dubbo.protocol.rmi.port=1099 相当于

　　dubbo.registry.china.address=10.20.153.10:9090 相当于

　　如下，是一个典型的 dubbo.properties 配置样例。

　　重写与优先级

　　优先级从高到低：

　　JVM -D 参数：当你部署或者启动应用时，它可以轻易地重写配置，比如，改变 dubbo 协议端口；

　　XML：XML 中的当前配置会重写 dubbo.properties 中的；

　　Properties：默认配置，仅仅作用于以上两者没有配置时。

　　1、如果在 classpath 下有超过一个 dubbo.properties 文件，比如，两个 jar 包都各自包含了 dubbo.properties，dubbo 将随机选择一个加载，并且打印错误日志。

　　2、如果 id 没有在 protocol 中配置，将使用 name 作为默认属性。

　　自动加载环境变量

　　在 Dubbo 中自动加载环境变量

　　从 2.7.3 版本开始，Dubbo 会自动从约定 key 中读取配置，并将配置以 Key-Value 的形式写入到URL中。

　　支持的 key 有以下两个：

　　1、dubbo.labels，指定一些列配置到 URL 中的键值对，通常通过 JVM -D 或系统环境变量指定。

　　增加以下配置：

　　最终生成的 URL 会包含 tag1、tag2 两个 key: dubbo://xxx?tag1=value1&tag2=value2

　　2、dubbo.env.keys，指定环境变量 key 值，Dubbo 会尝试从环境变量加载每个 key

　　最终生成的 URL 会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: dubbo://xxx?DUBBO_TAG1=value1&DUBBO_TAG2=value2