Protocol 还有一个实现分支是 AbstractProxyProtocol，如下图所示：
创新互联公司自2013年创立以来，先为来凤等服务建站，来凤等地企业，进行企业商务咨询服务。为来凤企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
从图中我们可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等协议对应的 Protocol 实现，都是继承自 AbstractProxyProtocol 抽象类。
目前互联网的技术栈百花齐放，很多公司会使用 Node.js、Python、Rails、Go 等语言来开发 一些 Web 端应用，同时又有很多服务会使用 Java 技术栈实现，这就出现了大量的跨语言调用的需求。Dubbo 作为一个 RPC 框架，自然也希望能实现这种跨语言的调用，目前 Dubbo 中使用“HTTP 协议 + JSON-RPC”的方式来达到这一目的，其中 HTTP 协议和 JSON 都是天然跨语言的标准，在各种语言中都有成熟的类库。
下面就重点来分析 Dubbo 对 HTTP 协议的支持。首先，会介绍 JSON-RPC 的基础，并通过一个示例，快速入门，然后介绍 Dubbo 中 HttpProtocol 的具体实现，也就是如何将 HTTP 协议与 JSON-RPC 结合使用，实现跨语言调用的效果。
Dubbo 中支持的 HTTP 协议实际上使用的是 JSON-RPC 协议。
JSON-RPC 是基于 JSON 的跨语言远程调用协议。Dubbo 中的 dubbo-rpc-xml、dubbo-rpc-webservice 等模块支持的 XML-RPC、WebService 等协议与 JSON-RPC 一样，都是基于文本的协议，只不过 JSON 的格式比 XML、WebService 等格式更加简洁、紧凑。与 Dubbo 协议、Hessian 协议等二进制协议相比，JSON-RPC 更便于调试和实现，可见 JSON-RPC 协议还是一款非常优秀的远程调用协议。
在 Java 体系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身体积小巧，使用方便，既可以独立使用，也可以与 Spring 无缝集合，非常适合基于 Spring 的项目。
下面先来看看 JSON-RPC 协议中请求的基本格式：
JSON-RPC请求中各个字段的含义如下：
在 JSON-RPC 的服务端收到调用请求之后，会查找到相应的方法并进行调用，然后将方法的返回值整理成如下格式，返回给客户端：
JSON-RPC响应中各个字段的含义如下：
Dubbo 使用 jsonrpc4j 库来实现 JSON-RPC 协议，下面使用 jsonrpc4j 编写一个简单的 JSON-RPC 服务端示例程序和客户端示例程序，并通过这两个示例程序说明 jsonrpc4j 最基本的使用方式。
首先，需要创建服务端和客户端都需要的 domain 类以及服务接口。先来创建一个 User 类，作为最基础的数据对象：
接下来创建一个 UserService 接口作为服务接口，其中定义了 5 个方法，分别用来创建 User、查询 User 以及相关信息、删除 User：
UserServiceImpl 是 UserService 接口的实现类，其中使用一个 ArrayList 集合管理 User 对象，具体实现如下：
整个用户管理业务的核心大致如此。下面我们来看服务端如何将 UserService 与 JSON-RPC 关联起来。
首先，创建 RpcServlet 类，它是 HttpServlet 的子类，并覆盖了 HttpServlet 的 service() 方法。我们知道，HttpServlet 在收到 GET 和 POST 请求的时候，最终会调用其 service() 方法进行处理；HttpServlet 还会将 HTTP 请求和响应封装成 HttpServletRequest 和 HttpServletResponse 传入 service() 方法之中。这里的 RpcServlet 实现之中会创建一个 JsonRpcServer，并在 service() 方法中将 HTTP 请求委托给 JsonRpcServer 进行处理：
最后，创建一个 JsonRpcServer 作为服务端的入口类，在其 main() 方法中会启动 Jetty 作为 Web 容器，具体实现如下：
这里使用到的 web.xml 配置文件如下：
完成服务端的编写之后，下面再继续编写 JSON-RPC 的客户端。在 JsonRpcClient 中会创建 JsonRpcHttpClient，并通过 JsonRpcHttpClient 请求服务端：
在 AbstractProxyProtocol 的 export() 方法中，首先会根据 URL 检查 exporterMap 缓存，如果查询失败，则会调用 ProxyFactory.getProxy() 方法将 Invoker 封装成业务接口的代理类，然后通过子类实现的 doExport() 方法启动底层的 ProxyProtocolServer，并初始化 serverMap 集合。具体实现如下：
在 HttpProtocol 的 doExport() 方法中，与前面介绍的 DubboProtocol 的实现类似，也要启动一个 RemotingServer。为了适配各种 HTTP 服务器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 层抽象出了一个 HttpServer 的接口。
dubbo-remoting-http 模块的入口是 HttpBinder 接口，它被 @SPI 注解修饰，是一个扩展接口，有三个扩展实现，默认使用的是 JettyHttpBinder 实现，如下图所示：
HttpBinder 接口中的 bind() 方法被 @Adaptive 注解修饰，会根据 URL 的 server 参数选择相应的 HttpBinder 扩展实现，不同 HttpBinder 实现返回相应的 HttpServer 实现。HttpServer 的继承关系如下图所示：
这里以 JettyHttpServer 为例简单介绍 HttpServer 的实现，在 JettyHttpServer 中会初始化 Jetty Server，其中会配置 Jetty Server 使用到的线程池以及处理请求 Handler：
可以看到 JettyHttpServer 收到的全部请求将委托给 DispatcherServlet 这个 HttpServlet 实现，而 DispatcherServlet 的 service() 方法会把请求委托给对应接端口的 HttpHandler 处理：
了解了 Dubbo 对 HttpServer 的抽象以及 JettyHttpServer 的核心之后，回到 HttpProtocol 中的 doExport() 方法继续分析。
在 HttpProtocol.doExport() 方法中会通过 HttpBinder 创建前面介绍的 HttpServer 对象，并记录到 serverMap 中用来接收 HTTP 请求。这里初始化 HttpServer 以及处理请求用到的 HttpHandler 是 HttpProtocol 中的内部类，在其他使用 HTTP 协议作为基础的 RPC 协议实现中也有类似的 HttpHandler 实现类，如下图所示：
在 HttpProtocol.InternalHandler 中的 handle() 实现中，会将请求委托给 skeletonMap 集合中记录的 JsonRpcServer 对象进行处理：
skeletonMap 集合中的 JsonRpcServer 是与 HttpServer 对象一同在 doExport() 方法中初始化的。最后，我们来看 HttpProtocol.doExport() 方法的实现：
介绍完 HttpProtocol 暴露服务的相关实现之后，下面再来看 HttpProtocol 中引用服务相关的方法实现，即 protocolBindinRefer() 方法实现。该方法首先通过 doRefer() 方法创建业务接口的代理，这里会使用到 jsonrpc4j 库中的 JsonProxyFactoryBean 与 Spring 进行集成，在其 afterPropertiesSet() 方法中会创建 JsonRpcHttpClient 对象：
下面来看 doRefer() 方法的具体实现：
在 AbstractProxyProtocol.protocolBindingRefer() 方法中，会通过 ProxyFactory.getInvoker() 方法将 doRefer() 方法返回的代理对象转换成 Invoker 对象，并记录到 Invokers 集合中，具体实现如下：
本文重点介绍了在 Dubbo 中如何通过“HTTP 协议 + JSON-RPC”的方案实现跨语言调用。首先介绍了 JSON-RPC 中请求和响应的基本格式，以及其实现库 jsonrpc4j 的基本使用；接下来我们还详细介绍了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心类，剖析了 Dubbo 中“HTTP 协议 + JSON-RPC”方案的落地实现。
Dubbo是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。
Dubbo内部使用了 Netty、Zookeeper，保证了高性能高可用性，使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用和灵活扩展，使前端应用能更快速的响应多变的市场需求。
另外，分布式架构可以承受更大规模的并发流量。
Dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。
当网站流量很小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本。
缺点：单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难以维护
垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。
缺点：但是在垂直架构中相同逻辑代码需要不断地复制，不能复用。
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心
随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。
课程目标：
了解远程调用PRC的概念，分布式应用为什么使用RPC, 基于PRC协议的Dubbo的使用。Dubbo框架的特点，框架的组件;基于Dubbo服务提供者，消费者，注册中心Zookeeper的分布式应用的开发部署， Dubbo的负载均衡实现。微服务的开发. Spring + Dubbo + Zookeeper + Linux
适用人群：
适合有Java基础，要进入到互联网行业的开发人员，微服务开发。
动力节点的Dubbo课程以实战为主讲解，从基础开始手把手式地详细讲解RPC概念，PRC在分布式应用的重要作用。Dubbo分布式服务框架的应用入门基础。传统应用到分布式以及微服务的转变思想。Dubbo协议的特点。Dubbo分布式服务的详细开发流程、Dubbo服务的实施部署，Zookeeper的服务管理等。
课程目录：
•001.dubbo视频教程-dubbo前言
•002.dubbo视频教程-dubbo概述
•003.dubbo视频教程-初识dubbo
•004.dubbo视频教程-dubbo前世今生
•005.dubbo视频教程-dubbo结构概述-1
•006.dubbo视频教程-dubbo结构概述-2
•007.dubbo视频教程-dubbo的使用-直连方式-1
•008.dubbo视频教程-dubbo的使用-直连方式-2
•009.dubbo视频教程-dubbo的使用-直连方式-3
•010.dubbo视频教程-dubbo的使用-直连方式-4
•011.dubbo视频教程-dubbo服务化最佳实践-概述
•012.dubbo视频教程-dubbo服务化最佳实践-1
•013.dubbo视频教程-dubbo服务化最佳实践-2
•014.dubbo视频教程-dubbo服务化最佳实践-3
•015.dubbo视频教程-dubbo服务化最佳实践-4
•016.dubbo视频教程-dubbo服务化最佳实践-5
•017.dubbo视频教程-注册中心概述
•018.dubbo视频教程-windows下安装及配置zookeeper
•019.dubbo视频教程-linux下安装及配置zookeeper
•020.dubbo视频教程-内容回顾
•021.dubbo视频教程-dubbo实例-使用注册中心-1
•022.dubbo视频教程-dubbo实例-使用注册中心-2
•023.dubbo视频教程-dubbo实例-使用注册中心-3
•024.dubbo视频教程-dubbo实例-使用注册中心-4
•025.dubbo视频教程-dubbo实例-使用注册中心-5
•026.dubbo视频教程-dubbo实例使用linux注册中心
•027.dubbo视频教程-dubbo实例-版本号version的使用-1
•028.dubbo视频教程-dubbo实例-版本号version的使用-2
•029.dubbo视频教程-dubbo实例-版本号version的使用-3
•030.dubbo视频教程-dubbo实例-版本号version的使用-4
•031.dubbo视频教程-解决学生问题
•032.dubbo视频教程-dubbo配置中常见属性
•033.dubbo视频教程-dubbo的高稳定性
•034.dubbo视频教程-监控中心-1
•035.dubbo视频教程-监控中心-2
Dubbo实战视频教程：
Dubbo全套资料下载
通常我们想调用别人的dubbo服务时，我们需要在项目中引入对应的jar包。而泛化调用的作用是，我们无需依赖相关jar包，也能调用到该服务。
这个特性一般使用在网关类项目中，在业务开发中基本不会使用。
假设我现在要调用下面的接口服务
在xml文件做以下配置
然后注入使用
在两种调用方式中，我们都需要使用被调用接口的字符串参数生成GenericService，通过GenericService的$invoke间接调用目标接口的接口。
$invoke的三个参数分别为，方法名，方法参数类型数组，方法参数数组。
可以看到泛化调用的一个复杂性在于$invoke的第三个参数的组装，下面介绍几种复杂入参的调用方式
首先丰富提供者接口
与入参相似，虽然$invoke的返回定义为Object，实际上针对不同类型有不同的返回。
泛化调用和直接调用在消费者者端，在 使用上的区别 是，我们调用服务时使用的接口为GenericService，方法为$invoker。在 底层的区别 是，消费者端发出的rpc报文发生了变化。
在使用上，不管哪种配置方式，我们都需要配置generic=true
设置generic=true后，RefereceConfig的interfaceClass会被强制设置为GenericService
这也使得我们的RefereanceBean返回的是GenericService类型的代理。
生成的代理是GenericService的代理只是我们使用方式上的变化，更为核心的是，底层发送的rpc报文发生了什么变化。
Dubbo的rpc报文分为header和body两部分。我们这边只需要关注body部分。构造逻辑如下
那么我们通过直接调用与泛化调用ByeService的bye方法在报文上有啥区别呢？
我一开始以为报文中的path是GenericeService，其实并没有，path就是我们调用的目标方法。
path来源？？？todo
而报文中的方法名，方法参数类型以及具体参数，还是按照GenericeService的$invoke方法入参传递的。
这么个二合一的报文，发送到提供者那边，它估计也会很懵逼，我应该怎么执行？
所以针对泛化调用报文还会把generic=true放在attchment中传递过去
具体逻辑在GenericImplFilter中。
GenericImplFilter中有很多其他逻辑，比如泛化调用使用的序列化协议，正常接口走泛化调用的模式，我们只需要设置attachment的那部分。
知道消费者端报文发生了什么变化，那么接下来就去看提供者端如何处理这个改造后的报文。
总结一下ReferenceConfig中interfaceClass和interfaceName的区别？(这道面试题好像不错)
interfaceClass用于指定生成代理的接口
interfaceName用于指定发送rpc报文中的path(告诉服务端我要调用那个服务)
消费者泛化调用的rpc报文传递到提供者还不能直接使用，虽然path是对的，但是实际的方法名，参数类型，参数要从rpc报文的参数中提取出来。
GenericFilter就是用来做这件事情。
在提供者这边，针对泛化调用的逻辑全部封装到了GenericFilter，解耦的非常好。
注意第4个条件，一开始很疑惑，后来发现rpc报文中的path是目标接口的，这边invoker.getInterface()返回的肯定就是实际接口了
这边有个疑问，为什么这边还要再次反序列化一次，netty不是有decoder么？？
嗯，你别忘了，针对一个POJO你传过来是一个Map，从Map转换为POJO需要这边进一步处理。
这边需要注意一下！！针对接口的泛化调用，抛出的异常都会经过GenericException包装一下。
从功能上来看，泛化调用提供了在没有接口依赖情况下进行的解决方案，丰富框架的使用场景。
从设计上来看，泛化调用的功能还是通过扩展的方式实现的，侵入性不强，值得学习借鉴。
Dubbo是Alibaba开源的分布式服务框架，它按照分层的方式来架构，使用这种方式可以使各层解耦。
Dubbo在调用远程的服务的时候再本地有一个接口，就想调用本地方法一样去调用，底层实现好参数传输和远程服务运行结果传回之后的返回。
Dubbo的特点：
（1）它主要使用高效的网络框架和序列化框架，让分布式服务之间调用效率更高。
（2）采用注册中心管理众多的服务接口地址，当你想调用服务的时候只需要跟注册中心询问即可，不像使用WebService一样每个服务都得记录好接口调用方式。
（3）监控中心时实现服务方和调用方之间运行状态的监控，还能控制服务的优先级、权限、权重、上下线等，让整个庞大的分布式服务系统的维护和治理比较方便。
（4）高可用，如果有服务挂了，注册中心就会从服务列表去掉该节点，客户端会像注册中心请求另一台可用的服务节点重新调用。同时注册中心也能实现高可用（ZooKeeper）。
（5）负载均衡，采用软负载均衡算法实现对多个相同服务的节点的请求负载均衡。
Dubbo需要四大基本组件：Rigistry,Monitor,Provider,Consumer。
1、监控中心的配置文件-dubbo.properties文件
（1）容器，监控中心是在jetty和spring环境下运行，依赖于注册中心，日志系统是log4j
dubbo.container = log4j,spring,registry,jetty
（2）监控服务的名称，监控系统对整个Dubbo服务系统来说也是一个服务
dubbo.application.name = simple-monitor
（3）服务的所有者，这是Dubbbo的服务的功能，可以指定服务的负责人
dubbo.application.owner = coselding
（4）注册中心的地址，配置后监控中心就能通过注册中心获取当前可用的服务列表及其状态，在页面向你汇报Dubbo中的服务运行情况。
dubbo.registr.address = multicast://{ip}:{port} //广播
dubbo.registr.address = zookeeper://{ip}:{port} //zookeper
dubbo.registr.address = redis://{ip}:{port} //redis
dubbo.registr.address = dubbo://{ip}:{port} //dubbo
（5）dubbo协议端口号
dubbo.protocol.port = 7070
（6）jetty工作端口号
dubbo.jetty.port = 8082
（7）工作目录，用于存放监控中心的数据
dubbo.jetty.directory = ${user.home}/monitor
（8）监控中心报表存放目录
dubbo.charts.directory=${dubbo.jetty.directory}/charts
（9）监控中心数据资料目录
dubbo.statistics.directory=${user.home}/monitor/statistics
（10）监控中心日志文件路径
dubbo.log4j.file=logs/dubbo-monitor-simple.log
（11）监控中心日志记录级别
dubbo.log4j.level=WARN
2、Dubbo提供负载均衡方式
（1）Random，随机，按权重配置随机概率，调用量越大分布越均匀，默认方式。
（2）RounRobin，轮询，按权重设置轮询比例，如果存在比较慢的机器容易在这台机器上请求阻塞较多。
（3）LeastActive，最少活跃调用数，不支持权重，只能根据自动识别的活跃数分配，不能灵活调配。
（4）ConsistenHash，一致性hash，对相同参数的请求路由到一个服务提供者上，如果有类似灰度发布需求可采用。
3、Dubbo过滤器
Dubbo初始化过程加载ClassPath下的META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个路径下的com.alibaba.dubbo.rpc.Filter文件。文件内容：
Name = FullClassName,这些类必须实现Filter接口。
自定义Filter类：
配置文件在配置过滤器，consumer.xml中：
Dubbo对过滤器的加载过程：
先加载三个路径下的com.alibaba.dubbo.rpc.Filter文件里面的键值对，key为过滤器名称，value为过滤器的类的全限定名(这个类必须实现Dubbo中的Filter接口)。
自定义的类中@Active注解是过滤器设定的全局基本属性。
Spring在加载consumer.xml文件时，通过 dubbo:consumer filter="xxx" id = "xxx" retrries = "0"这个配置指定消费者端要加载的过滤器，通过filter属性指定过滤器名称。
@Activate注解-自动激活，group属性是表示匹配了对应的角色才被加载，value表示表明过滤条件，不写则表示所有条件都会被加载，写了则只有dubbo URL中包含该参数名且参数值不为空才被加载，这个参数会以dubbo协议的一个参数K-V对传到Provider。
4、Dubbo的Provider配置
5、Dubbo的Consumer配置
1、Dubbo是什么？
Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式框架。
2、为什么使用Dubbo？
很多公司都在使用，经过很多线上的考验，内部使用了Netty，Zookeeper，保证了高性能可用性。
使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可以提高业务复用灵活性扩展，使前端应用能快速的响应对边的市场需求。分布式架构可以承受更大规模的并发流量。
Dubbo的服务治理图：
3、Dubbo和Spring Cloud的区别
两个没有关联，但是非要说区别，有如下几点：
（1）通信方式不同，Dubbo使用RPC通信，Spring Cloud使用HTTP Restful方式
（2）组成部分不同
4、Dubbo支持的协议
dubbo:// （推荐）；rmi:// ；hessian:// ；http:// ；webservice:// ；thrift:// ；memcached:// ；redis:// ；rest:// 。
5、Dubbo需要容器吗？
不需要，如果硬要容器的话，会增加复杂性，同时也浪费资源。
6、Dubbo内置的服务容器
Spring Container；Jetty Container；Log4j Container。
7、Dubbo中节点角色
Register，Monitor，Provider，Consumer，Container(服务运行的容器)。
8、Dubbo的服务注册和发现的流程图
9、Dubbo的注册中心
默认使用Zookeper作为注册中心，还有Redis，Multicast，dubbo注册中心。
10、Dubbo的配置方式
Spring配置方式和Java API配置方式
11、Dubbo的核心配置
（1）dubbo:service 服务配置
（2）dubbo:referece 引用配置
（3）dubbo:protocol 协议配置
（4）dubbo:application 应用配置
（5）dubbo:registry 注册中心配置
（6）dubbo:monitor 监控中心配置
（7）dubbo:provider 提供方配置
（8）dubbo:consumer 消费方配置
（9）dubbo:method 方法配置
（10）dubbo:argument 参数配置
12、在Provider 节点上可以配置Consumer端的属性有哪些？
（1）timeout：方法调用超时
（2）retries：失败重试次数，默认是2次
（3）loadbalance：负载均衡算法，默认随机
（4）actives消费者端，最大并发调用控制
13、Dubbo启动时如果依赖的服务不可用会怎样
Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成。默认check ="true"。
14、Dubbo序列化框架
推荐使用Hessian序列化，还有Dubbo，FastJson，Java自带序列化。
15、Dubbo的通信框架
默认使用Netty框架，另外也提供了Mina，Grizzly。
16、Dubbo集群容错方案
（1）Failover Cluster，失败自动切换，自动重试其他服务器。
（2）Failfast Cluster，快速失败，立即报错，只发起一次调用。
（3）Failsafe Cluster，失败安全，出现异常时，直接忽略。
（4）Failback Cluster，失败自动恢复，记录失败请求，定时重发。
（5）Forking Cluster，并行调用多个服务器，只要一个返回成功即可。
（6）Broadcast Cluster，广播逐个调用所有提供者，任意一个报错则报错。
17、Dubbo的负载均衡策略
（1）Random LoadBalance，随机，按权重设置随机概率，默认。
（2）RoundRobin LoadBalace，轮询，按公约后的权重设置轮训比例。
（3）LeastActive LoadBalace，最少活跃调用数，相同活跃数的随机。
（4）ConsistenHash LoadBalance，一致性hash，相同参数的请求总是发到用一个服务器。
18、指定某一个服务
可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。
dubbo:reference interface="com.weidian.dubbo.IMyDemo" version="1.0" id="myDemo" url="dubbo://127.0.0.1:20880/"/dubbo:reference
19、Dubbo多协议
Dubbo允许配置多协议，在不同服务器上支持不同协议，或者同一服务支持多种协议。
20、当一个服务有多种实现时怎么做？
当一个接口有多种是现实，可以用group属性来分组，服务提供方和消费方都指定同一个group即可。
21、兼容旧版本
使用版本号过度，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。
22、Dubbo可以缓存吗？
Dubbo提供声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。
23、Dubbo服务之间的调用时阻塞的吗？
默认是同步等待结果阻塞的，支持异步调用。Dubbo是基于NIO的非阻塞实现并行调用的，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个Future对象。
24、Dubbo不支持分布式事务
25、Dubbo必须依赖的包
Dubbo必须依赖JDK，其他为可选。
26、Dubbo使用过程中的问题
Dubbo的设计目的是为了满足高并发小数据量的rpc请求，在大数据量下性能表现不是很好，建议使用rmi或http协议。
27、Dubbo的管理控制台的作用
路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡。
28、Spring boot整合Dubbo
（1）添加依赖
!-- --
dependency
groupIdcom.alibaba.boot/groupId
artifactIddubbo-spring-boot-starter/artifactId
version0.1.0/version
/dependency
!-- --
dependency
groupIdcom.101tec/groupId
artifactIdzkclient/artifactId
version0.10/version
/dependency
（2）配置dubbo
## Dubbo 服务提供者配置
spring.dubbo.application.name=provider
spring.dubbo.registry.address=zookeeper://127.0.0.1:2181
spring.dubbo.protocol.name=dubbo
spring.dubbo.protocol.port=20880
spring.dubbo.scan=org.spring.springboot.dubbo
## Dubbo 服务消费者配置
spring.dubbo.application.name=consumer
spring.dubbo.registry.address=zookeeper://127.0.0.1:2181
spring.dubbo.scan=org.spring.springboot.dubbo
一、Dubbo整体架构
1、Dubbo与Spring的整合
Dubbo在使用上可以做到非常简单，不管是Provider还是Consumer都可以通过Spring的配置文件进行配置，配置完之后，就可以像使用spring
bean一样进行服务暴露和调用了，完全看不到dubbo
api的存在。这是因为dubbo使用了spring提供的可扩展Schema自定义配置支持。在spring配置文件中，可以像、这样进行配置。META-INF下的spring.handlers文件中指定了dubbo的xml解析类：DubboNamespaceHandler。像前面的被解析成ServiceConfig，被解析成ReferenceConfig等等。
2、jdk spi扩展
由于Dubbo是开源框架，必须要提供很多的可扩展点。Dubbo是通过扩展jdk
spi机制来实现可扩展的。具体来说，就是在META-INF目录下，放置文件名为接口全称，文件中为key、value键值对，value为具体实现类的全类名，key为标志值。由于dubbo使用了url总线的设计，即很多参数通过URL对象来传递，在实际中，具体要用到哪个值，可以通过url中的参数值来指定。
Dubbo对spi的扩展是通过ExtensionLoader来实现的，查看ExtensionLoader的源码，可以看到Dubbo对jdk spi做了三个方面的扩展：
（1）jdk spi仅仅通过接口类名获取所有实现，而ExtensionLoader则通过接口类名和key值获取一个实现；
（2）Adaptive实现，就是生成一个代理类，这样就可以根据实际调用时的一些参数动态决定要调用的类了。
（3）自动包装实现，这种实现的类一般是自动激活的，常用于包装类，比如Protocol的两个实现类：ProtocolFilterWrapper、ProtocolListenerWrapper。
3、url总线设计
Dubbo为了使得各层解耦，采用了url总线的设计。我们通常的设计会把层与层之间的交互参数做成Model，这样层与层之间沟通成本比较大，扩展起来也比较麻烦。因此，Dubbo把各层之间的通信都采用url的形式。比如，注册中心启动时，参数的url为：
registry://0.0.0.0:9090?codec=registrytransporter=netty
这就表示当前是注册中心，绑定到所有ip，端口是9090，解析器类型是registry，使用的底层网络通信框架是netty。
二、Dubbo启动过程
Dubbo分为注册中心、服务提供者(provider)、服务消费者(consumer)三个部分。
1、注册中心启动过程
注册中心的启动过程，主要看两个类：RegistrySynchronizer、RegistryReceiver，两个类的初始化方法都是start。
RegistrySynchronizer的start方法：
（1）把所有配置信息load到内存；
（2）把当前注册中心信息保存到数据库；
（3）启动5个定时器。
5个定时器的功能是：
（1）AutoRedirectTask，自动重定向定时器。默认1小时运行1次。如果当前注册中心的连接数高于平均值的1.2倍，则将多出来的连接数重定向到其他注册中心上，以达到注册中心集群的连接数均衡。
（2）DirtyCheckTask，脏数据检查定时器。作用是：分别检查缓存provider、数据库provider、缓存consumer、数据库consumer的数据，清除脏数据；清理不存活的provider和consumer数据；对于缓存中的存在的provider或consumer而数据库不存在，重新注册和订阅。
（3）ChangedClearTask，changes变更表的定时清理任务。作用是读取changes表，清除过期数据。
（4）AlivedCheckTask，注册中心存活状态定时检查，会定时更新registries表的expire字段，用以判断注册中心的存活状态。如果有新的注册中心，发送同步消息，将当前所有注册中心的地址通知到所有客户端。
（5）ChangedCheckTask，变更检查定时器。检查changes表的变更，检查类型包括：参数覆盖变更、路由变更、服务消费者变更、权重变更、负载均衡变更。
RegistryReceiver的start方法：启动注册中心服务。默认使用netty框架，绑定本机的9090端口。最后启动服务的过程是在NettyServer来完成的。接收消息时，抛开dubbo协议的解码器，调用类的顺序是
NettyHandler-》NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》
DecodeHandler-》HeaderExchangeHandler-》RegistryReceiver-》RegistryValidator-》RegistryFailover-》RegistryExecutor。
2、provider启动过程
provider的启动过程是从ServiceConfig的export方法开始进行的，具体步骤是：
（1）进行本地jvm的暴露，不开放任何端口，以提供injvm这种形式的调用，这种调用只是本地调用，不涉及进程间通信。
（2）调用RegistryProtocol的export。
（3）调用DubboProtocol的export，默认开启20880端口，用以提供接收consumer的远程调用服务。
（4）通过新建RemoteRegistry来建立与注册中心的连接。
（5）将服务地址注册到注册中心。
（6）去注册中心订阅自己的服务。
3、consumer启动过程
consumer的启动过程是通过ReferenceConfig的get方法进行的，具体步骤是：
（1）通过新建RemoteRegistry来建立与注册中心的连接。
（2）新建RegistryDirectory并向注册中心订阅服务，RegistryDirectory用以维护注册中心获取的服务相关信息。
（3）创建代理类，发起consumer远程调用时，实际调用的是InvokerInvocationHandler。
三、实际调用过程
consumer端发起调用时，实际调用经过的类是：
1、consumer:
InvokerInvocationHandler-》MockClusterInvoker(如果配置了Mock，则直接调用本地Mock类)-》FailoverClusterInvoker(负载均衡，容错机制，默认在发生错误的情况下，进行两次重试)-》RegistryDirectory$InvokerDelegete-》ConsumerContextFilter-》FutureFilter-DubboInvoker
2、provider:
NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》DubboProtocol.requestHandler-》EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter-》实际service。
四、Dubbo使用的设计模式
1、工厂模式
ServiceConfig中有个字段，代码是这样的：
private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Dubbo里有很多这种代码。这也是一种工厂模式，只是实现类的获取采用了jdk
spi的机制。这么实现的优点是可扩展性强，想要扩展实现，只需要在classpath下增加个文件就可以了，代码零侵入。另外，像上面的Adaptive实现，可以做到调用时动态决定调用哪个实现，但是由于这种实现采用了动态代理，会造成代码调试比较麻烦，需要分析出实际调用的实现类。
2、装饰器模式
Dubbo在启动和调用阶段都大量使用了装饰器模式。以Provider提供的调用链为例，具体的调用链代码是在ProtocolFilterWrapper的buildInvokerChain完成的，具体是将注解中含有group=provider的Filter实现，按照order排序，最后的调用顺序是
EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》
TimeoutFilter-》MonitorFilter-》TraceFilter。
更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter的作用是判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter则只是在主功能上添加了功能，更改当前线程的ClassLoader，这是典型的装饰器模式。
3、观察者模式
Dubbo的provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个listener。注册中心会每5秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个notify消息，provider接受到notify消息后，即运行NotifyListener的notify方法，执行监听器方法。
4、动态代理模式
Dubbo扩展jdk
spi的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是，获取URL参数中指定参数的值作为获取实现类的key。
官网地址：
如果在消费端和服务端都配置了负载均衡策略，以消费端为准。
在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。
消费者调用一个服务，分为三步：
1.消费者发送请求（网络传输）
2.服务端执行服务
3.服务端返回响应（网络传输）
如果在服务端和消费端各配置了一个timeout，那就比较复杂了，假设
1.服务执行为5s
2.消费端timeout=3s
3.服务端timeout=6s
那么消费端掉用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。
官网地址：
集群容错表示：服务消费者在掉用某个服务时，这个服务有多个服务提供者，在经过负载均衡后选择其中一个服务提供者之后进行调用，但调用报错后，Dubbo所采取的后续处理策略。
官网地址：
服务降级表示：服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。
集群容错和服务降级的区别在于：
1.集群容错时整个集群范围内的容错
2.服务降级时单个服务提供者的自身容错
官网地址：
本地存根：名字很抽象，但实际上不难理解，本地存根就是一段逻辑，这段逻辑是在服务消费端执行的，这段逻辑一般都是由服务提供者提供，服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情，比如结果缓存，请求参数验证等等。
官网地址：
本地伪装就是Mock，Dubbo中的Mock的功能相对于本地存根更简单一点，Mock其实就是Dubbo中的服务容错的解决方案。
官网地址：
如果当前服务支持参数回调，意思就是对于某个服务接口中的某个方法，如果想支持消费者在调用这个方式时能设置回调逻辑，那么该方法就是需要提供一个入参用来表示回调逻辑
因为Dubbo协议是基于长连接，所以消费者在两次调用同一个方法想指定不同的回调逻辑，那么就需要在调用时在指定一定key进行区分。
官网地址：
理解起来比较容易，主要要理解CompletableFuture，如果不理解，就直接把它理解为Future
其他异步调用方式：
官网地址：
泛化调用可以用来做服务测试。
在Dubbo中，如果某个服务想要支持泛化调用，就可以将该服务的generic属性设置为true，那对于服务消费者来说，就可以不用依赖该服务的接口，直接利用GenericService接口来进行服务调用
官网地址：
实现了GenericService接口就是泛化服务
官网地址：
github地址：
官网地址：
注意动态配置修改的是服务参数，并不能修改服务的协议,IP,PORT,VERSION,GROUP,因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。
官网地址：
