Dubbo——高可用

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/rubulai/article/details/84946818

  高可用就是通过设计和调整服务的架构来减少系统不能提供服务的时间，使系统能够7*24小时不间断地提供服务。
一、zookeeper宕机与dubbo直连
 1、zookeeper宕机
  在服务提供者和服务消费者都启动起来之后，如果注册中心宕机了并不会影响在宕机之前注册的服务，这个时候消费者依然能够正常的调用服务提供者提供的服务。这是因为，服务消费者启动之后会从注册中心获取服务地址列表，并缓存至本地，注册中心宕机并不会影响消费者端本地的缓存。但宕机之后服务提供者暴露的服务消费者是没有办法调用的，除非使用dubbo直连的方式绕过注册中心。
 2、dubbo直连
  注册中心的作用是保存服务提供者所在的位置信息，如果我们知道服务提供者的地址信息的话，就可以完全绕过注册中心，使用dubbo直连的方式来调用服务提供者暴露的服务，这样即使没有注册中心也是可以的。
  示例：此时即使在两端启动之前zookeeper宕机也不会影响接口调用
   服务端：

<dubbo:protocol name="dubbo" port="20882"></dubbo:protocol>

   或者使用代码配置：

@Bean
public ProtocolConfig protocolConfig(){
	ProtocolConfig config = new ProtocolConfig();
	config.setPort(20882);
	config.setName("dubbo");
	return config;
}

   消费端：通过@Reference的url属性明确服务端地址

@Service//是spring的@Service注解而非dubbo的
public class OrderServiceImpl implements OrderService {

	@Reference(check=false,url="127.0.0.1:20882")//使用直连的方式绕过注册中心
	UserService userService;

	/**
	 * 初始化订单
	 */
	public List<UserAddress> initOrder(String userId) {
		// 查询用户的收货地址,需要调用用户服务
		return userService.getUserAddressList(userId);
	}
}

 另外：
  ①监控中心宕掉不影响使用，只是丢失部分采样数据
  ②数据库(指注册中心使用的数据库)宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
  ③注册中心若为集群，任意一台宕掉后，将自动切换到另一台
  ④注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
  ⑤服务提供者无状态，任意一台宕掉后，不影响使用
  ⑥服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

二、负载均衡机制
  在集群模式下，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。
 1、基于权重的随机负载均衡

  随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。可通过将性能好的机器的权重调大来提升整体性能。
 2、基于权重的轮询负载均衡

  轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。可通过将性能好的机器的权重调大来提升整体性能。
 3、最少活跃数负载均衡

  最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数(时间计数)差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
 4、一致性Hash负载均衡

  一致性 Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂掉时，原本发往该提供者的请求，会基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。算法参见。缺省只对第一个参数 Hash，如果要修改，请配置：

<dubbo:parameter key="hash.arguments" value="0,1" />

  缺省用 160 份虚拟节点，如果要修改，请配置：

<dubbo:parameter key="hash.nodes" value="320" />

 负载均衡的实现：

 测试：
  ①需要启动注册中心，且不能使用dubbo直连的方式
  ②启动多个服务提供者(eclipse中运行多次服务提供者的main()，注意修改暴露服务的dubbo端口)
  负载均衡机制的配置可以参见官方文档：负载均衡配置，可以在服务端配置，也可以在客户端配置，服务的权重可以在暴露服务时通过@Service(Dubbo的@Service)的weight属性配置，也可以通过dubbo提供的控制台来调整：

 示例：在消费端配置，loadbalance 有4个可选值(random、roundrobin、leastactive、consistenthash)

@Reference(loadbalance = "roundrobin") // 使用基于权重的轮询负载均衡
UserService userService;

三、服务降级
  在服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。也就是通过牺牲非核心业务的正常调用来释放资源使核心业务正常运转。
  服务降级有两种方式：服务屏蔽和服务容错
   ①mock=force:return+null(服务屏蔽) 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响
   ②mock=fail:return+null(服务容错) 表示消费方对该服务的方法调用在失败(比如超时)后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响，服务在设置为容错时不会出现异常信息，否则在出现异常时前端会出现异常信息，可以将非核心业务的服务的超时时间设置的短一些，并设置为服务容错，这样就可以避免因非核心业务浪费系统资源了
  示例：可通过管理控制台在消费者端进行设置，设置之后可以恢复
四、集群容错
  在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。
 1、集群容错模式

模式	描述	备注
Failover Cluster	失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)	重试次数配置如下： <dubbo:service retries=“2” /> 或 <dubbo:reference retries=“2” /> 或<dubbo:reference ><dubbo:method name=“findFoo” retries=“2” /></dubbo:reference>
Failfast Cluster	快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录
Failsafe Cluster	失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作
Failback Cluster	失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作
Forking Cluster	并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数
Broadcast Cluster	广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息

 2、集群容错模式配置：按照以下示例在服务提供方和消费方配置集群容错模式

<dubbo:service cluster="failsafe" />

或

<dubbo:reference cluster="failsafe" />

 3、整合hystrix(在开发中使用的集群容错方案，不使用2的方式)
  ①导入依赖：服务方和消费方都需要引入该启动器

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
	<version>1.4.4.RELEASE</version>
</dependency>

  ②启用hystrix：服务方和消费方都需要启用，方式为在SpringBoot的主配置类中使用@EnableHystrix注解

@EnableHystrix
@SpringBootApplication
public class ProviderApplication {
	...
}

  ③在服务提供方的实现方法上添加注解@HystrixCommand：这样该方法就会被Hystrix代理，我们这里随机抛出异常

@Component
@Service //此注解是dubbo的暴露服务注解
public class UserServiceImpl implements UserService {

	@HystrixCommand
	public List<UserAddress> getUserAddressList(String userId) {
		System.out.println("UserServiceImpl...3...");
		UserAddress address1 = new UserAddress(1, "北京市昌平区宏福科技园综合楼3层", "1", "李老师", "010-56253825", "Y");
		UserAddress address2 = new UserAddress(2, "深圳市宝安区西部硅谷大厦B座3层（深圳分校）", "1", "王老师", "010-56253825", "N");
		if(Math.random() > 0.5)
			throw new RuntimeException();
		return Arrays.asList(address1, address2);
	}
}

  ④在服务消费方调用服务方法的方法上也使用@HystrixCommand注解，并使用属性fallbackMethod指定服务方法调用异常时的回调方法，我们可以在此回调方法中返回模拟数据给前端，也可以在此提供更友好的提醒信息给前端

@Service // 是spring的@Service注解而非dubbo的
public class OrderServiceImpl implements OrderService {

	@Reference(loadbalance = "roundrobin") 
	UserService userService;

	/**
	 * 初始化订单
	 */
	@HystrixCommand(fallbackMethod="callback")
	public List<UserAddress> initOrder(String userId) {
		// 查询用户的收货地址,需要调用用户服务
		return userService.getUserAddressList(userId);
	}
	
	/**
	 * 服务调用失败的回调方法
	 * @param userId
	 * @return
	 */
	public List<UserAddress> callback(String userId) {
		return Arrays.asList(new UserAddress(10, "测试地址", "1", "测试", "测试", "Y"));
	}
}

  测试：会随机的出现这种结果，因为在服务方法中我们生成的随机数可能大于0.5