分布式架构理论(CAP和注册中心的选择)

分布式架构理论

微服务

微服务就是一个很小的服务,小到一个服务就只完成一个功能、只做一件事。但是这个服务可以独立部署运行,每个服务之间通过RPC(远程调用)来相互交互,每一个微服务都可以有一个小团队来完成开发、测试、部署、上线、维护它的生命周期。

微服务架构

在做架构设计时,先做逻辑架构、在做物理架构,当你拿到需求后,估算过最大用户量和并发量后,计算每一个应用服务器能否满足需求,如果用户量只有几百人的小应用,单体应用就可以搞定,即把所有应用部署在一个应用服务器上;如果是很大的用户量,且一些功能会被频繁、大量的调用,或者一个功能计算量很大,那么这个时候就要考虑将一个应用拆分成多个子应用,各自负责功能。

分布式服务

各个服务分散部署在不同的机器上,一种面向服务的架构(SOA),服务之间也是用RPC或者webService来交互,逻辑架构设计完就需要做物理架构的设计。系统应用部署在多台服务器或虚拟机上,并且各个分派部署的部分彼此通过通讯协议进行信息交互,这就是分布式部署。

生产环境下的微服务肯定是分布式部署的,分布式部署的应用不一定是微服务架构的。(比如集群部署,他是把相同的应用,复制到不同的服务器上,到那时逻辑功能还是一个单体应用)

CAP定理

Consistency、Availability、Partition tolerance。在任何分布式架构设计的系统中,我们只能同时满足CAP中的两个条件,无法达到三者同时并存的情况

  • C(Consistency一致性):每一个节点访问到的都是最新的数据
  • A(Availability可用性):每一个请求都会得到响应,不管请求是成功还是失败
  • P(Partition tolerance分区容错性):除了整体的网络故障之外,任何的其他故障都不能让整个系统不可用
CP
  • 保证一致性和分区容错性,舍弃可用性,也就是说,在一些特殊情况下,允许发生系统无法被访问到的情况,牺牲用户的体验,每次都要系统数据一致后,在继续让用户使用,这期间就会增加用户的等待时间
AP
  • 保证可用性和分区容错性,舍弃一致性,很多分布式系统都会这样设计,保证高可用,让用户有较好的体验,不需要长时间的等待,但是整个系统每个节点的数据不会同时保持一致,会有一个同步的过程
CA
  • 保证一致性和可用性,舍弃分区容错性,舍弃掉P,就相当于舍弃分布式系统,单节点的错误不能影响到整体系统的运行,这是分布式系统的前提条件,所以这种情况是不存在的。

所以在分布式系统中,我们只能顾及到两点,在实际情况下,网路硬件方面一定会有延迟和丢包的发生。所以分区容错性是我们开发时一定要实现的。所以我们就要考虑在一致性和可用性之间做权衡

Base理论

就是CAP中的一致性和可用性的一次权衡结果。核心思想:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到一种最终一致性

  • Basically Available(基本可用)
    • 假设系统出现了不可预知的故障,但是还能用,可能会有性能或者功能上的影响
  • Soft state(软状态)
    • 允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时
  • Eventually consistent(最终一致性)
    • 系统能够保证在没有其他的新的更新操作的情况下,数据最终一定能过达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取最新的值

(总结:BASE理论面向的是大型高可用、可扩展的分布式系统。BASE提出通过牺牲强一致性来获得可用性,并允许数据段时间内的不一致,但是最终达到一致状态。同时,在实际分布式场景中,不同业务对数据的一致性要求不一样。)

注册中心

下面是几个常见的注册中心,根据上面CAP的学习,在实际的应用场景中,我们就要根据他们的特点,选择出合适的注册中心。

Nacos Eureka Consul Zookeeper
一致性协议 CP+AP AP CP CP
健康检查方式 TCP/HTTP/MYSQL/Client/Beat 心跳 TCP/HTTP/gRPC/Cmd Keep Alive
访问协议 HTTP/DNS HTTP HTTP/DNS TCP
Spring Cloud集成 支持 支持 支持 支持
雪崩保护

Zookeeper:

​ CP原则,保证一致性。集群搭建的时候,某个节点失效,则会进行选举leader。如果半数以上节点不可用,则无法提供服务,因此无法保证服务的可用性。

Consul:

​ CP原则,保证一致性。使用的是Raft算法,比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性,但是可用性就相应下降了,例如服务注册的时间会稍长一些,因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ;在leader挂掉了之后,重新选举出leader之前会导致Consul 服务不可用。

Eureka:

​ AP原则,保证高可用。无主从节点,一个节点挂了,自动切换其他节点可以使用,去中心化。只要有一个节点还存着,就能保证注册服务的可用,不过,信息可能不是最新的。

Nacos:

​ 支持AP和CP模式,默认情况下是AP模式

选择

  • 根据实际情况中的业务场景来进行合适的架构设计
  • 要求一致性:
    • 选择Zookeeper/Nacos
    • 适合支付、交易类、对数据需要保证强一致的情况。宁可业务不可用,也不能出现脏数据。如金融行业
  • 要求高可用行:
    • 选择Eureka/Nacos
    • 适合互联网业务,比如信息流架构,不要求数据的强一致性,但服务要一直可用。如电商系统

你可能感兴趣的:(Spring,Cloud,分布式,java,编程语言,spring,cloud)