探索分布式服务框架Dubbo7：Dubbo高级特性剖析

Dubbo剖析-服务直连

2018年03月15日 12:37:30

阅读数：57

一、前言

为了方便开发及测试，一般需要绕过注册中心，只测试指定ip的服务提供者，这时候服务消费方和服务提供方就是点对点直联方式。这时候服务消费方会忽略注册中心的提供者列表。另外直连方式以服务接口为单位，假如A 接口配置点对点，不影响 B 接口从注册中心获取列表。

二、直连方法

• 通过-D参数指定 
  在服务消费进程启动时候 JVM 启动参数中加入-D参数映射服务地址 ，如： 
  -Dcom.test.UserServiceBo=dubbo://30.8.59.182:20880；则标示当调用com.test.UserServiceBo接口时候访问30.8.59.182:20880提供的服务，忽略zk发现列表。
• 通过 XML 配置 
  如果是XML方式点对点，可在 中配置 url 指向提供者，将绕过注册中 
  心，多个地址用分号隔开，配置如下： 
• 通过文件映射 
  如果服务比较多，也可以用文件映射，用 -Ddubbo.resolve.file 指定映射文件路径，此配置优先级高于 中的配置 ，如： 
  java -Ddubbo.resolve.file=xxx.properties 
  然后在映射文件 xxx.properties 中加入配置，其中 key 为服务名，value 为服务提供者 
  URL： 
  com.test.UserServiceBo=dubbo://30.8.59.182:20880

注:为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。

Dubbo剖析-服务分组与服务版本号

2018年03月17日 16:47:41

阅读数：157

一、前言

在Dubbo中接口类并不能唯一确定一个服务，在dubbo中接口+服务分组+版本号才能唯一确定一个服务，本文就来讲解下服务分组和版本号的使用。

二、服务分组

当一个接口有多种实现时，可以用 group 区分。 
- 服务提供方： 

上面配置在服务提供方法提供了com.test.UserServiceBo接口的两套实现，服务分组分别为olddubbo,newdubbo。

• 服务消费方 
  

上面配置在服务消费方消费com.test.UserServiceBo接口的两套实现，服务分组分别为olddubbo,newdubbo。

需要注意的是消费方只能消费与自己服务分组相同的提供方的服务，这里userServiceOld生成的是服务提供方分组为olddubbo的接口的代理。 
userServiceNew生成的是服务提供方分组为newdubbo的接口的代理。

三、服务版本

当同一个服务分组的接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。 
可以按照以下的步骤进行版本迁移： 
1. 在低压力时间段，先升级一半提供者为新版本 
2. 再将所有消费者升级为新版本 
3. 然后将剩下的一半提供者升级为新版本

比如：

• 服务提供方

服务提供方法在分组dubbo下提供了两个版本号的服务

• 服务消费方

同理需要注意的是服务消费方只能消费与自己接口+分组+版本一致的服务提供方的服务。

四、总结

dubbo中唯一确定一个服务的是接口+服务分组+版本号，服务提供方和消费方提供和消费服务时候显示的配置服务分组和版本号是一个最佳实践。

Dubbo剖析-服务消费端异步调用

原创： 加多 技术原始积累 3月13日

一、前言

前面我们讲解的无论是正常调用还是泛化调用也好，都是进行同步调用的，也就是服务消费方发起一个远程调用后，调用线程要被阻塞挂起，直到服务提供方返回。本节来讲解下异步调用，异步调用是指服务消费方发起一个远程调用后，不等服务提供方返回结果，调用方法就返回了，也就是当前线程不会被阻塞，这就允许调用方同时调用多个远程方法。

二、服务端异步调用实例

image.png

可以测试下在sayHello和sayHello2方法内sleep 2s，然后执行调用，会发现输出为costs:2这说明调用方的sayHello和sayHello2是并发调用的，因为如果是串行的话会输出costs:4.

三、总结

异步调用是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。后期会在本公众号 '技术原始积累' 的精品区下分析dubbo异步实现原理，敬请期待。

Dubbo剖析-服务消费端泛化调用

原创： 加多 技术原始积累 3月12日

一、前言

前面我们讲解基于Spring和基于dubbo api方式搭建一个简单的分布式系统时候服务消费端是引入了一个sdk的，这个SDK是个二方包，里面存放了服务提供端提供的所有接口类以及接口使用的入参和出参的pojo类，服务消费端则使用JDK代理对接口进行代理。

泛化接口调用方式主要用于服务消费端没有 API 接口类及模型类元（比如入参和出参的pojo类）的情况，参数及返回值中的所有POJO 均用 Map 表示。

二、服务端泛化调用实例

image.png

三、总结

泛化调用通常用于框架集成，比如：实现一个通用的服务测试框架，可通过
GenericService 调用所有服务实现。后期会在本公众号 '技术原始积累' 的精品区下分析dubbo泛化实现原理，敬请期待。

Dubbo剖析-负载均衡

一、前言

在服务提供方是集群的时候，为了避免大量请求一直落到一个或者几个服务提供方机器上，从而使这些机器负载很高，甚至打死，需要做一定的负载均衡策略。Dubbo 提供了多种均衡策略，缺省为 random 随机调用

二、dubbo负载均衡策略

• Random LoadBalance 随机策略
  按权重设置随机概率。
• RoundRobin LoadBalance 轮询策略
  轮循，按公约后的权重设置轮循比率
• LeastActive LoadBalance 最少活跃调用数
  最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差
• ConsistentHash LoadBalance 一致性hash策略
  一致性 Hash，相同参数的请求总是发到同一提供者。
  当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

三、 何时加载负载均衡策略

四、总结

dubbo提供了几种常见的负载均衡策略，如果您需要定制自己额负载均衡策略，可以按照dubbo的规范进行定制化，比如你可以定制均匀一致性hash对dubbo的一致性hash进行改良。

Dubbo剖析-集群容错

原创： 加多 技术原始积累 4月2日

一、前言

在进行系统设计时候，不仅要考虑正常逻辑该如何走，还要考虑异常逻辑。dubbo中当服务消费方调用服务提供方的服务出现错误时候，提供了多种容错方案，缺省为 failover 重试。

二、Dubbo集群容错模式

• Failover Cluster
  重试。当服务消费方调用服务提供者失败后自动切换，重试其它服务提供者。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
  <dubbo:reference retries="2" />

• Failfast Cluster
  快速失败。当服务消费方调用服务提供者失败，失败立即报错。通常用于非幂等性的写操作。

• Failsafe Cluster
  失败安全。出现异常时，直接忽略。通常用于写入审计日志等操作。

• Failback Cluster
  失败自动恢复。后台记录失败请求，并按照一定的策略后期在进行重试。通常用于消息通知操作。

• Forking Cluster
  并行调用多个服务提供者的服务，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

• Broadcast Cluster
  广播调用所有服务提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息

三、原理

3.1何时加载集群容错扩展实现类

image.png

3.2 FailoverClusterInvoker原理