Java面试-微服务篇-SpringCloud
- [SpringCloud 常见组件](#SpringCloud 常见组件)
- [注册中心Eureka, Nacos](#注册中心Eureka, Nacos)
- 负载均衡Ribbon
- [服务雪崩, 熔断降级](#服务雪崩, 熔断降级)
- 微服务的监控
- 来源
SpringCloud 常见组件
通常情况下
- Eureka: 注册中心
- Ribbon: 负载均衡
- Feign: 远程调用
- Hystrix: 服务熔断
- Zuul/Gateway: 网关
SpringCloudAlibaba
- 注册中心/配置中心: Nacos
- 负载均衡: Ribbon
- 服务调用: Feign
- 服务保护: sentinel
- 服务网关: Gateway
注册中心Eureka, Nacos
-
服务注册和发现(eureka为例)
- 服务注册: 服务提供者需要把自己的信息注册到eureka, 由eureka来保存这些信息, 比如服务名称, ip, 端口等
- 服务发现: 消费者向eureka拉取服务列表信息, 如果服务提供者有集群, 则消费者会利用负载均衡算法, 选择一个发起调用
- 服务监控: 服务提供者每隔30秒向eureka发送心跳, 报告健康状态, 如果eureka90秒没接收到心跳, 就从eureka中剔除
-
nacos和eureka的区别
- nacos和eureka的共同点(注册中心)
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- nacos和eureka的区别(注册中心)
- nacos支持服务端主动检测提供者状态: 临时实例使用心跳模式, 非临时实例使用主动检测模式
- 临时实例心跳不正常会被剔除, 非临时实例不会被剔除
- nacos支持服务列表变更的消息推送模式, 服务列表更新更及时
- nacos集群默认采用AP方式(高可用模式), 当集群中操作非临时实例时, 采用CP模式(强一致模式); eureka采用AP方式(高可用模式)
- nacos支持配置中心, eureka只有注册中心
- nacos和eureka的共同点(注册中心)
负载均衡Ribbon
- 实现Ribbon负载均衡
在Feign远程调用过程中, 底层的负载均衡就是使用Ribbon
- Ribbon负载均衡策略
- RoundRobinRule: 简单轮询服务列表来选择服务器
- WeightedResponseTimeRule: 按照权重来选择服务器，响应时间越长，权重越小
- RandomRule: 随机选择一个可用的服务器
- BestAvailableRule:忽略那些短路的服务器，并选择并发数较低的服务器
- RetryRule:重试机制的选择逻辑, 轮询服务器, 对于失效的服务进行不断地重试获取服务器
- AvailabilityFilteringRule: 可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
- ZoneAvoidanceRule(默认策略): 区域敏感策略, 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。首先根据调用方的区域按照区域就近原则选择服务器, 而后再对Zone内的多个服务做轮询(没有区域就是轮询)
- 自定义负载均衡策略
- 创建类实现IRule接口, 可以指定负载均衡策略(全局)
- 在客户端的配置文件中, 可以配置某一个服务调用的负载均衡策略(具备)
服务雪崩, 熔断降级
- 什么是服务雪崩, 如何解决
- 服务雪崩: 一个服务失败, 导致整条链路的服务都失败的情形
- 服务降级: 服务自我保护的一种方式, 或者保护下游服务的一种方式, 用于确保服务不会受请求突增影响变得不可用, 确保服务不会崩溃, 一般在实际开发中与feign接口整合, 编写降级逻辑
- 服务熔断(Hystrix): 默认关闭, 需要手动打开(在引导类上添加注解
@EnableCircuitBreaker). 如果检测到10秒内请求的失败率超过50% , 就触发熔断机制. 之后每隔5秒重新尝试请求微服务, 如果微服务不能响应, 继续走熔断机制. 如果微服务可达, 则关闭熔断机制, 恢复正常请求.
微服务的监控
SkyWalking为例
- SkyWalking主要可解监控接口, 服务, 物理实例的一些状态.在压测的时候可以看到众多服务中哪些服务和接口比较慢, 可以针对性的分析和优化
- SkyWalking还可以设置告警规则, 项目上线后, 如果报错, 可以设置给相关负责人发短信和发邮件, 第一时间知道项目的bug情况, 第一时间修复
来源
黑马程序员. 新版Java面试专题视频教程