StringCloud Netfix常用组件简介

最新推荐文章于 2024-09-29 11:09:12 发布

克里斯关下门_被占用

最新推荐文章于 2024-09-29 11:09:12 发布

阅读量728

点赞数

分类专栏： springcloud 文章标签：微服务 java

本文链接：https://blog.csdn.net/qq_42340002/article/details/114598124

版权

springcloud 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

什么是微服务

微服务是架构思想，根据具体业务进行模块化拆分，每个服务单独拎出来，实现解耦，可以多语言实现，方便服务单独测试

文章

eureka

eureka与服务提供者、消费者关系

服务注册、服务发现，监控各个服务
还有集群：Eureka防止服务挂掉，注册多个Eureka，相互进行注册，互相备份，服务向多个注册中心绑定，一个注册中心挂掉，另外的还可以用
多个eureka互相注册，服务提供者向多个eureka注册

Eureka心跳、自我保护机制

每个服务提供者配置连接Eureka后，启动就会注册到Eureka，默认30秒向Eureka发送消息，保持心跳。
而Eureka注册中心默认90秒内未收到客户端的心跳则认为服务宕了，注销该实例。
这时候Eureka自我保护机制就会保护服务注册表中的信息，不会删除已经因为长时间没收到心跳而应该过期的服务

CAP原则

关系型数据库RDBMS（MySQL、Oracle、SqlServer）
ACID
A：原子性
C：一致性
I：隔离性
D：持久性

非关系型NoSQL（Redis、MongoDB）
CAP
C：强一致性
A：可用性
P：分区容错性
在分布式中，网络是不可控的，所以首先要保证 P ，然后在A和C之间做选择。要么AP ,要么CP 。
Zookeeper保证的是C、P
zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性

eureka保证的是A、P
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性

nacos默认是AP，可以切换为CP
redis：AP

Ribbon负载均衡

LoadBelancer（LB）：负载均衡
简单来说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）
Ribbon会自动帮助你基于某种规则（简单轮询，随机连接等等）去连接这些机器，实现负载均衡

集中式LB：即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如Nginx），由该设施负责把访问请求通过某种策略转发至服务的提供方
进程内LB：将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

其他工具：Nginx、Lvs（国人——章文嵩开发的Linux虚拟服务器）实现原理像中介
IRule类下常见方法

RoundRobinRule：轮询
RandomRule：随机
AvailabilityFilteringRule：会先过滤掉跳闸、访问故障的服务，对剩下的服务进行轮询
RetryRule：会先按照轮询获取服务，如果获取失败，则会在指定的时间内进行重试

ribbon

Feign

feign是声明式的web service客户端，它让微服务之间调用变的更简单，类似controller调用service ，springcloud集成了ribbon和eureka，可以在使用feign时提供负载均衡的http客户端
只需要创建一个接口，然后添加注解进行调用即可

Hystrix

Hystrix是一个用于分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可比避免的调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

服务雪崩

用户做请求，多个微服务之间调用
当 A服务 ->调用-> B服务
B服务 ->再去调用->C服务，但C服务超时或者挂掉了
B服务 就一直无法连接到C服务，就会一直陷入等待
这就是我们常说的服务雪崩

断路器

“断路器”本身是一种开关，当对特定的服务的调用达到一个阀值（hystric 是5秒20次）断路器将会被打开，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个服务预期的，可处理的备选响应（FallBack），而不是长时间的等待或者调用方法抛出异常无法处理的异常，这样可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

服务熔断

熔断机制是对应雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。但检测到该节点微服务响应正常后恢复调用链路。在springcloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务之间调用的状况，但失败的调用到一定的阈值，默认是5秒之内20次调用失败就会启动熔断机制
熔断类型：
熔断打开：请求不在进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态。
熔断关闭：正常情况。
熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。
涉及断路器的三个重要参数：快照时间窗，请求总数阈值，错误百分比阈值。
快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，统计的时间范围就是快照时间窗，默认是10s。
请求总数阈值：在快照时间窗内，必须满足请求总数阈值才有资格熔断。默认是20，意味着10s内，如果Hystrix命令的调用次数不足20次，即使所有的请求都超时或其他原因，断路器都不会打开。
错误百分比阈值：当请求总数在快照时间窗内超过了阈值，比如发生了30次调用，如果再30次调用中，有16次发送了超时异常，则超过了50%的错误百分比，在默认设定50%阈值的情况下，这时候会将断路器打开。
原来的主逻辑要如何恢复？

当开启的时候，所有请求都不会进行转发；一段时间之后（默认是5s），这个时候断路器是半开状态，会让其中一个请求进行转发，如果成功，断路器会关闭，若失败，继续开启。重复上述步骤。

熔断针对一个类，一个方法
熔断是服务异常，超时引起熔断
熔断：服务端/生产者
扇出链路：服务不断的向下一个调用，A服务->B服务->C服务…

服务降级

当A服务接到1万个请求 B服务接到10个请求 C服务接到1个请求
这时候对应A服务来说压力很大，为了保证重要或基本服务能运行成功，可以对一下 不重要 或者不紧急 的服务或任务进行服务的延迟使用 或暂停使用

降级也是熔断策略的一种
降级针对一个服务所有类，所有方法
降级服务压力太大，从整体网站请求负载考虑，服务关闭，用户能正常发送请求，
但会返回服务不可用提示信息
降级：客户端/消费者

服务限流

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

常见限流算法

计数器算法

计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter

假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面，瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求，也就是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。

增加一个滑动窗口，即可解决

令牌桶算法

所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；
根据限流大小，设置按照一定的速率往桶里添加令牌；
桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝；
请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；
令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

漏桶算法

可以粗略的认为就是注水漏水过程，往桶中以一定速率流出水，以任意速率流入水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

网关

网关层是最外层，浏览器与服务器交互时经过的第一个服务节点，它主要起屏蔽下游业务服务的作用，对于浏览器而言，只需要跟网关交互就相当于在与下游多个业务服务节点交互，让浏览器觉得他在和一台服务器交互。

这样的好处显而易见，不管是下游业务服务、支撑服务、基础服务，都对于浏览器屏蔽，与服务器的交互变的非常简单，浏览器无需关心各个节点的依赖关系、如何协同工作，浏览器只会了解到本次请求是否成功；开发者可以灵活的增加业务服务模块；可以在网关层做一些最上层的公用的操作，如过滤恶意请求、设置ip黑白名单、做身份认证、限流、负载均衡等。
zuu与gateway

网关职能

请求接入
作为所有API接口服务请求的接入点
业务聚合
作为所有后端服务的聚合点
中介策略
实现安全、验证、路由、过滤、流控等策略
统一管理
对索引API服务和策略进行统一管理

网关分类

流量网关：关注稳定与安全

全局性流控
日志统计
防止SQL注入
防止web攻击
屏蔽工具扫描
黑白ip名单
证书/加解密处理

业务网关：提供更好的服务

服务级别流控
服务降级与熔断
路由与负载均衡、灰度策略
服务过滤、聚合与发现
权限验证与用户等级策略
业务规则与参数效验
多级缓存策略

Zuul

查看源码发现，zuul是继承了HttpServlet，本质上就是用了java.servletAPI,实现了一个有网关功能的Servlet
继续看ZuulServlet方法，里面主要有4个方法，
pereRoute()、route()、postRoute、error()
前置路由、路由、后置路由、异常处理

Zuul提供了StaticResponseFilter、SurgicalDebugFilter两个抽象类

StaticResponseFilter：会讲请求直接处理并返回、不会经过路由链路
SurgicalDebugFilter：会将请求路由到zuul.debug.vip或zuul.debug.host所指定的debugEureka"vip"
or host

Zuul特点

zuul底层servlet、处理的是http请求
zuul抽象类非常简单易懂、易于扩展，易于debug
zuul提供的两个抽象类使用很灵活
zuul-core包不依赖spring、依赖包很少
zuul支持负载均衡、限流、熔断

Config配置中心

由于每个服务都需要application.yml配置必要信息才能运行，服务多了配置文件修改起来很麻烦，所以一套集中式的，动态的配置管理设施是必不可少的，AspringCloud提供了ConfigServer来解决这个问题

spring cloud config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同服务器应用的所有环节提供一个中心化的外部配置。
spring cloud config分为服务端、客户端
服务端：也叫分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提配置信息、加密、解密等访问接口。

客户端：通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用Git来存储配置信息，这样有助于对环境配置进行版本管理。并且可以通过Git客户端工具来方便的管理和访问配置内容。
config