-
Eureka
目前已经停更进维了,具有自我保护机制:某时刻某个服务不能用了,但是还会保存该服务信息(默认90s收不到心跳会设置该服务为宕机),不会立即清理,属于CAP里面的AP分支
-
Zookeeper
刚开始是为大数据提供服务的组件,具有实时剔除宕机的服务的策略,所以在服务可用性不如Eureka和Consul
-
Consul
go语言写的,所以在维护和个性化方面代价会相对较高(毕竟还要招一个懂go语言的工程师)
4. Nacos
阿里的开发的组件,应用前景会很广,使用java开发,更加独立,支持服务持久化,管理更加细化,可以灵活配置在AP和CP,但是目前只支持java服务,不支持其它语言的服务注册,之后应该会出来的,毕竟作为一个注册中心需要海纳百川么
区别与联系
组件名 | 语言 | CAP | 服务健康检查 | 对外暴露接口 | Spring Cloud集成 |
---|---|---|---|---|---|
Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
Consul | Go | CP | 支持 | HTTP/DNS | 已集成 |
Zookeeper | Java | CP | 支持 | 客户端 | 已集成 |
nacos | Java | AP/CP | 支持 | HTTP/DNS | 已集成 |
-
C:Consisitency(强一致性)
-
A:Availability(可用性)
-
P:Partition tolerance(分区容错性)
-
CAP理论关注粒度是数据,而不是整体系统设计的