Spring Cloud(1) - 服务治理相关技术汇总

什么是分布式系统的CAP理论?

在分布式系统中,有一个重要的理论,即CAP理论.即C-一致性,A-高可用性,P-服务对网络分区故障的容错性(除非整个网络发生故障,分布式服务不能因为单点的网络故障而完全瘫痪).这三个特性,在任何的分布式系统中,都只能满足其中两个.

Zookeeper 和 Eureka的区别

Zookeeper

Zookeeper 是著名 Hadoop 的一个子项目,很多场景下 Zookeeper 也作为 Service 发现服务解决方案.Zookeeper 保证的是 CP,即任何时刻对Zookeeper进行访问,都会得到一致的结果,但是它不能保证服务的高可用性.例如,当zookeeper集群正在进行选主操作的时候,或者zookeeper集群有半数以上的机器不可用时.

Eureka

Eureka是Netflix开源的一款服务注册与发现产品,并提供了基于Java的封装.在它的实现理念中,所有的节点都是平等的.Eureka保证的是AP.一个节点挂掉,不会影响到其他的节点提供服务.哪怕是所有的服务全部挂掉,Eureka Client也会根据缓存的服务列表,尽最大可能保证调用是连同的.

Spring Cloud Netflix 主要组件

服务注册与发现 —— Eureka

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件的一部分,基于 Netflix Eureka
做了二次封装,主要负责完成微服务架构中的服务治理功能,服务治理可以说是微服务架构中最为核心和基础的模块,他主要用来实现各个微服务实例的自动化注册与发现.
  • 服务注册
    在服务治理框架中,通常都会构建一个注册中心.每一个服务单元向注册中心注册自己的服务地址,版本号,通信协议等信息.同时,注册中心还需要通过心跳等方式,来维护服务可用列表.
  • 服务发现
    由于运行在服务治理框架下,服务间的调用不通过指定具体的位置来执行,而是通过注册中心获取可用的位置列表来执行.

Eureka是由多运行实例组成的.大致分为两类:Eureka Server(服务端) 和 Eureka Client(客户端).为了便于理解,我们将 Eureka client 再分为 Service Provider 和 Service Consumer.如下图所示:

Spring Cloud(1) - 服务治理相关技术汇总_第1张图片

Eureka Server

Eureka Server 作为一个独立的部署单元,以 REST API 的形式为服务实例提供了注册、管理和查询等操作.同时,Eureka Server 也为我们提供了可视化的监控页面,可以直观地看到各个 Eureka Server 当前的运行状态和所有已注册服务的情况.

Eureka Server 的高可用集群

Eureka Server 可以通过部署多个实例,来实现高可用集群.不同于Zookeeper选举的过程(PS:ZK选主的算法自己也不是非常的了解,在这里也不多赘述.以后研究明白了再写出来~),Eureka Server是基于 Peer to Peer的模式.这是一种去中心化的架构,没有 M/S 的区别,大家在集群中都是对等的.在这种架构中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点.每个节点都可被视为其他节点的副本.

如果某台 Eureka Server 宕机,Eureka Client 的请求会自动切换到新的 Eureka Server 节点,当宕机的服务器重新恢复后,Eureka 会再次将其纳入到服务器集群管理之中.当节点开始接受客户端请求时,所有的操作都会进行replicateToPeer(节点间复制)操作,将请求复制到其他 Eureka Server 当前所知的所有节点中.

一个新的 Eureka Server 节点启动后,会首先尝试从邻近节点获取所有实例注册表信息,完成初始化.Eureka Server 通过getEurekaServiceUrls()方法获取所有的节点,并且会通过心跳续约的方式定期更新.默认配置下,如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳,Eureka Server 将会注销该实例(默认为 90 秒,通过eureka.instance.lease-expiration-duration-in-seconds配置).当 Eureka Server 节点在短时间内丢失过多的心跳时(比如发生了网络分区故障),那么这个节点就会进入自我保护模式。下图为 Eureka 官网的架构图:

Spring Cloud(1) - 服务治理相关技术汇总_第2张图片

雪崩效应

在微服务或者说是SOA的架构下,一次业务请求需要调用多个服务来完成.单个服务或者基础服务的故障,由于级联的效果,会导致整个服务变得不可用.雪崩效应是一种由于"服务提供方"不可用,最后导致"服务消费者"不可用的过程.
在Spring Cloud中,为我们提供了完善的降级,熔断支持.本人也是一边学习一边总结,之后会慢慢的更新到后续的文章中.

你可能感兴趣的:(soa,springcloud)