Version: Next
常见服务注册中心对比及 CAP 理论
| 项目 | Nacos | Eureka | Consul | CoreDNS | Zookeeper |
|---|---|---|---|---|---|
| 一致性协议 | CP + AP | AP | CP | / | CP |
| 健康检查 | TCP/HTTP/MySQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cms | / | Client Beat |
| 负载均衡 | 权重/DSL/meatadata/CMDB | Ribbon | Fabio | RR | / |
| 雪崩保护 | 支持 | 支持 | 不支持 | 不支持 | 不支持 |
| 自动注销实例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 访问协议 | HTTP/DNS/UDP | HTTP | HTTP/DNS | DNS | TCP |
| 监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注册中心 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud 集成 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| Dubbo 集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8s 集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
分布式 CAP 理论简述
在分布式环境下，存在分区问题，数据同步问题，那么分布式系统应当保证
- C——Consistency 数据一致性：数据在多个副本节点中保持一致，可以理解为两个用户对不同节点进行读取数据操作，两个用户看到的数据完全一样
- 强一致性：一旦更新，其他节点立刻也得到更新
- 弱一致性：一旦更新，能够容忍一些节点不能得到更新
- 最终一致性：一旦更新，一段时间内一些节点不能得到更新，但最终整个分布式系统的数据会达到一致
- 此处
C表示强一致性- A——Avaliability 服务可用性：系统对外提供服务必须一致处于可用状态，在任何故障下，客户端能在合理时间内，获取服务器返回的
非错误响应- P——Partition-Tolerance 分区容错性：分布式系统遭遇任何网络分区故障时，系统仍然能对外提供服务；分区故障：由于一些节点出错，导致整个网络分裂为若干个子网络
CAP 三特性
不可能同时满足：
- 如果选择了 CA，而放弃了 P，那么当发生分区时，为了保证 C 强一致性，系统需要禁止写入，当有写入请求时，系统返回 error，那么视为系统不可用，即违背了 A，因此 CA 也是不成立的
- P必须要：只能选择 CP 或 AP
- 广义的 CA 模式：C 可以降低为最终一致性、A 可以建立在 服务降级、服务限流上，此时可以认为实现了一种广义 CA 模式
反证：如果 CAP 同时存在
- 由于允许 P 的存在，即允许分区发生，则一定存在节点之间的丢包，这样就不能保证 C
- 因为允许分区，写操作可能在 节点1 上成功，在 节点2 上失败，这时候客户端读节点1和客户端读节点2，读取到的数据不一致，为了保证 C 一致性，则两个写操作必须同时失败，这就违背了 A 可用性
CP / AP 切换
根据 CAP 理论
C：强一致性A：高可用P：分区容错
何时选择何种模式
- 不需要存储服务级别的信息且服务实例是通过
nacos-client注册，并能够保持心跳，那么可以选择AP模式
- Spring Cloud 、Dubbo 都适用于 AP 模式，AP 模式为了服务可用性牺牲了一定一致性，因此 AP 模式下只支持注册
临时实例- 需要在服务级别编辑或存储配置信息，那么必须使用
CP，K8s 服务和 DNS 服务都适用 CP 模式
- CP 模式下支持注册
持久化实例，此时则以Raft一致性协议组织集群运行，该模式下注册实例之前必须先注册服务，如果服务不存在，就会报错切换
curl -X PUT "$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP"
BASE 理论
由于 CA 无法同时满足，eBay架构师，提出了 BASE 理论，他通过牺牲数据的强一致性，来获取可用性，它具有以下 3 种特征
Basically Available（基本可用）：分布式系统在出现不可预估的故障时，允许损失部分可用性，保证核心功能可用Soft state（软状态）：软状态也称为弱状态，和硬状态相对，指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延迟Eventually Consistent（最终一致性）：强调系统中所有的数据副本，在经过一端时间的同步后，最终能打到一个一致状态。只需保证系统最终数据达到一致，不需保证数据实时强一致
分布式一致性算法
Raft 一致性协议
- 我之前的详细笔记，在简书上 ↓