一、Eureka
1、概念
Eureka采用了CS的设计架构,Eureka Sever作为服务注册功能的服务器,它是服务注册中心。而系统中的其他微服务,使用Eureka的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。
1)Eureka Server提供服务注册服务
各个微服务节点通过配置启动后,会在EurekaServer中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观看到。
2)EurekaClient通过注册中心进行访问
2、Eureka server
Eureka server提供服务注册服务,各个节点启动后,会在Eureka server中进行注册,Eureka server就会存储所有可用的服务节点。Eureka server本身也是一个服务,搭建单机版的Eureka server注册中心,需要配置取消Eureka server的自动注册逻辑。
Eureka server通过Register、Get、Renew等接口提供服务的注册、发现、心跳检测等服务。
1)服务注册
服务提供者启动时,会通过 Eureka Client 向 Eureka Server 注册信息,Eureka Server 会存储该服务的信息(服务的context-path、业务ip和端口、管理ip和端口,以及设置其他信息),Eureka Server 内部有二层缓存机制来维护整个注册表
2)提供注册表
服务消费者在调用服务时,如果eureka client没有缓存注册表的话,会从eureka server拉取最新的注册表缓存到本地
3)同步状态
Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。接受eureka client发送过来的心跳检测,当一个client心跳超时,服务剔除该服务;
4)服务保护机制
运行期间,注册中心会统计心跳失败比例在15分钟之内是否低于85%, 注册中心会把当前注册实例保护起来,不删除这些实例信息,当网络恢复后,退出自我保护机制
3、Eureka client
- Eureka client是一个java客户端
- 同时也是一个内置的、使用轮询负载算法的负载均衡器。向Eureka server发送心跳,默认周期30秒。
4、集群
为了保持注册表的一致性,Eureka Server的每个节点需要一个同步机制同步维护注册表。
集群同步可以分为两块:
- 启动时拉取注册表信息到本地缓存
- 更新本地注册表时同步到其他节点
https://blog.csdn.net/qwe86314/article/details/94552801
二、Ribbon
1、概念
Ribbon 是 Netflix 公司的一个开源的负载均衡 项目,是一个客户端/进程内负载均衡器,运行在消费者端
2、工作原理
Consumer 端获取到了所有的服务列表之后,在其内部 使用负载均衡算法 ,进行对多个系统的调用。
基于HTTP和TCP等协议负载均衡组件
3、Nginx 和 Ribbon 的对比
Nginx 将所有请求都集中起来,然后再进行负载均衡
Ribbon 进程内负载均衡
4、ribbon有7种负载均衡策略
策略类 | 命名 | 描述 |
---|---|---|
RandomRule | 随机策略 | 随机选择server |
RoundRobinRule | 轮询策略 | 按照顺序选择server(ribbon默认策略) |
RetryRule | 重试策略 | 在一个配置时间段内,当选择server不成功,则一直尝试选择一个可用的server |
BestAvailableRule | 最低并发策略 | 逐个考察server,如果server断路器打开,则忽略,再选择其中并发链接最低的server |
AvailabilityFilteringRule | 可用过滤策略 | 过滤掉一直失败并被标记为circuit tripped的server,过滤掉那些高并发链接的server(active connections超过配置的阈值) |
ResponseTimeWeightedRule | 响应时间加权重策略 | 根据server的响应时间分配权重,响应时间越长,权重越低,被选择到的概率也就越低。响应时间越短,权重越高,被选中的概率越高,这个策略很贴切,综合了各种因素,比如:网络,磁盘,io等,都直接影响响应时间 |
ZoneAvoidanceRule | 区域权重策略 | 综合判断server所在区域的性能,和server的可用性,轮询选择server并且判断一个AWS Zone的运行性能是否可用,剔除不可用的Zone中的所有server |
5、自定义负载均衡算法
只需要实现 IRule 接口,然后修改配置文件或者自定义 Java Config 类
3、Feign
1、目的
Eureka,RestTemplate,Ribbon 我们就可以愉快地进行服务间的调用了,但是使用 RestTemplate 还是不方便。
像原来调用 Service 层代码一样调用。–openFeign
2、定义
Feign是Springcloud组件中的一个轻量级Restful的HTTP服务客户端,Feign内置了Ribbon,用来做客户端负载均衡,去调用服务注册中心的服务。
Feign的使用方式是:使用Feign的注解定义接口,调用这个接口,就可以调用服务注册中心的服务
3、对比
OpenFeign是springcloud在Feign的基础上支持了SpringMVC的注解,如@RequestMapping等等。
OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口,并通过动态代理产生实现类,实现类中做负载均衡并调用其他服务。
4、springcloud之Feign、ribbon设置超时时间和重试机制的总结
设置重试次数:
ribbon:
ReadTimeout: 3000
ConnectTimeout: 3000
MaxAutoRetries: 1 #同一台实例最大重试次数,不包括首次调用
MaxAutoRetriesNextServer: 1 #重试负载均衡其他的实例最大重试次数,不包括首次调用
OkToRetryOnAllOperations: false #是否所有操作都重试 123456
根据上面的参数计算重试的次数:MaxAutoRetries+MaxAutoRetriesNextServer+(MaxAutoRetries *MaxAutoRetriesNextServer) 即重试3次 则一共产生4次调用
如果在重试期间,时间超过了hystrix的超时时间,便会立即执行熔断,fallback。所以要根据上面配置的参数计算hystrix的超时时间,使得在重试期间不能达到hystrix的超时时间,不然重试机制就会没有意义
hystrix超时时间的计算: (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout 即按照以上的配置 hystrix的超时时间应该配置为 (1+1+1)*3=9秒
当ribbon超时后且hystrix没有超时,便会采取重试机制。当OkToRetryOnAllOperations设置为false时,只会对get请求进行重试。如果设置为true,便会对所有的请求进行重试,如果是put或post等写操作,如果服务器接口没做幂等性,会产生不好的结果,所以OkToRetryOnAllOperations慎用。
如果不配置ribbon的重试次数,默认会重试一次
feign和ribbon同时设置connectTimeout readTimeout,feign的配置会覆盖掉ribbon的
5、日志增强
Feign提供了日志打印功能,我们可以通过配置来调整日恙级别,从而了解Feign 中 Http请求的细节。
说白了就是对Feign接口的调用情况进行监控和输出
日志级别
NONE:默认的,不显示任何日志;
BASIC:仅记录请求方法、URL、响应状态码及执行时间;
HEADERS:除了BASIC中定义的信息之外,还有请求和响应的头信息;
FULL:除了HEADERS中定义的信息之外,还有请求和响应的正文及元数据