dubbo源码分析

一、dubbo容错 1、配置方式 1 ）服务端设置 < dubbo : service cluster = "failsafe" retries = "2" / > 2 ）调用端设置 < dubbo : reference cluster = "failsafe" retries = "2" / > 2、FailoverClusterInvoker FailoverClusterInvoker是一种失败后，重新换其他机器重试，并设有重试次数的一种容错机制 @Override @SuppressWarnings ( { "unchecked" , "rawtypes" } ) public Result doInvoke ( Invocation invocation , final List < Invoker < T > > invokers , LoadBalance loadbalance ) throws RpcException { List < Invoker < T > > copyinvokers = invokers ; // 对 copyinvokers 进行判空检查 checkInvokers ( copyinvokers , invocation ) ; //获取重试次数，如果参数没配，默认是2次，再加上第一次调用，总共调用3次 int len =

服务目录 服务目录对应的接口是Directory，这个接口里主要的方法是 List<Invoker<T>> list(Invocation invocation) throws RpcException; 列出所有的Invoker，对于服务消费端而言，一个Invoker对应一个可用的服务提供者，底层封装了一个tcp连接。当然Invoker也可以是嵌套的，一个Invoker内包含了多个实际的Invoker。通过Cluster对象将一个服务目录封装成一个Invoker，内部包含了故障转移，服务路由，负载均衡，等等相关的集群逻辑。 回到服务目录，主要包括两种服务目录，StaticDirectory，RegistryDirectory。 StaticDirectory。静态服务目录，顾名思义，这个目录在创建的时候就会通过构造方法传进一个Invoker列表，在之后过程中这个列表不再变化。 RegistryDirectory。通过监听注册中心的服务提供者信息动态更新Invoker列表的服务目录。 从上节服务引入，我们知道，不论是StaticDirectory还是RegistryDirectory，最终都会通过Cluster.join方法封装为一个Invoker。由于静态服务目录的逻辑很简单，这里不再赘述，本节我们主要分析一下注册中心的服务目录。 RegistryDirectory概述

1、好多公司动不动就JVM、高并发、分布式、微服务等等，我没有实际经验。 2、从事Java开发三年了，目前的职位是高级Java工程师，感觉技术和工资都到了瓶颈，对以后的发展方向有些迷茫。 3、加班时间过长，年龄大了，精力严重不够，竞争力远不如年轻程序员了。 4、Java工程师体量庞大，供大于需，导致Java程序员面临更加激烈的竞争。 5、目前做技术管理，薪资25K，但25K基本是天花板了，不甘心。 　　在我看来，开发三年甚至五六年以上的Java程序员要解决上面的问题无非就是两个层面： 1、技术经验 　　在技术经验方便，个人感觉你要想有所突破，首先就要形成一套技术体系，从技术的实现原理到技术应用，再到不同技术的优劣比较。因为当前各大公司使用的如火如荼的技术栈，无怪乎那些你已经曾经使用过的东西，只是你需要在这个基础上，让自己更有深度和见解。 2、业务需求能力 　　在业务需求能力方面，一个公司除了看重技术积累方面，另外还比较注重个人的业务理解和分析能力，如果你在某个领域的业务能力比较强，能够hold住当前的一个业务架构，这样说明你对业务的理解能力是非常到位的。所以在业务方便，首先需要的是结合场景的个人理解，其次是延伸扩展。 　　裁员并不可怕，没有技术实力才可怕，真正有实力的人不会被埋没。真正有实力的人才能走的更远飞的更高。当你具备这些能力时，你不用担心裁员而是应该考虑我要不要继续留在

dubbo提供了四种配置方式: 1. api配置 2. 属性配置 3. xml配置 4. 注解配置 配置一览: 配置之间的关系如下所示: 分为四个部分: 1. application-shared 2. provider-side 3. consumer-side 4. sub-config 先来看一段官方给的消费者的初始化代码: //当前应用配置 ApplicationConfig application = new ApplicationConfig(); application.setName( "yyy" ); //注册中心配置 RegistryConfig registry = new RegistryConfig(); registry.setAddress( "10.20.130.230:9090" ); registry.setUsername( "aaa" ); registry.setPassword( "bbb" ); //链接远程服务,内部封装了和注册中心以及远程服务的链接 ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); reference .setApplication(application); reference .setRegistry

简介 首先，先来介绍一下服务目录是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。 Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的，标签路由暂未在我所分析的 2.6.4 版本中提供，该实现会在 2.7.0 版本中提供。本篇文章将分析条件路由相关源码，脚本路由和标签路由这里就不分析了。下面进入正题。 2. 源码分析 条件路由规则有两个条件组成，分别用于对服务消费者和提供者进行匹配。比如有这样一条规则： host = 10.20.153.10 => host = 10.20.153.11 该条规则表示 IP 为 10.20.153.10 的服务消费者 只可 调用 IP 为 10.20.153.11 机器上的服务，不可调用其他机器上的服务。条件路由规则的格式如下： [服务消费者匹配条件] => [服务提供者匹配条件] 如果服务消费者匹配条件为空，表示不对服务消费者进行限制。如果服务提供者匹配条件为空，表示对某些服务消费者禁用服务。 Dubbo 官方文档对条件路由进行了比较详细的介绍，大家可以参考下，这里就不过多说明了。 条件路由实现类 ConditionRouter

提供端分析 服务提供者在起动时，会执行到DubboProtocol.export，生成DubboExporter对象，并放入exportMap中。 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException { URL url = invoker.getUrl(); // export service. String key = serviceKey(url); DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap); exporterMap.put(key, exporter); //export an stub service for dispaching event Boolean isStubSupportEvent = url.getParameter(Constants.STUB_EVENT_KEY,Constants.DEFAULT_STUB_EVENT); Boolean isCallbackservice = url.getParameter(Constants.IS_CALLBACK_SERVICE, false); if (isStubSupportEvent &&

from： https://www.cnblogs.com/cyfonly/p/8987043.html 文是针对 Dubbo 协议调用的调优指导，详细说明常用调优参数的作用域及源码。 Dubbo调用模型 常用性能调优参数 参数名 作用范围 默认值 说明 备注 threads provider 200 业务处理线程池大小 iothreads provider CPU+1 io线程池大小 queues provider 0 线程池队列大小，当线程池满时，排队等待执行的队列大小， 建议不要设置，当线程程池时应立即失败， 重试其它服务提供机器，而不是排队，除非有特殊需求 acceptes provider 0 服务提供方最大可接受连接数 0表示不限制 executes provider 0 服务提供者每服务每方法最大可并行执行请求数 0表示不限制 connections consumer 0 对每个提供者的最大连接数， rmi、http、hessian等短连接协议表示限制连接数， Dubbo等长连接协表示建立的长连接个数 Dubbo协议默认共享一个长连接 actives consumer 0 每服务消费者每服务每方法最大并发调用数 0表示不限制 源码及原理分析 >> threads FixedThreadPool.java public Executor getExecutor(URL

核心类图 该图是包含了dubbo-registry-api和dubbo-registry-default两个模块整合的简化类图，只描述了核心的类与类的关系，为了清晰明了，去除了方法和属性的描述，也忽略了类所处的包，将其放在一个类图中。 注册中心核心的职责就是注册和注销URL，订阅和取消订阅URL，还有包括查询符合条件的已注册的URL列表等职责，类图中的接口和类就是围绕核心职责的实现。 核心源码分析 RegistryProtocol 该类是注册中心的协议，即协议名称为registry的协议。这是整个注册中心启用的入口，通过该类整合了Protocol、Cluster、Directory 和Registry这几个组件。因此它作为入口我们非常有必有学习它的源码。 当我们在配置发布服务和引用服务的时候，若配置使用了注册中心，则会将原来的URL替换为一个protocol名称为registry的URL，并且会保留原始的URL在新的URL参数中。则通过dubbo的SPI机制获取到的Protocol接口的实现类便是RegistryProtocol，因此变回进入到该类的核心方法中，我们一起来看看这些核心方法的源码实现。 发布服务方法export public <T> Exporter<T> export(final Invoker<T> originInvoker) throws