- 简介RPC
- 远程方法调用 VS 本地方法调用
- Dubbo的定义
- 基本原理
- 核心功能
- 面向接口代理的高性能RPC调用
- 智能容错和负载均衡
- 服务自动注册和发现
- 高度可扩展能力
- 运行期流量调度
- 可视化的服务治理与运维
- 详细解释
- 服务超时
- 集群容错
- 服务降级
- 参数回调
- Dubbo中的REST
- 动态配置
- 在分布式计算，远程过程调用（Remote Procedure Call 缩写为RPC是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间的子程序。
- PRC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
- 如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作远程调用或远程方法调用。
对于Java程序员来说，RPC就是远程方法调用。
远程方法调用 VS 本地方法调用
本地方法调用指的是进程内部的方法调用，而远程方法调用指的是两个进程内的方法相互调用。
如果实现远程方法调用，基本是通过网络，通过传输数据来进行实现。
RPC over Http：基于http协议来传输数据
RPC over Tcp: 基于Tcp协议来传输数据
具体传输的数据，由RPC的双方来协商定义，基本包括：
- 调用的是哪个类或接口
- 调用的是哪个方法，方法名和方法参数类型
- 调用方法的入参
通过传输的数据我们可以看到RPC的自定义很高，各个公司内部都可以实现自己的一套RPC框架，而Dubbo就是阿里开源出来的一套RPC框架
Dubbo的定义Apache Dubbo是一款高性能、轻量级的开源Java 服务框架。
原来的解释是：Apache Dubbo是一款高性能、轻量级的开源Java RPC框架。
为什么会将RPC改为服务？
Dubbo一开始的定位是RPC,专注于两个服务之间的调用。但随着微服务的盛行，除了服务调用之外，Dubbo也在逐步的涉猎服务治理、服务监控、服务网关等，所以现在的Dubbo目标已经不止是RPC框架了，而是和Spring Cloud类似想成为一个服务框架。
- 注册中心
- 保存服务名与服务器地址映射关系
- 服务地址变动主动通知服务消费者
- 服务消费者
- 启动时根据接口名从注册中心获取服务地址并缓存
- 根据负载均衡策略筛选出一个服务器地址进行服务调用
- 服务提供者
- 提供服务的接口
- 提供实现类
- 注册服务（注册中心注册，本地注册）
- 暴露服务（启动Tomcat,NettyServer,从而接收以及处理请求）
- 监控中心
- 统计服务调用次数和调用时间等
提供高性能的基于代理的远程调用能力，服务以接口为粒度，以开发者屏蔽远程调用底层细节。
智能容错和负载均衡内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提供系统吞吐量
服务自动注册和发现支持多种注册中心服务，服务实例上下线实时感知。
高度可扩展能力遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
运行期流量调度内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
可视化的服务治理与运维提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。
消费者调用一个服务，分为三步：
- 消费者发送请求（网络传输）
- 服务端执行服务
- 服务端返回响应（网络传输）
如果在服务端和消费端只在其中一方配置了timeout：
- 表示消费端调用服务的超时时间，消费端如果超过时间还没有收到响应结果，则消费端会抛超时异常。 服务端不会抛异常。
- 服务端在执行服务后，会检查执行服务的时间，如果超过timeout,会打印一个超时日志。服务会正常的执行完。
如果在服务端和消费端各配了一个timeout,那就比较复杂了。假设：
- 服务执行为5s
- 消费端timeout=3s
- 服务端timeout=6s
那么消费端调用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）
服务消费者在调用某个服务时，这个服务有多个服务提供者，在经过负载均衡后选出其中一个服务提供者之后进行调用，但调用报错后，Dubbo所采取的后续处理策略。
服务降级服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。
集群容错和服务降级的区别在于：
- 集群容错是整个集群范围内的容错
- 服务降级是单个服务提供者的自身容错
首先，如果当前服务支持参数回调，意思就是：对于某个服务接口中的某个方法，如果想支持消费者在调用这个方法时能设置回调逻辑，那么该方法就需要提供一个入参用来表示回调逻辑。
因为Dubbo协议是基于长连接的，所以消费端在两次调用同一个方法时想指定不同的回调逻辑，那么就需要在调用时指定key进行区分。
注意Dubbo的REST也是Dubbo所支持的一种协议。
当我们用Dubbo提供了一个服务后，如果消费者没有使用Dubbo也想调用服务，那么这个时候我们就可以让我们的服务支持REST协议，这样消费者就可以通过REST形式调用我们的服务了。
如果某个服务只有REST协议可用，那么该服务必须用@Path注解定义访问路径
注意动态配置修改的是服务参数，并不能修改服务的协议、IP、PORT、VERSION、GROUP，因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。
感谢您的阅读~~
