负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。
String loadbalance() default "";
dubbo的四种负载分别是:随机(权重)、轮询(权重)、最少活跃调用数、一致性Hash。
通过服务注册中心的服务名/接口实现负载均衡。实际上gateway的负载均衡基于的是ribbon
server:
port: 8080
spring:
application:
name: gateway_server
cloud:
gateway:
default-filters:
routes:
- id: my_route
uri: lb://my-load-balanced-service
predicates:
- Path=/gateway/**
filters:
- StripPrefix=1
my-load-balanced-service:
ribbon:
listOfServers: localhost:1001, localhost:1002
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule**
# 使用了轮询的负载均衡策略。
# https://www.jianshu.com/p/cdf63185b0c3
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FDMK8kFz-1596725381127)(https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1596721489063&di=66641b845f5efbd56566eff256dccf3e&imgtype=0&src=http%3A%2F%2Fstatic.jointforce.com%2Fjfperiodical%2Fattached%2Fimage%2F20160420%2F-1451750843.png)]
nginx负载均衡基本配置
http {
upstream myapp1 {
server ip:port;
server ip:port;
server ip:port;
}
server {
listen 80;
location / {
proxy_pass http://xxx;
}
}
}
目前Nginx的upstream模块支持6种方式的负载均衡策略(算法):轮询(默认方式)、weight(权重方式)、ip_hash(依据ip分配方式)、least_conn(最少连接方式)、fair(第三方提供的响应时间方式)、url_hash(第三方通过的依据URL分配方式)。
推荐文章:
服务熔断的作用类似于我们家用的保险丝,当某服务出现不可用或响应超时的情况时,为了防止整个系统出现雪崩,暂时停止对该服务的调用。
String mock() default ""; //true(自动寻找mork实现类) fail(允许请求) default(和true一样) force(屏蔽请求)
circuitBreaker.enabled 是否开启熔断
circuitBreaker.requestVolumeThreshold 熔断最低触发请求数阈值
circuitBreaker.sleepWindowInMilliseconds 产生熔断后恢复窗口
circuitBreaker.errorThresholdPercentage 错误率阈值
circuitBreaker.forceOpen 强制打开熔断
circuitBreaker.forceClosed 强制关闭熔断
@Configuration
public class GatewayFallbackConfig {
@Autowired
private HystrixFallbackHandler hystrixFallbackHandler;
@Bean
public RouterFunction routerFunction() {
return RouterFunctions.route(
RequestPredicates.GET("/defaultfallback")
.and(RequestPredicates.accept(MediaType.TEXT_PLAIN)), hystrixFallbackHandler);
}
}
@Component
public class HystrixFallbackHandler implements HandlerFunction<ServerResponse> {
@Override
public Mono<ServerResponse> handle(ServerRequest serverRequest) {
serverRequest.attribute(ServerWebExchangeUtils.GATEWAY_ORIGINAL_REQUEST_URL_ATTR)
.ifPresent(originalUrls -> log.error("--------", originalUrls));
return ServerResponse
.status(HttpStatus.INTERNAL_SERVER_ERROR)
.contentType(MediaType.APPLICATION_JSON_UTF8)
.body(BodyInserters.fromObject(ResultData.fail("HystrixFallbackHandler")));
}
}
可以采用简单的注解配置
当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。
服务降级这个问题,如果从整体来操作,
一定是先降级优先级地的接口,两权相害取其轻
如果服务链路整体没有性能特别差的点,比如就是外部流量突然激增,那么就从外到内开始降级
如果某个服务能检测到自身负载上升,那么可以从这个服务自身做降级
第一种方式:通过dubbo-admin实现
mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后,再返回 null 值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
第二种方式:@Reference实现
@Reference(timeout = 1000) //设置超时时间
第三种方式:mork
String mock() default ""; //true(自动寻找mork实现类) fail(允许请求) default(和true一样) force(屏蔽请求)
//xxxServiceMork要和接口在一个项目中,为的是方便找到Mork类
为了防止某个消费者的QPS或是所有消费者的QPS总和突然飙升而导致的重要服务的失效,系统可以对访问流量进行控制,这种对集群的保护措施称为服务限流。
Dubbo中能够实现服务限流的方式较多,可以划分为两类:直接限流与间接限流
dubbo限流的方式:
第一种方式:executes直接限流(提供者端使用)
<dubbo:service interface="com.xxx.xxx" executes="10" />
<dubbo:service interface="com.xxx.xxx">
<dubbo:method name="xxxx" executes="10" />
dubbo:service>
第二种方式:accepts限流(提供者端使用)
<dubbo:provider protocol="dubbo" accepts="10" />
<dubbo:protocol name="dubbo" port="20880" accepts="10" />
第三种方式:actives限流(两端)
根据消费者与提供者间建立的连接类型的不同,其意义也不同
<dubbo:service interface="com.xxx.xxx" actives="10" />
<dubbo:reference interface="com.xxx.xxx">
<dubbo:method name="xxxx" actives="10" />
dubbo:service>
<dubbo:reference interface="com.xxx.xxx" actives="10" />
<dubbo:reference interface="com.xxx.xxx">
<dubbo:method name="xxxx" actives="10" />
dubbo:service>
第四种方式:connections限流(两端)
限定连接的个数。对于短连接,该属性效果与actives相同。但对于长连接,其限制的是长连接的个数。
一般情况下,会使connectons与actives联用,让connections限制长连接个数,让actives限制一个长连接中可以处理的请求个数。联用前提:使用默认的Dubbo服务暴露协议
<dubbo:service interface="com.xxx.xxx" ref="xxx" connections="10">dubbo:service>
<dubbo:service interface="com.xxx.xxx" ref="xxx">
<dubbo:method name="xxxx" connections="10">dubbo:method>
dubbo:service>
<dubbo:reference interface="com.xxx.xxx" id="xxx" connections="10">dubbo:reference>
<dubbo:reference interface="com.xxx.xxx" id="xxx">
<dubbo:method name="xxxx" connections="10">dubbo:method>
dubbo:reference>
第五种方式:延迟连接(间接限流)
仅可设置在消费者端,且不能设置为方法级别。仅作用于Dubbo服务暴露协议。
将长连接的建立推迟到消费者真正调用提供者时。可以减少长连接的数量。
<dubbo:reference id="xxx" lazy="true"
interface="com.xxx.xxx.xxx"/>
第六种方式:粘连连接(间接限流)
仅能设置在消费者端,其可以设置为接口级别,也可以设置为方法级别。仅作用于Dubbo服务暴露协议,其会使客户端尽量向同一个提供者发起调用,除非该提供者挂了,其会连接另一台。只要启用了粘连连接,其就会自动启用延迟连接,其限制的是流向,而非流量。
<dubbo:reference id="xxxx" sticky="true" interface="com.xxx.xxx.xxx">dubbo:reference>
<dubbo:reference id="xxxx" interface="com.xxx.xxx.xxx">
<dubbo:method name="xxxx" sticky="true">dubbo:method>
dubbo:reference>
第七种方式:负载均衡(间接限流)
参考负载均衡中的dubbo
public class CommandReject extends HystrixCommand<String> {
private String tag;
public CommandReject(String tag) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("CommandReject"))
.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
.withCoreSize(5)
.withMaxQueueSize(2))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withExecutionTimeoutInMilliseconds(3000)));
this.tag = tag;
}
@Override
protected String run() throws Exception {
Thread.sleep(3000);
return tag;
}
@Override
protected String getFallback() {
return "服务降级处理";
}
}
Hystrix写的很少,往后学习会补充进去