简介
众所周知，当下各大公司使用的分布式架构基本都是Spring Cloud，Spring Cloud 是一套基于Spring Boot的微服务解决方案。
Spring Cloud生态在国内主流的分为两套，一套是以奈飞开源的Spring Cloud Netfilx 20%，一套是阿里巴巴开源的Spring Cloud Alibaba 40%，无论是哪种，其中都有5大核心组件，注册中心、配置中心、网关、负载均衡、声明式远程调用。本篇文章就说说注册中心的架构特性。
CAP定律
CAP原则又称CAP定理，是指在一个分布式系统中具有一致性（Consistency）、可用性（Availability）、 分区容错性（Partition tolerance），CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
- Consistency：分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点访问同一份最新的数据副本）。
- Availability：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）。
- Partition tolerance：分区指的是由于网络或者一些不可控因素导致集群中某些节点不连通的情况，而分区容错性指的是当我们的分布式系统出现了分区的情况时，还能够对外提供正常的服务，叫做分区容错性。
在目前看来，分区容错性在一个分布式系统中基本上是必备。
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP是无法同时存在的，通过以下例子来说明
- 当库存服务减库存以后，那么需要将数据同步到其他的服务上，这是为了保证数据一致性C，但是网络是不可靠的，所以我们系统就需要保证分区容错性P，也就是我们必须容忍网络所带来的的一些问题，此时如果我们想保证C那么就需要舍弃A，也就是说我们在保证C的情况下，就必须舍弃A，也就是CP无法保证高可用。
- 如果为了保证A，高可用的情况下，也就是必须在限定时间内给出响应，同样由于网络不可靠P，订单服务就有可能无法拿到新的数据，但是也要给用户作出响应，那么也就无法保证C一致性。所以AP是无法保证强一致性的。
- 如果我们想保证CA，也就是高可用和一致性，也就是必须保证网络良好才能实现，那么也就是说我们需要将库存、订单、用户放到一起，但是这种情况也就丧失了P这个保证，这个时候系统也就不是分布式系统了。
总结
- CP模式
在Nacos集群中存在三个节点，一个主节点，两个从节点，当主节点与一个从节点出现了分区后，如果我们的前提是需要保证整个系统的一致性，也就是需要保证Consistency这个状态存在，整个集群会发起主节点的重新选举，选举完成后同步所有的数据来保持数据的一致性，那么在选主的过程中，一定会导致一段时间的不可用，当然这个时间会极短，从而不能保证完全可用性。 - AP模式
在AP模式下我们的集群没有主从的概念，所有的节点都是平等的，并且每个节点间的数据都互通，如果两个节点中间发生了分区情况，两个节点不再连通，但是我们的系统又必须保证整体的可用性，所以节点间会出现一段时间的数据不一致，直到分区恢复。
所以在分布式系统中，p是必然的存在的，只能在C和A之间进行取舍，在这种条件下就诞生了BASE理论。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—-注意，这绝不等价于系统不可用。比如：
- 响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。
- 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
总结：
保证核心服务是可以使用的，至于其他的服务可以适当的降低响应时间，甚至是服务降级。
软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
总结：
存在中间状态，不影响整体系统使用，数据同步存在延时。
最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
总结：
再过了流量高峰期以后，经过一段时间的同步，保持各服务数据的一致。
看到这里，大家应该知道怎么去回答这个问题了吧。
如果文章对你有帮助，欢迎关注、点赞、收藏(一键三连)
