自己做网站兼职,有免费的网站做农家院宣传,四川省建设工程信息网查询,北京网站制作设计哪个公司好文章目录 1、SpringCloud五大组件2、服务注册和发现2.1 Eurake2.2 Eurake和Nacos的区别 3、Ribbon负载均衡3.1 策略3.2 自定义负载均衡策略 4、服务雪崩与熔断降级4.1 服务雪崩4.2 服务降级4.3 服务熔断 5、服务限流5.1 Nginx限流5.2 网关限流 6、微服务监控7、面试 1、SpringC… 文章目录 1、SpringCloud五大组件2、服务注册和发现2.1 Eurake2.2 Eurake和Nacos的区别 3、Ribbon负载均衡3.1 策略3.2 自定义负载均衡策略 4、服务雪崩与熔断降级4.1 服务雪崩4.2 服务降级4.3 服务熔断 5、服务限流5.1 Nginx限流5.2 网关限流 6、微服务监控7、面试 1、SpringCloud五大组件 通常情况下
Eureka服务注册中心注册自己的地址上来方便后续路由转发到对应的服务上去干活儿Ribbon负载均衡Feign远程调用Hystrix服务熔断zuul/Gateway网关
实际项目用到了SpringCloudAlibaba相关的组件
Nacos服务注册中心/配置管理Ribbon负载均衡Feign远程调用Sentinel服务熔断Gateway网关
2、服务注册和发现
微服务中关于注册中心
作用服务注册和发现常见选择Nacos、Eureka、Zookeeper
2.1 Eurake
以Eureka为例 比如order服务需要远程调用user服务则前者为服务消费者、后者为服务提供者服务启动后详情如下体现了Eurake的三个功能
服务注册微服务向注册中心注册自己的实例信息服务名称、IP、端口比如user有三个实例Pod地址分别为localhost:8081、8082、8083服务发现order作为服务消费者调用user服务时从注册中心拉取注册信息并利用负载均衡算法选择user的某一个实例进行远程调用服务监控每个实例定期向注册中心发送心跳比如user-service:8083实例挂掉注册中心收不到其心跳信息则从服务列表中删掉其注册信息
2.2 Eurake和Nacos的区别
二者的共同点
都支持服务的注册和注册信息拉取都支持服务提供者心跳方式做健康检查
区别
1Nacos还支持做配置管理Eurake只有注册中心2Nacos临时实例采用心跳模式非临时实例采用主动检测模式使用Nacos时可以加这个配置设置为非临时实例默认临时实例 默认的临时实例其健康检测和Eurake一样但当设置为非临时实例时Nacos注册中心会主动发消息询问这个实例还活着没而不是实例向注册中心发送心跳信息。临时实例心跳不正常会被剔除非临时实例则不会被剔除。
3服务注册信息发生变化时Naocs会将列表变更推送到服务消费者即服务列表实时更新如上图即Nacos即支持服务主动定时pull拉取注册列表信息也支持主动将变更push到服务
4Nacos集群默认是AP即追求高可用但当集群中存在非临时实例时采用CP模式即强一致性而Eurake采用AP3、Ribbon负载均衡
3.1 策略
采用Feign远程调用时底层是Ribbon在做负载均衡流程如下 从注册中心拉取的服务提供者实例列表根据负载均衡策略选择一个实例比如轮询策略 Ribbon负载均衡策略轮流、随机、选响应快的、选比较空闲的
轮询RoundRobinRule按照权重来选实例响应时间越长权重越小WeightedResponseTimeRule随机选择一个可用的实例RandomRule忽略那些短路的实例并选择并发数较低的实例比较空闲的一个BestAvailableRule重试轮询的实例宕机重试RetryRule可用性敏感策略先过滤非健康的再选择连接数较小的实例AvailabilityFilteringRule区域敏感策略默认策略以区域可用的实例为基础进行实例的选择使用 Zone 对实例进行分类这个 Zone 可以理解为一个机房、一个机架等后再对 Zone 内的多个服务做轮询。比如就近选择上海的机房服务器而不选择放在北京的服务器没有区域的概念则就是一个轮询ZoneAvoidanceRule
3.2 自定义负载均衡策略 方式一 在服务消费方发起调用的那一方创建IRule的Bean返回一个IRule接口的实现类不同的实现类对应上面的一个个策略。如此order调用任何一个微服务都是这种负载均衡策略。 方式二 在配置文件中针对调用哪一个微服务时使用哪种策略局部生效只针对order调用user这一个微服务时生效。
4、服务雪崩与熔断降级
4.1 服务雪崩
服务雪崩即一个服务宕机导致整个调用链上的其他服务因连接数耗尽也不可用 如上D被A远程调用后面A被B调用此时D实例宕机A远程请求一直得不到响应积累久了A的可用连接数就没了一个服务的最大连接数是有限的而调用失败的那些连接不会立马释放。如此A也不可用以此类推整个系统都挂了。解决方案
熔断降级限流只能起个预防作用
4.2 服务降级
服务D远程调用不通时走降级逻辑。 Feign时用fallback指定降级逻辑 4.3 服务熔断
只有降级也不行降级只是返回了另一个提前定义好的失败调用结果后面请求进来还是先会去远程请求直到超时失败才走降级代码因此需要加上熔断。即远程调用失败次数到达一定阈值请求过来直接走降级逻辑不再去先远程调用等到超时。 Hystrix 熔断机制用于监控微服务调用情况。默认关闭开启熔断可在引导类上添加注解EnableCircuitBreaker如果检测到 10 秒内请求的失败率超过 50%就触发熔断机制断路器打开请求过来不管远程调用通不通直接走降级代码。之后每隔 5 秒重新尝试请求微服务断路器半开放行一个请求如果微服务还不能响应继续走熔断机制。如果微服务可达则关闭熔断机制恢复正常请求流程。
最后注意降级是针对远程调用某一个接口的而熔断发生时是全部接口。比如A远程调用B请求B失败率到达阈值触发熔断则不管你直接请求B还是远程调用请求B都是立即失败 5、服务限流
限流的原因
有突发流量并发高防止用户恶意刷接口 实现方式
设置Tomcat最大连接数 Nginx漏桶算法网关令牌桶算法自定义拦截器
5.1 Nginx限流
漏桶算法即请求过来后存起来以固定的、微服务能处理及的速率放出来装不下的请求等待或抛弃。削峰的味道。 具体实现 方式一控制速率 语法: limit_req_zone key zone rate参数
key定义限流对象 binary_remote_addr 就是一种 key 即基于客户端 ip 限流Zone定义共享存储区来存储访问信息上图serviceReateLimit这个是自定义的名称10m可以存储 16wip 地址访问信息Rate最大访问速率rate10r/s表示每秒最多放出10个请求burst20相当于桶的大小nodelay快速处理桶里的请求快速处理桶外的请求快速丢弃 方式二控制并发连接数 语法: limit_req_zone key zone rate参数
limit_conn perip 20对应的 key是 $binary_remote addr 表示限制单个 |P 同时最多能持有 20 个连接limit_conn perserver 100对应的 key是 $server name表示虛拟主机(server)同时能处理并发连接的总数
5.2 网关限流
请求过来时先去桶里申请令牌。拿到令牌正常请求拿不到令牌阻塞或丢弃 和漏桶算法相比二者的区别比如漏桶设置了漏出速率为3令牌桶设置了每秒生成的令牌数也为3.此时
使用漏桶可以保证最多每秒处理3个请求令牌桶每秒最多可处理6个请求比如第1秒无请求攒了3个令牌第2秒来了6个请求用掉已有的三个令牌同时这一秒又生成3个新令牌这一秒就可以处理6个请求
Spring Cloud Gateway网关限流的实现是在配置中加局部过滤器RequestRateLimiter key-resolver 定义限流对象( ip 、路径、参数)需代码实现使用 spel表达式获取replenishRate 令牌桶每秒填充平均速率令牌存Redis因此需要配置RedisburstCapacity 令牌桶总容量
6、微服务监控
常见技术选型
SpringBoot-AdminPrometheus Grafana偏监控搭建复杂Zipkin偏链路追踪但有代码侵入Skywalking偏链路追踪
以SkyWalking为例 相关概念
服务Service系统中的一个个微服务端点Endpoint开发的一个个功能接口实例Instance服务所在的物理机服务器
搭建完成后根据仪表盘中的慢接口去问题定位拓扑图中显示了服务之间的调用关系 更好的是sky walking可以设置告警规则项目上线后可给负责人发短信或者邮件以便第一时间修复问题。
7、面试
