RPC的概念：

RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

RPC的原理图：

由RPC的原理图可知RPC两个核心模块是通讯和序列化。通讯和序列化的效率决定了RPC框架的效率。

Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

Dubbo的几个重要角色：

服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。

  服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

  注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者

    监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

Dubbo的工作原理：

• 调用关系说明

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

1.在incubator-dubbo-ops-master\dubbo-admin\src\main\resources下修改applicatipn.propertis,将其修改为

dubbo.registry.address=zookeeper://47.101.47.253:2181

2.dubbo管理控制台

进入dubbo-admin，用命令mvn clean package将其打成一个jar包，并运行

http://47.101.47.253:7001/   默认账号和密码都是root

------------

dubbo配置

SpringBoot整合dubbo。

1、引入spring-boot-starter以及dubbo和curator的依赖

<dependency>

    <groupId>com.alibaba.boot</groupId>

    <artifactId>dubbo-spring-boot-starter</artifactId>

    <version>0.2.0</version>

</dependency>

注意starter版本适配：

2、配置application.properties

提供者配置：
dubbo.application.name=
dubbo.registry.protocol=zookeeper
dubbo.registry.address=
dubbo.scan.base-package=
dubbo.protocol.name=dubbo
application.name就是服务名，不能跟别的dubbo提供端重复
registry.protocol 是指定注册中心协议
registry.address 是注册中心的地址加端口号
protocol.name 是分布式固定是dubbo,不要改。
base-package  注解方式要扫描的包
消费者配置：
dubbo.application.name=
dubbo.registry.protocol=zookeeper
dubbo.registry.address=
dubbo.scan.base-package=
dubbo.protocol.name=dubbo

3、dubbo注解

【如果没有在配置中写dubbo.scan.base-package,还需要使用@EnableDubbo注解】

@Service。在服务提供者上加此注解，与spring的@Service重名。spring的可用@component代替此功能。

@Reference  在服务服务消费者上加此注解。

二、dubbo配置

0、配置原则

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

XML 次之，如果在 XML(在springboot中即application）中有配置，则 dubbo.properties 中的相应配置项无效。

Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

1.服务存在检查

启动时检查提供者是否存在，true报错，false忽略

<dubbo:consumer check="false" ></dubbo:consumer>

2、重试次数

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。不设置的话默认值为2，设置为0代表不重试。一般在查询、删除、修改等幂等操作可设置超时重试，在新增这种非幂等的条件下不能设置重试。

重试次数配置如下：

<dubbo:service retries="2" />

或

<dubbo:reference retries="2" />

或

<dubbo:reference>

    <dubbo:method name="findFoo" retries="2" />

</dubbo:reference>

3、超时时间

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。默认值为1000ms

1、Dubbo消费

全局超时配置

<dubbo:consumer timeout="5000" />

指定接口以及特定方法超时配置

<dubbo:reference interface="com.foo.BarService" timeout="2000">

    <dubbo:method name="sayHello" timeout="3000" />

</dubbo:reference>

2、Dubbo服务端

全局超时配置

<dubbo:provider timeout="5000" />

指定接口以及特定方法超时配置

<dubbo:provider interface="com.foo.BarService" timeout="2000">

    <dubbo:method name="sayHello" timeout="3000" />

</dubbo:provider>

超时时间和重试次数一般会同步出现。

3、配置原则

dubbo推荐在Provider上尽量多配置Consumer端属性：

1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

配置的覆盖规则：

1) 方法级配置优先级 >  接口级别   > 全局配置，即小Scope优先

2) Consumer端配置 优于 Provider配置。注意：只有在同一级别下，consumer配置才优先于cosumer。

举个例子：比如Provider设置了方法级的超时时间为1000.  此方法的执行需要3S。consumer接口级别设置的超时时间为5000.那么最后会超时。因为方法级别的provider的优先级 > consumer接口。具体的优先级顺序如下图从高往低。

4、版本号

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本

再将所有消费者升级为新版本

然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
新版本服务提供者配置：

<dubbo:service interface="com.foo.BarService" version="2.0.0" />
老版本服务消费者配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
新版本服务消费者配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

如果不需要区分版本，可以按照以下的方式配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

dubbo的本地存根（Stub）

springboot在@service和@Refernce中只能控制接口级别的配置，想要在springBoot中实现方法级别的配置，需要通过

@ImportResource导入dubbo的配置文件。

springboot与dubbo整合的三种方式

dubbo的高可用

zookeeper注册中心宕机，还可以消费dubbo暴露的服务。

原因：

1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

dubbo直连

    <dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" version="1.0.0" url="dubbo://127.0.0.1:20882"></dubbo:reference>

通过此方式可以直接指定url。

在springboot中

@Reference(url=  )

dubbo的负载均衡

dubbo高可用：服务降级

dubbo容错

dubbo集群容错策略

1）failover cluster模式

失败自动切换，自动重试其他机器，默认就是这个，常见于读操作

1. failfast cluster模式

一次调用失败就立即失败，常见于写操作

3）failsafe cluster模式

出现异常时忽略掉，常用于不重要的接口调用，比如记录日志

4）failbackc cluster模式

失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种

5）forking cluster

并行调用多个provider，只要一个成功就立即返回

6）broadcacst cluster

逐个调用所有的provider

dubbo支持不同的通信协议

1）dubbo协议  dubbo://192.168.0.1:20188

默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议

适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高

为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就100个连接。然后后面直接基于长连接NIO异步通信，可以支撑高并发请求。否则如果上亿次请求每次都是短连接的话，服务提供者会扛不住。

而且因为走的是单一长连接，所以传输数据量太大的话，会导致并发能力降低。所以一般建议是传输数据量很小，支撑高并发访问。

2）rmi协议

走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用

3）hessian协议

走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用

4）http协议

走json序列化

5）webservice

走SOAP文本序列化

(2）dubbo支持的序列化协议

所以dubbo实际基于不同的通信协议，支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。但是hessian是其默认的序列化协议。