微服务基本概念

什么是CAP?

C：一致性（ Consistency）节点1和节点2的数据是相同的

A：可用性（ Availability）

P：分区容错性（ Partition tolerance）节点1和节点2网络不通了，出现分区了对外依然要能提供服务，不能说分区了导致整个系统岩机无法对外提供服务。

AP：保证高可用，即保证某个服务故障仍然可以正常访问，牺牲了数据的一致性。一旦网络或者服务恢复就会进行数据同步保证数据最终一致性。

CP：保证数据一致性。在整个系统中保证数据时刻一致，强一致性，一旦数据不一致就会出现提示：用户系统异常。

AC：既保证高可用又保证数据强一致性，这种情况是不存在的，因为谁也无法保障网络永远不会出现故障

分布式系统肯定优先保证P，多数时候是在（C和A之间做权衡选择)

脑裂

脑裂：集群(M-S模式)的脑裂通常是发生在节点之间通信不可达（分区）的情况下，集群会分裂成不同的小集群，小集群各自选出自己的master节点，导致原有的集群出现多个master节点的情况。

解决方法：过半机制，leader选举，要求节点的投票数量>（总节点数量/2），有这个选举原则保证了集群出现分区，无论如何最多只有一个小集群能选出leader

AP模式的nacos，是点对点集群架构，不会出现脑裂

M-S模式的集群节点个数为什么一般推荐是奇数个？（偶数个也行，但是很多问题）

1、偶数个节点的集群一旦节点数对半分区（比如4个节点分区成两个节点和两个节点的情况），整个集群无法选出leader，集群无法提供服务（这种情况就是没有满足CAP里的P）

2、容错能力相同的情况下奇数节点比偶尔更节约资源，比如5个节点挂两个还能选leader，6个节点最多也只能挂两个节点才能保证其能选leader

C/S架构和B/S架构

C/S和B/S各有优势，C/S在图形的表现能力上以及运行的速度上肯定是强于B/S模式的，不过缺点就是他需要运行专门的客户端，而且更重要的是它不能跨平台，用c++在windows下写的程序肯定是不能在linux下跑的。

而B/S模式就不同了，它不需要专门的客户端，只要浏览器，而浏览器是随操作系统就有的，方便就是他的优势了。

而且，B/S是基于网页语言的、与操作系统无关，所以跨平台也是它的优势，而且以后随着网页语言以及浏览器的进步，B/S在表现能力上的处理以及运行的速度上会越来越快，它的缺点将会越来越少。

比如，未来的HTML5，在图形的渲染方面以及音频、文件的处理上已经非常强大了。

不过，C/S架构也有着不可替代的作用。

常见注册中心对比

项目	Nacos	Eureka	Consul	CoreDNS	Zookeeper
一致性协议	CP+AP	AP	CP		CP
健康检查	TCP/HTTPMYSOL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd		Keep Alive
负载均衡策略	权重/metadata/selector	Ribbon	Fabio	RoundRobin
雪崩保护	有	有	无	无	无
自动注销实例	支持	支持	不支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
监听支持	支持	支持	支持	不支持	支持
多数据中心	支持	支持	支持	不支持	不支持
跨注册中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	不支持
Dubbo集成	支持	不支持	不支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持

集群和分布式

集群：同一个业务，部署在多个服务器上

分布式：

• 分布式部署，一个业务拆分成多个子业务，每个子业务分别部署在不同的服务器上
• 分布式存储，存储在一台机器上的数据被拆分成多份存储在不同的机器上
• 微服务：就是一种分布式部署架构

生活案例

小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。

为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群

BASE原则
BA：基本可用（Basically Available）
S：软状态（Soft State）
E：最终一致性（Eventual Consistency）
CAP原则是三选二BASE原则是CAP的折中，C、A、P三个都要，但不
用100%的保证每一个原则
分布式系统肯定优先保证P，多数时候是在C和A之间
做权衡选择