Spring Cloud(一):服务治理技术概览【Finchley 版】

作者 : 松哥资源 本文共3347个字,预计阅读时间需要9分钟 发布时间: 2019-01-6 共896人阅读




示例标题

CAP 定理

  • C—— 数据一致性,A—— 服务可用性,P—— 服务对网络分区故障的容错性。

  • 这三个特性在任何分布式系统中不能同时满足,最多同时满足两个。

Zookeeper

Zookeeper 保证的是 CP,即任何时刻对 Zookeeper 的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。从实际情况来分析,在使用 Zookeeper 获取服务列表时,如果 zookeeper 正在选主,或者 Zookeeper 集群中半数以上机器不可用,那么将就无法获得数据了。所以说,Zookeeper 不能保证服务可用性。

Zureka

Eureka 遵守的就是 AP 原则。在它的实现中,节点之间是相互平等的,部分注册中心的节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供发现服务。

Consul

Spring Cloud目前支持得最好的就是 Eureka,其次是 Consul,最后是 Zookeeper

Netflix 和 Spring Cloud的关系

netflix 是一家互联网流媒体播放商巨头,拥有巨大的访问量。使得其对微服务架构下的方方面面都有涉猎,孵化出众多项目,最后开源给社区。Spring Cloud对其进行进一步封装,形成现在的spring cloud netflix众多子项目

Eureka

  1. Eureka Server就相当于 zk
  2. Eureka Client可以分为两类:service provider / service consumer
    • service consumer和service provider没有严格的界限,实际情况可能某个服务节点既是service consumer也是service provider.

三者的关系如下:

Eureka Server集群

可以运行多个Eureka Server实例来组建Eureka Server集群。不像zk那样,实例间会有master/slave之分,存在leader的选举,eureka server实例之间是互相平等的。

对某个eureka server的所有操作都会复制到该实例已知的其他eureka server实例之中。如果某个eureka server实例不可用,eureka client则会自动切换到另外一台eureka server实例进行相关操作。当eureka server实例恢复后,则又会重新对eureka client提供服务。

某个eureka server启动后,会首先尝试从已知的eureka server实例中获取注册表信息,完成初始化

eureka server和servcie provider直接会通过心跳机制定时更新注册表信息。如果一定时间内,eureka server没有收到service provider的心跳信息,则会将该service provider从注册表中移除。

如果某个eureka server实例在短时间内丢失了过多心跳信息,这个时候该实例将会进入**自我保护模式** ,在自我保护模式下,该eureka server实例不会再注销任何service provider节点。

自我保护模式

默认情况下如果某个 eureka server 实例每分钟收到的心跳信息低于一个阈值,并且持续15分钟,该eureka server则会进入自我保护模式。

自我保护模式下,该eureka server实例不会再注销任何service provider节点。

当eureka server实例收到的心跳数量恢复到阈值之上,则会退出自我保护模式。

自我保护模式的设计思想就是:宁愿保留错误的service provider信息也不盲目注销任何可能健康的service provider.

这样的设计思想就会导致service consumer可能拿到不可用的服务节点信息,因此要求service consumer要有容错机制,不如重试、断路器等。

eureka server的自我保护模式是可关闭的,通过eureka.server.enable-self-preservation = false来禁用

Service Provider

service provider在启动的时候,会向eureka server提供自己的ip、端口和服务列表等信息。 eureka server会维护一个注册表来保存这些信息,该注册表结构为一个嵌套的map,如下:

private final ConcurrentHashMap<String,Map<String,Lease<InstannceInfo>>> registry = new ConcurrentHashMap<String,Map<String,Lease<InstanceInfo>>>>();

当service provider实例的状态发生改变的时候,会向eureka server实例同步自己的服务信息,同时会执行replicateToPeers操作把信息同步给其他eureka server实例。

续约与注销

servcie provider启动后会定期向eureka server发送心跳信息已达到续约的目的。

如果某个eureka server实例在一定时间内没有收到service provider的心跳信息,则会把改service provider从注册表中注销剔除。

Service Consumer

service consumer在启动后会从eureka server中获取所有实例的注册信息并缓存在本地。这些缓存信息每隔30s更新一次。因此即便所有eureka实例都不可用,service consumer还是可以利用本地的缓存信息和service provider进行通信

由于service consumer获取的服务实例信息可能是不可用的,所以service consumer需要有容错机制,比如请求重试、断路器 。spring cloud都提供了对应的工具:

  1. ribbon:实现客户端的负载均衡
  2. hystrix:断路器
  3. feign:restful web service客户端,整合了ribbon和hystrix。

Ribbon

由以下几部分组成

  1. ServerList:服务器列表,有不同的实现类

  2. ServerListFilter:服务器列表过滤器,也有不同的实现类

  3. IPing:服务实例探测器,有不同的实现类

  4. IRule:负载均衡策略,提供有 轮询、随机、响应时间加权等,类结构如下:

    5.RestClient:rest web service 请求工具

Hystrix

雪崩效应

当某个基础服务不可用的时候,依赖于该服务的其他服务可能产生级联故障,进而导致整个服务故障的事件成为雪崩效应

在微服务中会有雪崩效应,在缓存集群中也可能发生雪崩效应

为了解决这个问题,则诞生了hystrix。

hystrix的设计思想

当连续调用某个服务N次都不响应的时候,hystrix则会启用,启用它会给服务器调用方返回一个符合预期的可处理的响应结果(fallback),而不是让调用方长时间等待或则抛出一个调用方无法处理的异常,从而避免级联影响整体服务导致雪崩。

注意:
1. 在失败率较低的情况下,hystrix并不会启用,因此hystrix还是会把故障返回给客户端。
2. hystrix启用后返回的fallback是可有开发者定制的。

hystrix调用监控

hystrix会记录每分钟请求了多少次、多少失败、多少成功的等等信息,并且提供了可视化的工具hystrix dashboard对监控数据进行展示。图形化界面的含义如下:

Feign

feign整合了ribbon和hystrix,因此我们不需要再显式的使用这两个组件。

参考文献

Spring Cloud(一):服务治理技术概览【Finchley 版】



  • 随机毒鸡汤:我这辈子没求过谁,只求过阴影部分面积。


文章来源于justsoso.fun: Spring Cloud(一):服务治理技术概览【Finchley 版】





发表回复