首发网址:Dubbo--详解_IT利刃出鞘的博客-CSDN博客_dubbo系列
简介
本文介绍Dubbo的一些使用细节。
常用配置
启动时检查,集群容错模式,负载均衡策略,直连提供者,多协议,服务分组,多版本,结果缓存,异步调用,隐式参数,参数回调,事件通知,本地伪装(服务降级),并发控制,粘滞连接。
过半机制
另见:《从Paxos到Zookeeper 分布式一致性原理与实践》=> 7.6 Leader选举
2n+1台server,只要过半(大于等于n+1台)就可以使用。也就是你说的少于一半集群就无效了。
Zookeeper宕机
如果ZooKeeper宕机对我们的服务提供者消费者有什么影响?
现象:ZooKeeper注册中心宕机,还可以消费Dubbo暴露的服务。
原因:
启动Dubbo时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用。
- 监控中心宕掉不影响使用,只是丢失部分采样数据
- 数据库宕掉后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务
- 注册中心对等集群,任意一台宕掉后,将自动切换到另一台
- 注册中心全部宕掉后,服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态,任意一台宕掉后,不影响使用
- 服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复
高可用:通过设计,减少系统不能提供服务的时间
例子:
我们在消费者中睡眠20秒,然后我们在这20秒时间内停掉注册中心,看看第二次消费能否成功。
public class App
{
public static void main( String[] args ) throws Exception
{
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
new String[] { "classpath:customer.xml" });
final IUserService demoService = (IUserService) context.getBean("userService");
System.out.println(demoService.getUser());
System.out.println("程序运行第一次......");
Thread.sleep(1000*20);
System.out.println(demoService.getUser());
System.out.println("程序运行第二次......");
System.in.read();
}
}
接下来我们一次启动服务提供者 消费者 然后停掉服务注册中心
可以看到
我们的服务消费者在注册中心宕机后让然可以调用服务提供者提供的服务。但是注册中心宕机后我们不能再注册新的服务。
Dubbo直连
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直连方式,将以服务接口为单位,忽略注册中心的提供者列表,A 接口配置点对点,不影响 B 接口从注册中心获取列表。
注意 为了避免复杂化线上环境,不要在线上使用这个功能,只应在测试阶段使用。我们可以在开发的时候使用此方式进行调试。
<dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" version="1.0.0" url="dubbo://127.0.0.1:20882"></dubbo:reference>
我们启动我们的服务注册中心与服务提供者消费,发现我们的消费者并没有注册到服务注册中心,但是我们仍然可以调用服务提供者提供的服务。
我们实现了跨注册中心直连服务提供者。
服务注册中心,动态的注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和Failover, 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,服务消费者向注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外,注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者。
注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的,服务消费者可以直连服务提供者
负载均衡
在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。
负载均衡策略:
- Random LoadBalance //随机,按权重设置随机概率。
- RoundRobin LoadBalance //轮询,按公约后的权重设置轮询比率。
- LeastActive LoadBalance //最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
- ConsistentHash LoadBalance //一致性 Hash,相同参数的请求总是发到同一提供者。
接下来我们测试一下默认的随机方式
<dubbo:service interface="com.yz.dubbo.api.IUserService" ref="userService1" version="1.0.0" loadbalance="random"></dubbo:service>
我们启动多个服务提供者,并指定不同的端口号,在实现中通过来区分不同的提供者。
System.out.println("被调用了1............");
System.out.println("被调用了2............");
接下来我们启动多个服务提供者来模拟,并通过Admin控制台中的 倍权 半权 来调节权重 ,结果如下
接下来我们启动服务消费者模拟消费者多次消费,我们模拟了六次可以看到控制台输出
被调用了0............
被调用了0............
被调用了1............
被调用了0............
被调用了0............
被调用了0............
实现了调用多个服务提供者,并实现了负载均衡。
服务降级
当服务器的压力比较大的时候,我们可以通过服务降级功能 临时屏蔽某个出错的非关键服务,并定义降级后的返回策略,屏蔽掉不重要的服务如广告服务等,来降低核心业务的压力。
- mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
- mock=fail:return+null 表示消费方对该服务的方法调用在失败后,再返回 null 值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
我们可以直接在Admin控制台来操作服务降级,服务消费者中的屏蔽相当于不发起远程调用,
容错相当于对该服务的方法调用在失败后,再返回 null 值
屏蔽
我们屏蔽我们的应用yzcustomer
发现提供者并没有调用且返回null
容错
我们容错我们的应用yzcustomer,并手动使我们的提供者出错,启动服务提供者和消费者
发现在调用服务提供者出错时,返回null
集群容错
在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。
Failover Cluster
失败自动切换,当出现失败,重试其它服务器 。通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />
Dubbo安全机制
Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。
其他网址
dubbo高可用之zookeeper宕机、Dubbo直连、负载均衡、服务降级、集群容错_java_Code The Future-CSDN博客
dubbo高可用之zookeeper宕机、Dubbo直连、负载均衡、服务降级、集群容错_java_Code The Future-CSDN博客
http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html