SpringCloud简介
SpringCloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。SpringCloud是一个开发工具集合,含有多个子项目,它利用SpringBoot简化了分布式系统基础设施的开发。
1、Eureka
(1)主要功能:服务注册与发现。采用的c-s架构,由两个组件组成:Eureka服务端和Eureka客户端。Eureka客户端向Eureka服务端注册自己的服务信息,同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互,以更新服务租约和服务信息。
在这里插入图片描述

(3)两大组件
EurekaServer用作服务注册服务器,提供服务注册服务,各个节点启动后,会在EurekaServer中进行注册, 这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在页面中看到。
EurekaClient是一个java客户端,用来简化与服务器的交互、作为轮询负载均衡器,并提供服务的故障切换支持。在应用启动后,将会向EurekaServer发送心跳(默认周期为30秒),以证明当前服务是可用状态。如果EurekaServer在一定的时间(默认90秒)未收到客户端的心跳,EurekaServer将会从服务注册表中把这个服务节点移除。
(4)Eureka的自我保护机制
自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,Eureka Server自动进入自我保护机制,此时会出现以下几种情况:
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上,保证当前节点依然可用。
3、当网络稳定时,当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况,而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。
(5)Eureka和Zookeeper
CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。
Zookeeper保证CP
Zookeeper在一致性和可用性之间选择了一致性,因此集群里面的数据是全局一致的,每个 Server 都保存了一份相同的数据副本。客户端无论连接到哪一个 Server,数据都是一致的。这也意味着 Leader 只有将新数据同步给所有的 Follower 之后,整个 zookeeper 集群才能对外提供服务,否则客户端就有可能读到旧数据。当Leader 节点因为网络故障或者其他原因导致与其他节点失去联系,剩余节点则会发起选举,选举期间导致短暂不可用的情况,所以保证了强一致性而无法保证高可用性。
Eureka保证AP
Eureka保证了可用性,实现最终一致性。
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性),其中说明了,Eureka是不满足强一致性,但还是会保证最终一致性。

2、Ribbon和Feign
在微服务架构中,服务与服务的通讯是基于http的。SpringCloud有两种服务调用方式,一种是Ribbon+RestTemplate,另一种是Feign。
(1)Ribbon
作用:Ribbon主要提供客户侧的软件负载均衡算法。Ribbon是一个基于HTTP和TCP的客户端负载均衡工具,它基于Netflix Ribbon实现。
Ribbon 是 Netflix 发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将 Netflix 的中间层服务连接在一起,Ribbon 客户端组件提供一系列完善的配置项如连接超时,重试等,简单的说,就是在配置文件中列出 Load Balancer 后面所有的机器,Ribbon 会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器,我们也很容易使用 Ribbon 实现自定义的负载均衡算法。
(2)RestTemplate
传统情况下在java代码里访问restful服务,一般使用HttpClient,不过此种方法使用起来太过繁琐。Spring框架提供的RestTemplate类,简化了与 http 服务的通信方式,统一了 RESTful 的标准,封装了 http 链接, 我们只需要传入 url 及返回值类型即可。相较于之前常用的 HttpClient,RestTemplate 是一种更优雅的调用 RESTful 服务的方式。
(3)Feign
Feign是一个声明式http客户端。使用Feign能让编写http客户端更加简单,它的使用方法是定义一个接口,然后在上面添加注解,从避免了 调用目标微服务时,需要不断的解析/封装json 数据。SpringCloud中Feign默认集成了Ribbon,默认实现了负载均衡的效果。
(4)Ribbon和Feign的区别
Ribbon和Feign都是用于调用其他服务的,不过方式不同。
1.启动类使用的注解不同,Ribbon用的是@RibbonClient,Feign用的是@EnableFeignClients。
2.服务的指定位置不同,Ribbon是在@RibbonClient注解上声明,Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3.调用方式不同,Ribbon需要自己构建http请求,模拟http请求然后使用RestTemplate发送给其他服务,步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进,采用接口的方式,将需要调用的其他服务的方法定义成抽象方法即可,
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
在这里插入图片描述
(5)Ribbon和Nginx的区别
Nginx是服务器端负载均衡
Nginx是客户端所有请求统一交给Nginx,由Nginx进行实现负载均衡请求转发,属于服务器端负载均衡。
Ribbon是客户端负载均衡
Ribbon 是从 eureka 注册中心服务器端上获取服务注册信息列表,缓存到本地,然后在本地实现轮询负载均衡策略。
应用场景的区别:
Nginx 适合于服务器端实现负载均衡 比如 Tomcat
Ribbon 适合与在微服务中 RPC 远程调用实现本地服务负载均衡,比如 Dubbo、SpringCloud 中都是采用本地负载均衡。
在这里插入图片描述

3、Zuul
Zuul 是 NetFlix 开源的微服务网关,可以和 Eureka、Ribbon、Hystrix 等组件配合使用,其核心是一系列的过滤器;身份认证和安全:识别每个资源的验证要求,拒绝不符合要求的请求;审查与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图;动态路由:动态地将请求路由到不同的后端服务集群;压力测试:逐渐增加指向集群的流量;负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求;静态响应处理:在边缘位置直接建立部分响应,从而避免其转发到集群内部;多区域弹性:跨越 AWS Region 进行请求路由,实现 ELB(AWS Elastic Load Balancing ---- 负载均衡服务)使用的多样化,以及让系统的边缘更贴近系统的使用者。
在这里插入图片描述
Zuul的核心是一系列的filters,过滤器之间没有直接进行通信,而是通过Request Context(上下文)进行数据传递。
Zuul的过滤器是由Groovy写成,这些过滤器文件被放在Zuul Server上的特定目录下面,Zuul会定期轮询这些目录,修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用。
Zuul负载均和:zuul拦截对应的api前缀请求做转发 转发到对应的 serverId上,在eureka服务上同一个serverId可以对应多个服务, 也就是说用同一个服务节点不同的端口注册两个实例,但是serverId是一样 Zuul做转发的时候会结合eureka-server起到负载均衡的效果。
(1)过滤器的种类
四种过滤器
PRE(前置):这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现鉴权、限流、参数校验调整等。
ROUTING(路由):这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求,并使用Apache HttpClient或Netfilx Ribbon请求微服务。
POST(后置):这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端、日志等。
ERROR(错误):在其他阶段发生错误时执行该过滤器。
(2)Zuul和Nginx
Zuul虽然在性能上和nginx没法比,但它也有它的优点。Zuul 提供了认证鉴权,动态路由,监控,弹性,安全,负载均衡等边缘服务。
nginx和Zuul是可以配合使用的,发挥各自的优点,使用nginx作为负载均衡实现高并发的请求转发,Zuul用作网关
(3)Zuul和Ribbon实现负载均衡
Zuul是对外暴露的唯一接口相当于路由的是controller的请求,而Ribbon和Fegin路由了service的请求
Zuul做最外层请求的负载均衡 ,而Ribbon和Fegin做的是系统内部各个微服务的service的调用的负载均衡

4、Hystrix
Hystrix 断路器是一种开关装置,当某个服务单元发生故障之后,比如超时、异常等,通过断路器的故障监控,向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方不会长时间、不必要占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
雪崩效应:在微服务架构中,存在多个微服务,若其中一个微服务出现故障,就很容易因为依赖关系而引发故障蔓延,最终导致整个系统瘫痪,列举:电商系统中,存在用户、订单、库存、积分、评论等微服务,用户创建一个订单,请求库存系统出货,库存系统出现问题,导致订单服务挂起或失败,在高并发的情况下,被挂起的线程导致后续请求被阻塞,最终导致订单服务不可用。
服务熔断
服务熔断:当 A 服务去调用 B 服务,如果迟迟没有收到 B 服务的响应,那么就终断当前的请求,而不是一直等待下去,此时还要去监控 B 服务,当 B 服务恢复正常使用时,A 服务再发起请求;在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand.
服务降级:A 服务调用 B 服务,没有调用成功发生熔断,那么 A 服务拿一个默认值顶着,避免给我们的用户,响应一些错误的页面;请求缓存:对接口进行缓存,可以大大降低生产者的压力,适用更新频率低,但是访问又比较频繁的数据。
请求合并:将客户端多个请求合并成一个请求,只发送一个 HTTP 请求,得到响应后再将请求结果分发给不同的请求,这样就可以提供传输效率。
Netflix Hystrix 实现了断路器、线程隔离等一系列保护功能,用于隔离访问远程系统、服务或者第三方库,防止联级失败,从而提升系统的可用性与容错性。
Hystrix监控和断路器。
我们只需要在服务接口上添加Hystrix标签,就可以实现对这个接口的监控和断路器功能
Hystrix Dashboard监控面板,他提供了一个界面,可以监控各个服务上的服务调用所消耗的时间等。
Hystrix Turbine监控聚合
使用Hystrix监控,我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统查看。这样就不需要挨个打开一一个个的页面一个个查看。

5、config
微服务各自拥有自己的配置文件,当配置修改之后,我们需要重启项目,如果数量庞大,维护成本增加,针对这个问题,我们采用 Spring Cloud Config 来做配置。
Config Server:也被称为分布式配置中心,它是一个独立运行的微服务应用,用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。
Config Client:指的是微服务架构中的各个微服务,它们通过 Config Server 对配置进行管理,并从 Config Sever 中获取和加载配置信息。
Spring Cloud Config 默认使用 Git 存储配置信息,因此使用 Spirng Cloud Config 构建的配置服务器天然就支持对微服务配置的版本管理。我们可以使用 Git 客户端工具方便地对配置内容进行管理和访问。除了 Git 外,Spring Cloud Config 还提供了对其他存储方式的支持,例如 SVN、本地化文件系统等。
Spring Cloud Config 工作流程如下:
(1)开发或运维人员提交配置文件到远程的 Git 仓库。
(2)Config 服务端(分布式配置中心)负责连接配置仓库 Git,并对 Config 客户端暴露获取配置的接口。
(3)Config 客户端通过 Config 服务端暴露出来的接口,拉取配置仓库中的配置。
(4)Config 客户端获取到配置信息,以支持服务的运行。
在这里插入图片描述

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐