分布式架构理论（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
  • 适合互联网业务，比如信息流架构，不要求数据的强一致性，但服务要一直可用。如电商系统