spring cloud的主要七大组件:Eureka,Ribbon,Open Feign,Hystrix,Zuul,Config以及Spring Cloud Bus

Sping Cloud的组件有很多,21个,这里介绍主要的7个,包括Eureka,Ribbon,Open Feign,Hystrix,

Zuul,Config和Spring Cloud Bus。

(以下皆为纯手打,累死了。。。。)

Eureka:

是一个注册发现中心,类似于zookeeper,Consul的功能,在租房者-中介-房东模型中,是担任中介的作用的,各大服务(房东)将自身信息注册进入Eureka服务器,而Eureka则会通过心跳监测(30s),判断各大服务是否还提供服务,若90s后还是没有监测到服务提供,则注销该服务在Eureka服务器中的注册信息。而消费者(租房者)则是通过Eureka服务器来寻找自己需要调用的服务。

Eureka的自我保护机制:按照默认设置,当一个服务90s无法被监测到就应该在注册表中删除该服务的,但是通过自我保护机制,当EurekaServer节点在短时间内丢失过多客户端时,就可能是发送了网络故障,Eureka就会开启自我保护机制,保护注册表中的实例信息,等待网络恢复后关闭自我保护并重新连接。

Ribbon:

是一个客户端/进程内负载均衡器,运行在消费者端,其获取到所有的服务列表后,在其内部使用负载均衡的算法,进行对多个系统的调用。相比较于Nginx,于Ribbon不同的是,它是一种集中式的负载均衡器,也就是将所有的请求都集中起来,然后再进行负载均衡(ps:最重要的就是,Ribbon是先负载均衡在发请求 ,Nginx是先发请求到Nginx,再进行负载均衡)。

Ribbon的几种负载均衡调度算法:

  1. RoundRobinRule:轮询策略,默认策略,若一次轮询未找到相应的服务,最多再轮询10次,就返回null。

  2. RandomRule:随机策略,从所有可用的服务中随机选择一个。

  3. RetryRule: 重试策略,先按照轮询策略获取provider,若获取失败,则在指定的时限内重试。默认时限为500毫秒。

Open Feign:

和Ribbon一样,也是运行在消费者端的,使用Ribbon进行负载均衡,所以OpenFeign直接内置了Ribbon。进行服务间的调用有两种方式,包括

RestTemplate和Open Feign两种,不过相对于RestTemplate的繁琐,使用Open Feign更加简洁。

Hystrix:

Hystrix就是一个能进行熔断和降级的库,通过使用它能提高整个系统的弹性。举个例子,服务A调用服务B,服务B调用服务C,如果C突然由于某些原因挂掉了,大量请求就会在服务C阻塞,从而导致服务B,服务A的请求也会阻塞,因为这些请求会消耗占用系统的线程、IO等资源,随着请求的增加,服务器最终就崩了,即服务雪崩。

熔断就是当指定时间内的请求失败率达到设定阈值是,系统通过断路器直接将此请求链路断开(使用@HystrixCommand注解来标注某个方法,如果调用该方法的时间超过默认的1000ms,断路器就会中断对这个方法的调用);

降级就是通过设置fallbackMethod来给一个方法设置备用的代码逻辑,如果调用该方法超时发生熔断,就进行服务降级,执行备用代码逻辑。

Zuul:

作为一个统一的消费者工程调用路口,方便对所有调用行为进行管理。

其中最关键的就是路由和过滤器。首先Zuul会向Eureka中进行注册,从而获取

到Eureka中的所有注册信息,然后就可以进行路由映射。

1.可以通过自定义路由代替微服务名称以及屏蔽自身真实服务名。

2.可以通过路由屏蔽,屏蔽掉指定的URL,即只要用户请求的URL中包含指定的URL路径,就无法访问到指定的服务,通过该方式可以现在用户的权限

如:zuul:

  Ignore-patterns:**/ycl/**

就可以屏蔽袋ycl的URL请求。

4.屏蔽敏感请求头:默认情况下,Cookie,Set-Cookie等敏感请求头信息会被Zuul屏蔽掉,我们可以将这些默认屏蔽去掉,也可以添加要屏蔽的请求头。

Zuul的过滤功能:如令牌桶限流,以固定速率生存令牌到令牌桶,可以设置最多存储10个令牌,只有拿到令牌的请求才可以被处理,并且可以应付突发高请求(如令牌桶是满的,突然来了10个请求也可以直接获得令牌);Zuul的过滤还可以实现权限校验,灰度发布等。

Zuul作为网关肯定也存在单点问题,为了保证高可用,就需要进行集群配置,可以借助额外的负载均衡器,如Nginx;

Config:

作为分布式系统,这么多的服务和组件,不可能每次需要修改某些应用对应的配置就去修改该应用的配置文件,然后重启,太麻烦了,并且重启就抛弃了可用性。所以就有了这个作为配置中心的组件Config,可以动态修改配置文件,但是呢,其实在远程仓库修改配置文件,却又不会动态刷新到已经启动的应用中,这与前文的话冲突了,Config只能配合其他组件才能实现动态刷新,需要配合

Spring Cloud Bus

使用。

Spring Cloud Bus:可以简单的理解为管理和广播分布式系统中的消息,也就是消息引擎系统中的广播模式。Bus不仅仅有客户端的配置刷新功能的。

拥有Spring cloud Bus后,我们只需要创建一个简单的请求,并且加上

@ResfreshScope注解就可以进行配置的动态修改了。

我是“道祖且长”,一个在互联网苟且偷生的Java程序员

posted @   道祖且长  阅读(774)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· winform 绘制太阳,地球,月球 运作规律
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 超详细:普通电脑也行Windows部署deepseek R1训练数据并当服务器共享给他人
· 上周热点回顾(3.3-3.9)
点击右上角即可分享
微信分享提示