目录
1、认识Eureka
2、Eureka原理
2.1 和Dubbo架构对比:
2.2 三大角色
3、微服务常见的注册中心
3.1 Zookeeper
3.2 Eureka
3.3 Consul
3.4 Nacos
3.5 区别
Netflix 在设计Eureka 时,遵循的就是AP原则。
CAP原则又称CAP定理,指的是在一个分布式系统中
-
一致性(Consistency)
-
可用性(Availability)
-
分区容错性(Partition tolerance)
1、认识Eureka
CAP原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
Eureka是Netflix的一个子模块,也是核心模块之一。Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移,服务注册与发现对于微服务来说是非常重要的,有了服务发现与注册,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了,功能类似于Dubbo的注册中心,比如Zookeeper。
2、Eureka原理
SpringCloud 封装了NetFlix公司开发的Eureka模块来实现服务注册和发现。
Eureka采用了C-S的架构设计,EurekaServer作为服务注册功能的服务器,他是服务注册中心而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行,SpringCloud的一些其他模块(比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务,并执行相关的逻辑。
2.1 和Dubbo架构对比:
Eureka 包含两个组件:Eureka Server 和 Eureka Client 。
Eureka Server 提供服务注册服务,各个节点启动后,会在EurekaServer中进行注册,这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。
Eureka Client是一个Java客户端,用于简化EurekaServer的交互,客户端同时也具备一个内置的,使用轮询负载算法的负载均衡器。在应用启动后,将会向EurekaServer发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,EurekaServer将会从服务注册表中把这个服务节点移除掉(默认周期为90秒)。
2.2 三大角色
-
Eureka Server:提供服务的注册于发现。
-
Service Provider:将自身服务注册到Eureka中,从而使消费方能够找到。
-
Service Consumer:服务消费方从Eureka中获取注册服务列表,从而找到消费服务。
3、微服务常见的注册中心
3.1 Zookeeper
Zookeeper它是一个分布式服务框架,是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。简单来说Zookeeper=文件系统+监听通知机制。
3.2 Eureka
Eureka是在Java语言上,基于Restful Api开发的服务注册与发现组件,Springcloud Netflix中的重要组件。
3.3 Consul
Consul是由HashiCorp基于Go语言开发的支持多数据中心,分布式高可用的服务发布和注册服务软件,采用Raft算法保证服务的一致性,且支持健康检查。
3.4 Nacos
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是注册中心 + 配置中心的组合,提供简单易用的特性集,帮助我们解决微服务开发必会涉及到的服务注册与发现,服务配置,服务管理等问题。Nacos 还是 Spring Cloud Alibaba 组件之一,负责服务注册与发现。
3.5 区别
我们通过一张表格大致了解Eureka、Consul、Zookeeper的异同点。
选择什么类型的服务注册与发现组件,可以根据自身项目要求决定。
组件名 | 开发语言 | CAP | 一致性算法 | 服务健康检查 | 对外暴露接口 |
---|---|---|---|---|---|
Eureka | Java | AP | 无 | 可配支持 | HTTP |
Consul | Go | CP | Raft | 支持 | HTTP/DNS |
Zookeeper | Java | CP | Paxos | 支持 | 客户端 |
Nacos | Java | AP | Raft | 支持 | HTTP |