一.URL简介 URL也就是Uniform Resource Locator,中文叫统一资源定位符.Dubbo中无论是服务消费方,或者服务提供方,或者注册中心.都是通过URL进行定位资源的.所以今天来聊聊Dubbo中的统一URL资源模型是怎么样的. 二.Dubbo中的URL 标准的URL格式如下: protocol://username:password@host:port/path?key=value&key=value 在Dubbo中URL也是主要由上面的参数组成. public URL(S

  http://blog.csdn.net/zhiguozhu/article/details/50517513 背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进 单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键 垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,

最近维护的系统切换了网络环境,由联通换成了电信网络,因为某些过滤规则导致系统连不上zookeeper服务器(应用系统机器在深圳,网络为电信线路,zookeeper服务器在北京,网络为联通线路),因为我不是运维人员也不懂运维相关的技术,所以排查了很久也不知道原因,最后无奈之下把深圳这边的网络切回了联通,系统恢复正常. 但是因为本次事故体现了一个很严重的问题,即当zookeeper注册中心连不上时dubbo的线程会无限等待,因为系统有一些定时任务会比较频繁地开启新线程连接dubbo,所以导致的结果是

(facebook) thrift / (hadoop) avro / (google) probuf(grpc)是近几年来比较抢眼的高效序列化/rpc框架,dubbo框架虽然有thrift的支持,但是依赖的版本较早,只支持0.8.0,而且还对协议做一些扩展,并非原生的thrift协议. github上虽然也有朋友对dubbo做了扩展支持原生thrift,但是代码实在太多了,只需要一个类即可: Thrift2Protocal.java: package com.alibaba.dubbo.rpc

我们将上面开发的服务提供方服务,部署到2个独立的节点上(192.168.14.1和10.10.4.125),然后可以通过Dubbo管理中心查看对应服务的状况,如图所示: 上图中可以看出,该服务有两个独立的节点可以提供,因为配置的集群模式为failover,如果某个节点的服务发生故障无法使用,则会自动透明地重试另一个节点上的服务,这样就不至于出现拒绝服务的情况.如果想要查看提供方某个节点上的服务详情,可以点击对应的IP:Port链接,示例如图所示: 上图可以看到服务地址 dubbo://10.10

dubbo源码分析1-reference bean创建 dubbo源码分析2-reference bean发起服务方法调用 dubbo源码分析3-service bean的创建与发布 dubbo源码分析4-基于netty的dubbo协议的server dubbo源码分析5-dubbo的扩展点机制 dubbo提供了telnet的方式,直接用命令查看服务信息等.怎么实现的呢. 1. 编解码器 com.alibaba.dubbo.remoting.transport.netty.NettyCodecA

java实现dubbo的消费者服务编写:ruby实现消费者服务的接口测试:通过消费者间接测试dubbo服务接口的逻辑 内容包括:dubbo服务本地调用环境搭建,dubbo服务启动,消费者部署,脚本编写测试 自动化测试框架逻辑如下图: 一.dubbo服务本地环境搭建: zookeeper部署: http://www.apache.org/dyn/closer.cgi/zookeeper/ 下载 直接解压: 修改配置文件:conf/zoo_sample.cfg 变更为zoo.cfg;打开文件配置需要

part -- 外挂1.dubbo借助spring的schema启动和初始化 1.1 spring扫描所有jar下META-INF的spring.handlers和spring.schemas. 1.2 运行spring.handlers下定义的DubboNamespaceHandler的init方法. 1.3 spring加载xml,执行DubboBeanDefinitionParser的parse方法,通过RootBeanDefinition将serviceBean暴露给spring.(实际

dubbo是阿里巴巴公司开发的一个开源分布式应用框架,基于服务的发布者和订阅者,服务者启动服务向注册中心发布自己的服务:消费者(订阅者)启动服务器向注册中心订阅所需要的服务.注册中心将订阅的服务注册列表返回给订阅者.注册中心会感应服务的提供者的变化,如果服务的提供者发生变化,注册中心会立即通知消费者及时变更服务信息数据:dubbo并且带有审计功能--监控中心,服务的发布者和服务的消费者每分钟间隔都会向监控中心发送自己的统计情况如:调用次数 或者调用时间等(这些数据是保存在内存中以每分钟为单位向监

Dubbo是Alibaba开源的分布式服务框架,我们可以非常容易地通过Dubbo来构建分布式服务,并根据自己实际业务应用场景来选择合适的集群容错模式,这个对于很多应用都是迫切希望的,只需要通过简单的配置就能够实现分布式服务调用,也就是说服务提供方(Provider)发布的服务可以天然就是集群服务,比如,在实时性要求很高的应用场景下,可能希望来自消费方(Consumer)的调用响应时间最短,只需要选择Dubbo的Forking Cluster模式配置,就可以对一个调用请求并行发送到多台对等的提供方

  我们使用Dubbo时,一般都会使用xml配置基本信息,如项目名称(application).注册中心(register).协议(protocal).服务(service),如下所示: 1 2 3 4 5 6 7 <dubbo:application name="demo-provider" owner="programmer" organization="dubbox"/>   <dubbo:registry address

通常情况下是通过Spring配置的方式去实现服务的发布,为了方便调试,我就不采用Spring配置的方式. DemoService demo = new DemoServiceImpl(); ApplicationConfig config=new ApplicationConfig("hello-world-app"); RegistryConfig reg=new RegistryConfig("127.0.0.1:2181"); reg.setProtocol(

扩展点配置: 约定: 在扩展类的jar包内,放置扩展点配置文件:META-INF/dubbo/接口全限定名,内容为:配置名=扩展实现类全限定名,多个实现类用换行符分隔.(摘自dubbo文档) 示例: 假如我现在想使用自己定义的协议Myprotocol,在resources目录下新建META-INF/dubbo/com.alibaba.dubbo.rpc.Protocol目录文件,文件内容定义: myprotocol=com.selrain.MyProtocol 实现类内容: public cla

一.导论 dubbo作为阿里开发优秀的rpc服务框架,现已广泛用于各大rpc项目之间的远程通信,虽然阿里现在已经没有维护dubbo的开发,但是其结构设计也是值得学习. 二.结构简介 这部分只是简单介绍dubbo的结构图解,可能会有些复杂,但确实是dubbo设计的精髓所在. 1.各层介绍 config,配置层,对外配置接口,以ServiceConfig, ReferenceConfig为中心,可以直接new配置类,也可以通过spring解析配置生成配置类,dubbo的相关配置都是该对象在维护. p

在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用.我们还可以扩展自己的负责均衡策略,前提是你已经从一个小白变成了大牛,嘻嘻 1.Random LoadBalance 1.1  随机,按权重设置随机概率. 1.2  在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重. 1.3 源码分析 package com.alibaba.dubbo.rpc.cluster.loadbalance; import java.

转载自http://shiyanjun.cn/archives/1075.html Dubbo是Alibaba开源的分布式服务框架,我们可以非常容易地通过Dubbo来构建分布式服务,并根据自己实际业务应用场景来选择合适的集群容错模式,这个对于很多应用都是迫切希望的,只需要通过简单的配置就能够实现分布式服务调用,也就是说服务提供方(Provider)发布的服务可以天然就是集群服务,比如,在实时性要求很高的应用场景下,可能希望来自消费方(Consumer)的调用响应时间最短,只需要选择Dubbo的F

上文分析了Dubbo服务发布的整体流程,但服务代理生成的具体细节介绍得还不是很详细.下面将会接着上文继续分析.上文介绍了服务代理生成的切入点,如下: Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url); 这里的proxyFactory是在ServiceConfig中定义的,是final类型静态变量,赋值后无法进行修改.如下: private static final ProxyFactor

在Dubbo服务发布的整体流程一文中,只是分析了服务发布的整体流程,具体的细节还没有进一步分析.本节将继续分析服务暴露的过程.在ServiceConfig中通过一句话即可暴露服务,如下: Exporter<?> exporter = protocol.export(invoker); 此时Invoker对象携带的URL信息中定义的是"registry",则此处"protocol"加载的是RegistryProtocol对象.也即调用RegistryPro

Java中的SPI SPI,Service Provider Interface,java中提供的一种使程序可扩展的方式,系统定义好接口规范,供其他服务提供方实现,服务提供方将自己jar包META-INF/services下新建一个以接口全名称定义的文件,里面内容写上自己服务的实现的类名,每一行代表一个实现,服务使用方可以通过ServiceLoader.load加载所有的服务,然后判断可以使用的服务.具体可以参考reference dubbo中的SPI dubbo也使用了类似Java中的SPI机

Dubbo中的Cluster可以将多个服务提供方伪装成一个提供方,具体也就是将Directory中的多个Invoker伪装成一个Invoker,在伪装的过程中包含了容错的处理,负载均衡的处理和路由的处理.这篇文章介绍下集群相关的东西,开始先对着文档解释下容错模式,负载均衡,路由等概念,然后解析下源码的处理.(稍微有点乱,心情不太好,不适合分析源码.) 234567891011121314151617181920212223 public <T> Invoker<T> refer(C