系列文章目录
1、父工程创建
2、支付模块构建和热部署
3、消费者订单模块
4、服务注册中心-Eureka
5、zookeeper没学习
6、服务注册中心-Consul
7、Eureka、Consul异同
8、服务调用-Ribbon
9、服务调用-OpenFeign
10、服务降级-Hystrix
11、服务降级-Hystrix（二）
12、服务熔断-Hystrix
13、服务网关-Gateway
14-17 在git上做配置中心，没有学习
17、请求链路跟踪-Sleuth
18、Spring Cloud Alibaba-Nacos注册中心与配置中心
19、Spring Cloud Alibaba-Nacos集群和持久化配置
20、Sentinel流控
21、Sentinel熔断降级、热点key限流
22、SentinelResource配置
23、Sentinel 服务熔断与持久化
1. Eureka与Consul比较
| 组件名 | 语言 | CAP | 服务健康检查 | 对外暴漏接口 |
|---|---|---|---|---|
| Eureka | java | AP | 支持 | http |
| Consul | go | cp | 支持 | http/dns |
2. CAP理论
CAP分别指一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，在一个分布式系统中，这三个要素最多只能同时实现两点，不可能三者兼顾
2.1 Consistency (一致性)
写操作之后的读操作，必须返回该值。如客户端C1向服务器S1修改了一个值，这是C1访问S1可以拿到这个值v1。
但是C1也有可能向C2访问获取值，但是C2中的值并没有被修改，因此C2访问没修改的值v0。S1 和 S2 的读操作的结果不一致，这就不满足一致性了。
因此当S1中的值被修改时S1应该向S2发送消息，也让S2修改值。
这样C1从S2获取的值也是v1了。
2.2 Availability (可用性)
意思是只要收到用户的请求，服务器就必须给出回应。
C1向服务器发起请求，服务器必须要给出回应，不管是哪台服务器，只要收到请求，就必须回应请求，否则就不满足可用性。
2.3 Partition tolerance （分区容错性)
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。分区容错的意思是，区间通信可能失败。
S1 和 S2 是两台跨区的服务器。S1 向 S2 发送消息，S2 可能无法收到。在系统设计时，必须考虑到这种情况。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。只需要考虑C和A就行了。
- CA ：单点集群，满足—致性，可用性的系统，通常在可扩展性上不太强大。
- CP ：满足一致性，分区容忍必的系统，通常性能不是特别高。
- AP ：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
结论：违背了一致性C的要求，只满足可用性和分区容错，即AP（Eureka）
当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性。
结论：违背了可用性A的要求，只满足一致性和分区容错，即CP（Consul）