dubbo服务,Dubbo服务注册与动态发现机制的原理与实现细节

dubbo服务,Dubbo服务注册与动态发现机制的原理与实现细节详细介绍

本文目录一览： dubbo服务调用异常

dubbo服务调用异常有可能是以下原因造成：地址找不到、调用超时。
地址找不到：No provideravailable。
（1）Provider服务没启动，或者注册中心（比如ZooKeeper，Nacos，Consul）宕机了。
（2）Dubbo的服务配置有误差，必须保证服务名，组别（默认是Dubbo），version三者都正确。
（3）访问的环境有误：通常我们会有开发环境、测试环境、线上生产环境等多套环境。有时候发布的服务到了测试环境，而访问调用时却走了开发环境。
调用超时：client-sidetimeout
（1）服务端确实处理比较慢，无法在指定的时间返回结果，调用端就自动返回一个超时的异常响应来结束此次调用。
（2）服务端如果响应的比较快，但当客户端Load很高，负载压力很大的时候，会因为客户端请求发不出去、响应卡在TCPBuffer等问题，造成超时。因为客户端接收到服务端发来的数据或者请求服务端的数据，都会在系统层面排队，如果系统负载比较高，在内核态的时间占比就会加长，从而造成客户端获取到值时已经超时。
（3）通常是业务处理太慢，可在服务提供方机器上执行：jstack［PID］＞jstack.log分析线程都卡在哪个方法调用上，这里就是慢的原因。如果不能调优性能，请调高timeout阈值。
Dubbo的特性：
面向接口代理的高性能RPC调用提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
智能负载均衡内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
服务自动注册与发现支持多种注册中心服务，服务实例上下线实时感知。
高度可扩展能力遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
运行期流量调度内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
可视化的服务治理与运维提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
以上内容参考：百度百科-Dubbo

Dubbo分布式服务框架介绍

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。
Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。
Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。
作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：
Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。
Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo服务组件调用关秕说明 ：
Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：
从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。
根据官方提供的，对于上述各层之间关系的描述，如下所示：

Dubbo-发布服务执行的流程

我们以dubbo 的xml配置为例：

dubbo服务发布只需在spring.xml中如下配置即可：

通过dubbo于spring的融合可以了解到

标签是通过ServiceBean解析封装。

ServiceBean这个类继承 了ServiceConfig实现了spring的5个接口

InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware 来融入到spring的启动过程。

ServiceBean实现了 ApplicationListener 接口，当spring容器触发了ContextRefreshedEvent事件时，

就会调用 ServiceConfig 中的export()方法发布申明的dubbo服务，

ServiceConfig 中的export()方法部分源码如下，如果申明了delay（延迟多少），那么延迟调用doExport()发布这个服务，如果没有设置则直接调用doExport()发布服务：

接下来看ServiceConfig的doExport()方法

1，检查中是否配置了interface, 如果为空，那么抛出异常：

if (interfaceName == null || interfaceName.length() == 0) { throw new IllegalStateException("interface not allow null!");}

2，检查接口类型必需为接口

if(! interfaceClass.isInterface()) {

throw new IllegalStateException("The interface class " + interfaceClass + " is not a interface!");

}

3，检查方法是否在接口中存在

4，检查引用不为空，并且引用必需实现接口 interface="com.alibaba.dubbo.demo.DemoService" ref="demoService"

5，检查checkApplication(); checkRegistry(); checkProtocol();有效性。

6，调用ServiceConfig.doExportUrls()发布dubbo服务

ServiceConfig.doExportUrls()如下：

通过调用loadRegistries(true)得到所有registry的url地址，例如配置了

配置结果为dubbo.registry.address=zookeeper://127.0.0.1:2181；

protocols就是将要发布服务的协议集合(dubbo服务可以同时暴露多种协议)，例如配置了

dubbo.protocol.name=dubbo ,? dubbo.protocol.port=20880

ServiceConfig.doExportUrlsFor1Protocol()

先把application、module、provider、protocol、exporter、registries、monitor所有属性封装到Map中例如protocol=dubbo，host=10.0.0.1，port=20880，path=com.alibaba.dubbo.demo.TestService等，然后构造dubbo定义的统一数据模型URL:

URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);

这个url非常重要，贯穿整个dubbo服务的发布和调用过程，可以在服务发布后在dubbo-monitor中看到；

ServiceConfig.doExportUrlsFor1Protocol()中根据scope判断服务的发布范围：

如果配置scope = none， 那么不需要发布这个dubbo服务；

没有配置scope = none，且配置的scope != remote， 那么本地暴露 这个dubbo服务；

没有配置scope = none，且配置的scope != remote且配置的scope != local，那么远程暴露这个dubbo服务（例如远程暴露这个服务到zk上，默认情况下scope没有配置，就是在这里发布服务）；

以上如果执行成功，会把dubbo服务到zookeeper上，invoker.getUrl()的值为

registry://10.0.53.87:2188/com.alibaba.dubbo.registry.RegistryService?application=dubbo-test&dubbo=2.0.0&export=dubbo%3A%2F%2F10.52.16.218%3A20886%2Fcom.alibaba.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddubbo-test%26dubbo%3D2.0.0%26interface%3Dcom.alibaba.dubbo.demo.DemoService%26loadbalance%3Droundrobin%26methods%3DsayHello%26owner%3Dafei%26pid%3D2380%26side%3Dprovider%26timestamp%3D1380082&owner=afei&pid=2380?istry=zookeeper×tamp=138004：

接下来我们分析

Protocol.export()暴露服务接口：

然后调用RegistryProtocol.export()：

核心调用registry.register(registedProviderUrl)。

调用AbstractRegistry.register(URL)，把这次需要注册的URL加到Set registered中，即本地缓存新的注册URL；

在ZookeeperRegistry.doRegister(URL)调用AbstractZookeeperClient.create()，toUrlPath将URL形式的地址转换成zookeeper路径，最终在AbstractZookeeperClient中把需要发布的服务的URL保存到zookeeper：

ZookeeperRegistry.doRegister(url)注册服务如果失败：

如果开启了启动检查check=true，那么直接抛出异常；

如果没有开启启动检查，那么将失败的注册请求记录到失败列表，定时重试;

核心调用registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener):

对发布的dubbo服务的这个url进行监听， 当服务变化有时通知重新暴露服务， 以zookeeper为例，暴露服务会在zookeeper生成一个节点，当节点发生变化的时候会触发overrideSubscribeListener的notify方法重新暴露服务

注册服务失败的重试机制：

注册服务失败后，会将url加入重试url集合中，failedRegistered.add(url);重试任务在FailbackRegistry中实现：

注册的监听机制：

订阅并设置监听registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);

--> FailbackRegistry.subscribe(URL url, NotifyListener listener)

--> ZookeeperRegistry.doSubscribe(final URL url, final NotifyListener listener)，部分实现源码如下：

当服务有变化的时候:

doNotify(url, listener, urls);

AbstractRegistry.notify(URL url, NotifyListener listener, List urls)

--> RegistryDirectory.notify(List urls)

--> RegistryDirectory.refreshInvoker(List invokerUrls)，这里调用toMethodInvokers(Map> invokersMap)的实现比较重要，将invokers列表转成与方法的映射关系，且每个方法对应的List需要通过Collections.sort(methodInvokers, InvokerComparator.getComparator());排序，然后，还要将其转为unmodifiable的map

其中 InvokerComparator 的定义如下，即直接根据url进行比较排序

dubbo协议发布服务会调用DubboProtocol.export()的过程：

从Invoker中获取URL： URL url = invoker.getUrl();

根据URL得到key, 由暴露的服务接口+端口组成，例如com.alibaba.dubbo.demo.DemoService:20886 ；? String key = serviceKey(url);

构造DubboExporter存到Map中local cache化：

DubboExporter exporter = new DubboExporter(invoker, key, exporterMap); exporterMap.put(key, exporter);

调用DubboProtocol.openServer()开启netty(默认)服务保持通信，并设置requestHandler处理consumer对provider的调用请求；

DubboProtocol.openServer()：

key的值就是IP:Port，例如10.52.17.167:20886，根据key从serverMap中如果取不到ExchangeServer，表示还没绑定服务端口，需要调用createServer(url)-->Exchangers.bind(url, requestHandler)-->Transporters.getTransporter().bind(url, handler)(dubbo支持mina，netty，grizzly，默认实现是netty) --> NettyTransporter.bind(URL, ChannelHandler) --> NettyServer.open()；

dubbo默认调用的是netty

Netty服务几个重要的地方

构造 ChannelPipeline 时指定了编码&解码，其中编码为NettyCodecAdapter.getEncoder()，解码为NettyCodecAdapter.getDncoder()；

指定了handler为final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);处理请求；

从零开始认识Dubbo

[TOC]
1.Dubbo是什么
Apache Dubbo 是一款高性能Java RPC框架。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东， 说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册） 其核心部分包含:
2.Dubbo能做什么
Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
3.Dubbo架构
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
4.Dubbo的使用方法
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。如果不想使用Spring配置，可以通过API的方式进行调用（注解式，不推荐使用）
下载安装zookeeper注册中心（不建议使用multicast）
1.Windows
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.cmd启动注册服务中心
截图：
2.MacOS
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.sh start启动注册服务中心
3.Linux
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.sh start启动注册服务中心
服务提供者
1.定义服务接口(该接口需单独打包，在服务提供方和消费方共享)
DemoService.java
2.服务提供方实现接口：(对服务消费方隐藏实现)
DemoServiceImpl.java
dubbo-provider.xml：
4.加载Spring配置，启动服务：
Provider.java：
或者使用springBoot启动
服务消费者：
applicationContext-dubbo.xml 中注册自己需要调用的接口。
1.通过Spring配置引用远程服务
dubbo-consumer.xml：
2.加载Spring配置，并调用远程服务：
Consumer.java
或者使用springBoot启动
并添加对应的restful接口提供接口访问
修改对应index页面
3.dubbo管理页面：
启动后访问 http://localhost:8080/dubbo-admin/
输入账号密码root/root
应用页面：
提供者页面:
消费者页面：
服务页面：
测试是否成功，只要看状态是否正常，就ok了 ....
provider-log:
5.使用Dubbo可能遇到的问题
1、org.springframework.beans.factory.BeanCreationException
原因分析：
解决方案
2、org.apache.dubbo.rpc.RpcException
原因分析
解决方案
可能是因为providers没有启动，或者是provider对应暴露的服务被禁用，启动providers或者解除禁用即可
3、java.lang.IllegalStateException
原因分析
解决方案
总结以上两点，通俗点讲，就是重启了工程（可能是因为直接修改代码，工程reload了）， 并且，连过了数据库（登录等），才出现了上述报错信息。原因是因为在tomcat重启的时候，之前的tomcat的线程还没有完全关闭，最新启动tomcat就会报这个异常。
4、org.apache.dubbo.remoting.TimeoutException
原因分析
解决方案
在dubbo-provider.xml增加超时时间

Dubbo简介

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文件时，通过

这个配置指定消费者端要加载的过滤器，通过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、指定某一个服务

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

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）添加依赖

????????

? ? ? ?

? ? ? ? ? ?

com.alibaba.boot

? ? ? ? ? ?

dubbo-spring-boot-starter

? ? ? ? ? ?

0.1.0

? ? ? ?

? ? ? ?

? ? ? ?

? ? ? ? ? ?

com.101tec

? ? ? ? ? ?

zkclient

? ? ? ? ? ?

0.10

? ? ? ?

（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、InvokerInvocationHandler jdk动态代理
5、RegistryDirector返回Invokers Router分为：Script 脚本路由、Condition 条件路由
6、通过MockInvokersSelector的route方法（getNormalInvokers）拿到能正常执行的invokers
8、当回到AbstractClusterInvoker后，执行（默认FailoverClusterInvoker，根据配置的是，Failfast Cluster(快速失败) , Failsafe Cluster(失败安全) , Failback Cluster(失败自动恢复) , Forking Cluster(并行调用多个服务器，只要一个成功即返回) , Broadcast Cluster(广播调用所有提供者，逐个调用，任意一台报错则报错)）doInvoker方法
9、FailoverClusterInvoker调用AbstractClusterInvoker的select方法
10、执行doSelect方法
11、调用AbstractLoadbalance的select方法
12、根据配置的负载均衡策略调用对应的（如RoundRobinLoadBalance）类的doSelect方法
13、返回invokers.get()方法
14、调用FailoverClusterInvoker的invoke方法
均继承自抽象类AbstractDirectory
Directory 获取 invoker 是从 methodInvokerMap 中获取的，主要都是读操作,那它的写操作是在什么时候写的呢?就是在回调方法 notify 的时候操作的，也就是注册中心有变化,则更新 methodInvokerMap 和 urlInvokerMap 的值
根据dubbo-admin配置的路由规则来过滤相关的invoker，当我们对路由规则点击启用，就会触发 RegistryDirectory 类的 notify 方法。
notify方法调用refreshInvoker方法。
route方法的实现类为ConditionRoute 根据条件进行过滤
1、调用mathThen方法
2、调用matchCondition方法
3、调用isMatch判断
4、调用isMatchGlobPattern方法
? 集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是Dubbo Cluster集群的作用。
通过cluster来指定集群容错方式
其实就是应对出错情况采取的策略
用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非提供者挂了，再连另一台，自动开启延迟链接，以减少长接数
? 启动时服务提供者将当前进程启动时间注册到ZK；服务消费者发现该节点后计算服务启动时间（相对当前时间），在默认预热时间的前20%时间内，该节点权重始终固定为2，这样客户端的负载均衡器只会分发极少的请求至节点。
? 在预热时间之后的80%时间内，该节点权重将随着时间的推移而线性增长；待预热时间到期后，权重自动恢复为默认值100；负载均衡器的内核是一个标准的WLC算法模块，即加权最少连接算法；
? 如果某个节点Hang住或宕机，其权重会迅速自动调节降低，避免持续性影响；当节点下线时，服务端提前触发权重调节，重载默认权重至1并发布到注册中心，服务消费者将迅速感知到该事件； 服务提供者优雅下线步骤（注意这套逻辑仅在服务端执行）在ok.htm?down=true对应的controller中加入下列逻辑，注意要判断down是否为true，因为正常来说false表示启动验证而不是关机
服务者消费者配置
dubbo服务支持参数动态调整，例如动态调整权重，但dubbo实现方式较为特殊，并不是常规思路。
? ServiceConfig类拿到对外提供服务的实际类ref，然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转换（javassistProxyFacory、JdkProxyFactory），接着要做Invoker转换到Export的过程
? 服务发布：本地暴露、远程暴露
? 为什么会有 本地暴露 和 远程暴露 呢?不从场景考虑讨论技术的没有意义是.在dubbo中我们一个服务可能既是 Provider ,又是 Consumer ,因此就存在他自己调用自己服务的情况,如果再通过网络去访问,那自然是舍近求远,因此他是有 本地暴露 服务的这个设计.从这里我们就知道这个两者的区别
1、spring启动，解析配置文件
2、创建dubbo标签解析器
3、解析dubbo标签
4、ServiceBean解析
5、容器创建完成，触发ContextRefrestEvent
6、export暴露服务
7、duExportUrls
8、doExportUrlsFor1Protocol
9、getInvoker
10、protocol.export
11、开启服务器 openServer()如nettyServer
12、注册服务到注册中心 registerProvider
Filter 在服务暴露前，做拦截器初始化，在加载所有拦截器时会过滤支队provider生效的数据。
可以。zookeeper的信息会缓存到本地作为一个缓存文件,并且转换成 properties 对象方便使用。建立线程池，定时检测并连接注册中心，失败了就重连。
注册服务到zk其实就是在zk上创建临时节点，当节点下线或者down掉时，即会删除临时节点，从而使服务从可用列表中剔除。
持久节点
临时节点
1、export的时候进行zk订阅
2、设置监听回调的地址，回调给FailbackRegistry的notify
3、创建持久节点
4、设置对该节点的监听
5、更新新的服务信息，服务启动和节点更新回调，都会调用到这里
6、更新缓存文件
7、对比新旧信息是否有变化，有则重新暴露服务
高并发大业务量情况下，暂时屏蔽边缘业务
MockClusterInvoker
? SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。

Dubbo服务注册与动态发现机制的原理与实现细节

总结一下服务注册与发现机制：
基于注册 中心的事件通知（订阅与发布），一切支持事件订阅与发布的框架都可以作为Dubbo注册中心的选型。

1、服务提供者在暴露服务时，会向注册中心注册自己，具体就是在${service interface}/providers目录下添加 一个节点（临时），服务提供者需要与注册中心保持长连接，一旦连接断掉（重试连接）会话信息失效后，注册中心会认为该服务提供者不可用（提供者节点会被删除）。

2、消费者在启动时，首先也会向注册中心注册自己，具体在${interface interface}/consumers目录下创建一个节点。

3、消费者订阅${service interface}/ [ providers、configurators、routers ]三个目录，这些目录下的节点删除、新增事件都胡通知消费者，根据通知，重构服务调用器(Invoker)。

以上就是Dubbo服务注册与动态发现机制的原理与实现细节。

dubbo服务器线程使用情况查看

在dubbo服务器上，执行telnet可进入dubbo命令控制行：

点击回车，进入dubbo控制台

ls
显示服务列表。

ls -l
显示服务详细信息列表。

ls XxxService
显示服务的方法列表。

ls -l XxxService
显示服务的方法详细信息列表。

ps
显示服务端口列表。

ps -l
显示服务地址列表。

ps 20880
显示端口上的连接信息。

ps -l 20880
显示端口上的连接详细信息。

trace XxxService
跟踪1次服务任意方法的调用情况。

trace XxxService 10
跟踪10次服务任意方法的调用情况。

trace XxxService xxxMethod
跟踪1次服务方法的调用情况

trace XxxService xxxMethod 10
跟踪10次服务方法的调用情况。

小白也能看懂的dubbo3应用级服务发现详解

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）
提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。
在2.7.5之前，dubbo 只支持接口级服务发现模型，>=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。
本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。
开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。
dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样：
看着很乱？捋一捋：
无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面：
这个问题好解决： 拆！
dubbo 在 2.7 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中
无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。
当抹去注册信息中的 interface 信息，这样数据量就大大减少
只用过 dubbo 的同学可能觉得这很主流。
但从服务发现的角度来看：
无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。
在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。
provider端暴露服务：
consumer端引用服务：
本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法一样调用远程方法的感觉 ，这也是 dubbo 的优势。
从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。
如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。
至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。
实现 dubbo 应用级服务发现，难点在于
保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现
名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。
数据存储在哪里？显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。
且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。
本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。