[微服务]注册中心与 CAP 理论
服务注册中心本质上是为了给服务提供者与该服务消费者解耦的。对于任何一个微服务,都应该会有多个服务者,这样就引入了额外的组件来管理微服务提供者的注册于发现,这个组件就是服务注册中心。
一、CAP 理论
CAP 原则又称 CAP 定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
C:Consistency(强一致性)(所有节点在集群中具有相同的数据)
A:Availability(可用性)(保证每个请求不管成功或者失败都有响应,但可能接受到的数据节点是过时的或者错的)
P:Partition(分区容错性),目前分布式系统必须保证 (系统中任意信息丢失或者失败不影响系统的继续运作,某个部分宕机了,集群中的其他部分还是能运行的)
CAP 理论的核心是:一个分布式系统不可能同时很好的满足「一致性」、「可用性」和「分区容错性」这三个需求,因此,根据 CAP 理论原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则的三大类:
CA:单点集群,满足一致性、可用性的系统,通常在可扩展性上不太强大 CP:满足一致性、分区容忍性的系统,通常性能不是特别高 AP:满足可用性、分区容忍性的系统,通常对一致性要求低一些
CAP 理论关注粒度是数据,而不是整体系统设计的策略
二、Eureka、Zookeeper、Consul 三者异同点
组件名 | 语言 | CAP | 服务健康检查 | 对外暴露接口 | Spring Cloud 集成 |
---|---|---|---|---|---|
Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
Zookeeper | Java | CP | 支持 | 客户端 | 已集成 |
Consul | Go | CP | 支持 | HTTP/DNS | 已集成 |
目前 Eureka 组件 Netflix 已经停止更新了。
评论区