Dubbo高可用场景
为了保持程序7x24小时进行运行，我们需要保证程序的稳定性和高可用性
zookeeper 宕机和dubbo直连
- 监控中心宕机不影响使用，但是丢失部分数据
- 数据库宕机仍然能通过缓存提供查询
- 注册中心集群有一台宕机，自动切换
- 注册中心全部宕机，仍能通过本地缓存通信
- 服务提供者无状态，宕机一台，不影响其他服务
- 服务全宕机，讲无限次重连，等待恢复
服务直连
@Reference(url="127.0.0.1:20880")
没用注册中心的情况下也能调用服务
负载均衡
Random LoadBalance
按照权值随机访问
Dubbo默认使用随机的负载均衡机制
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮询 ，可以加上权重
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃数
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性哈希，相同参数的请求总是发到同一提供者
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
实验设计
在Spring boot配置好的基础上进行实验
配置三台服务提供者
使用三个服务提供者，对配置进行更改
#第一台
dubbo:
protocol:
name: dubbo
port: 20880
#第二台
dubbo:
protocol:
name: dubbo
port: 20881
#第三台
dubbo:
protocol:
name: dubbo
port: 20882
保证端口号不一样，并且保证名称不同
对服务实现进行略微的修改
public User findUserById(String id) {
System.out.println("调用了服务------ 1");
return UserServiceImpl.userMap.get(id);
}
以此类推，启动服务
此时应该能看见三个应用同时注册了同一个服务
启动消费者服务，发现调用是随机的
尝试更改策略
配置负载均衡的位置有四个
-
配置到服务端 <dubbo:service interface="..." loadbalance="roundrobin" /> -
配置到客户端 <dubbo:reference interface="..." loadbalance="roundrobin" /> -
配置到服务端方法 <dubbo:service interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:service> -
配置到客户端方法 <dubbo:reference interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:reference>我选择进行最简单的消费者端配置
@Reference(loadbalance = "roundrobin") UserService userService;再次进行实验
服务是轮流被dubbo调用的
服务降级
当服务器压力剧增的情况下，根据实际业务的情况和流量，对一些服务和页面有策略的不处理或换种简单的方式进行处理，从而释放服务器资源以保证核心交易正常运作或高效运作
Dubbo支持两种服务降级
- 直接屏蔽服务，直接返回为null
- 调用超时后返回为空
集群容错
Dubbo对集群容错提供了多种策略
- Failover
- Failfast
- Failsafe
- Failback
- Forking
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
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
类似于同步的效果
集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />
整合hystrix进行容错
配置spring-cloud-starter-netflix-hystrix
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
再在主启动类启用hystrix功能
@EnableHystrix
在方法实现上使用注解
@HystrixCommand
public User findUserById(String id) {
System.out.println("调用了服务------ 1");
return UserServiceImpl.userMap.get(id);
}
在消费者端也导入依赖
开启服务容错，在调用的时候时候继续加上注解
@RequestMapping("/consume")
@HystrixCommand(fallbackMethod = "hello")
public String consume()
{
User user = userService.findUserById("1");
return user.getUserName()+"订购了一些东西";
}
如果方法调用出错，就会调用某些方法，比如说我这里写的hello方法