分布式架构理论
微服务
微服务就是一个很小的服务,小到一个服务就只完成一个功能、只做一件事。但是这个服务可以独立部署运行,每个服务之间通过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
- 适合互联网业务,比如信息流架构,不要求数据的强一致性,但服务要一直可用。如电商系统