SpringClound——微服务概述——史上最烂
SpringClound——SpringClound入门概述——史上最烂
SpringCloud——Eureka——史上最基本
SpringClound——Ribbon负载均衡——史上最烂系列
SpringClound——Feign
SpringClound——Hystrix断路器
1:Ribbon概述
1.1 Ribbon是什么
-
SpringCloud Ribbon是基于NetFlix Ribbon实现一套客户端负载均衡工具
-
简单的说,Ribbon是Netlix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时, 重试等。简单的说,就是在配置文件中列出Load Balancer (简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。
1.2 Ribbon作用
实现负载均衡
-
LB负载均衡(Load Balance) 在微服务或分布式集群中经常用的一种应用。
-
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA。
-
常见的负载均衡有软件Nginx, LVS, 硬件F5等。
-
相应的在中间件,例如: dubbo和SpringCloud中均给我们提供 了负载均衡,SpringCloud的负载均衡算法可以自定义。
-
LB负载均衡(Load Balance)是什么?
简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA (高可用)。常见的负载均衡有软件Nginx,LVS, 硬件F5等。
Ribbon本地负载均衡客户端VS Nginx服务端负载均衡区别
Nginx是服务器负载均衡,客户端所有请求都会交给nginx,然后由nginx实现转发请求。即负载均衡是由服务端实现的。
Ribbon本地负载均衡,在调用微服务接口时候,会在注册中心上获取注册信息服务列表之后缓存到JVM本地,从而在本地实现RPC远程服务调用技术。
LB(负载均衡)分为集中式LB和进程内LB
- 集中式LB
即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件,如F5, 也可以是软件,如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方。 - 进程内LB
将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的服务器。
Ribbon就属于进程内LB,它只是一个类库, 集成于消费方进程,消费方通过它来获取到服务提供方的地址。
Ribbon在工作时分成两步
第一步:先选择EurekaServer ,它优先选择在同一个区域内负载较少的server.
第二步:再根据用户指定的策略,在从server取到的服务注册列表中选择一个地址。其中Ribbon提供了多种策略:比如轮询、随机和根据响应时间加权。
2:Ribbon负载均衡
第一步:参考microservicecloud-provider-dept-8001,新建两份,分别命名为8002,8003
第二步:新建8002/8003数据库,各自微服务分别连各自的数据库
第三步:修改8002/8003各自YML
8002的yml配置文件
eureka:
client: #客户端注册进eureka服务列表内
service-url:
#defaultZone: http://localhost:7001/eureka
# defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
instance:
instance-id: microservicecloud-dept8002
prefer-ip-address: true #访问路径可以显示IP地址
info:
app.name: atstudying-microservicecloud
company.name: www.atstudying.com
build.artifactId: $project.artifactId$
build.version: $project.version$
8003的yml配置文件
eureka:
client: #客户端注册进eureka服务列表内
service-url:
#defaultZone: http://localhost:7001/eureka
# defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
instance:
instance-id: microservicecloud-dept8003
prefer-ip-address: true #访问路径可以显示IP地址
info:
app.name: atstudying-microservicecloud
company.name: www.atstudying.com
build.artifactId: $project.artifactId$
build.version: $project.version$
第四步:在如下项目的主启动类中进行修改
@SpringBootApplication
@EnableEurekaClient
//在启动该微服务的时候就能去加载我们的自定义Ribbon配置类,从而使配置生效
public class DeptConsumer80_App
{
public static void main(String[] args)
{
SpringApplication.run(DeptConsumer80_App.class, args);
}
}
对configbean进行新注解@LoadBalanced,获得Rest时加入Ribbon配置
@Configuration
public class ConfigBean //boot -->spring applicationContext.xml --- @Configuration配置 ConfigBean = applicationContext.xml
{
@Bean
@LoadBalanced//Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
public RestTemplate getRestTemplate()
{
return new RestTemplate();
}
}
第五步:启动3个eureka集群配置区,并启动3个Dept微服务并各自测试通过
总结: Ribbon其实就是一个软负载均衡的客户端组件,
他可以和其他所需请求的客户端结合使用,和eureka结合只是其中的一一个实例。
3:Ribbon核心组件——lRule
lRule:根据特定算法中从服务列表中选取一个要访问的服务
以下是Ribbon可采取的算法
1:RoundRobinRule:轮询:
2:RandomRule:随机
3:AvailabiltyilteringRule:会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,还有并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略进行访问
4:WeightedResponseTimeRule:根据平均响应时间计算所有服务的权重,响应时间越快服务权重越大被选中的概率越高。刚启动时如果统计信息不足,则使用RoundRobinRule策略, 等统计信息足够,会切换到WeightedResponseTimeRule
5:RetryRule:先按照RoundRobinRule的策略获取服务,如果获取服务失败则在指定时间内会进行重试,获取可用的服务:
6:BestAvailableRule:会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务
7:ZoneAvoidanceRule:默认规则,复合判断server所在区域的性能和server的可用性选择服务器
使用方法:
就是在consumer,添加bean配置
@Bean
public IRule myRule()
{
//return new RoundRobinRule();
//return new RandomRule();//达到的目的,用我们重新选择的随机算法替代默认的轮询。
return new RetryRule();
}
4:自定义Ribbo的负载均衡算法
提出问题:依旧轮询策略,但是加上新需求,每个服务器要求被调用5次。也即以前是每台机器访问一次,现在是每台机器访问5次
第一步:在DeptConsumer80_App配置类中添加以下内容
@SpringBootApplication
@EnableEurekaClient
//在启动该微服务的时候就能去加载我们的自定义Ribbon配置类,从而使配置生效
@RibbonClient(name="MICROSERVICECLOUD-DEPT",configuration=MySelfRule.class)
//@RibbonClient(name="MICROSERVICECLOUD-DEPT",configuration=MySelfRule.class)
public class DeptConsumer80_App
{
public static void main(String[] args)
{
SpringApplication.run(DeptConsumer80_App.class, args);
}
}
注意:官方文档明确给出了警告:这个自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下,否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享,也就是说我们达不到特殊化定制的目的了。
第二步:如下结构中
建包myrule,并写MySelfRule.java和RandomRule_define.java
MySelfRule.java
@Configuration
public class MySelfRule {
@Bean
public IRule myRule()
{
//return new RandomRule();// Ribbon默认是轮询,我自定义为随机
//return new RoundRobinRule();// Ribbon默认是轮询,我自定义为随机
return new RandomRule_define();// 我自定义为每台机器5次
}
}
根据如下结构,我们知道如果要自定义轮询算法,要继承AbstractLoadBalancerRule类
RandomRule_define.java
public class RandomRule_define extends AbstractLoadBalancerRule
{
// total = 0 // 当total==5以后,我们指针才能往下走,
// index = 0 // 当前对外提供服务的服务器地址,
// total需要重新置为零,但是已经达到过一个5次,我们的index = 1
// 分析:我们5次,但是微服务只有8001 8002 8003 三台,OK?
//
private int total = 0; // 总共被调用的次数,目前要求每台被调用5次
private int currentIndex = 0; // 当前提供服务的机器号
public Server choose(ILoadBalancer lb, Object key)
{
if (lb == null) {
return null;
}
Server server = null;
while (server == null) {
if (Thread.interrupted()) {
return null;
}
List<Server> upList = lb.getReachableServers();
List<Server> allList = lb.getAllServers();
int serverCount = allList.size();
if (serverCount == 0) {
/*
* No servers. End regardless of pass, because subsequent passes only get more
* restrictive.
*/
return null;
}
// int index = rand.nextInt(serverCount);// java.util.Random().nextInt(3);
// server = upList.get(index);
// private int total = 0; // 总共被调用的次数,目前要求每台被调用5次
// private int currentIndex = 0; // 当前提供服务的机器号
if(total < 5)
{
server = upList.get(currentIndex);
total++;
}else {
total = 0;
currentIndex++;
if(currentIndex >= upList.size())
{
currentIndex = 0;
}
}
if (server == null) {
/*
* The only time this should happen is if the server list were somehow trimmed.
* This is a transient condition. Retry after yielding.
*/
Thread.yield();
continue;
}
if (server.isAlive()) {
return (server);
}
// Shouldn't actually happen.. but must be transient or a bug.
server = null;
Thread.yield();
}
return server;
}
@Override
public Server choose(Object key)
{
return choose(getLoadBalancer(), key);
}
@Override
public void initWithNiwsConfig(IClientConfig clientConfig)
{
// TODO Auto-generated method stub
}
}
为什么要继承AbstractLoadBalancerRule类?
如下结构就可以明白
测试:连续刷新五次都是这台服务器被访问
第六次就变成如下