注册中心的由来
在早期的单体架构中,服务间的调用通过固定的地址和端口直接完成。然而,随着系统规模的扩大,单体架构逐渐演变为分布式微服务架构,服务数量暴增,动态扩展需求也随之而来。于是,手动维护服务地址的方式变得不可行。
注册中心应运而生:
- 它为服务提供者和消费者之间建立了一个中间桥梁,简化了服务的发现和调用。
- 借助 RESTful 风格 和 RestTemplate 工具,服务之间的通信更加标准化。
想象一下你使用 RestTemplate 调用另一个服务的接口,如果每次都需要硬编码目标服务的地址,一旦服务地址变更就会导致大量修改。通过注册中心,服务调用者只需使用服务名,无需关心具体的地址。
一、注册中心生活实例
想象一下快递派件 的过程。快递员(服务消费者)要找到目标客户(服务提供者 )的地址。然而,客户的地址不是直接提供的,而是需要快递员先联系快递公司总部(注册中心),由总部查询后告知客户地址。注册中心在其中扮演了"地址查询器"的角色,这与微服务架构中的服务注册和发现非常类似。
核心内容
- 服务注册:微服务启动后,将自己的地址、端口等信息注册到注册中心,使其他服务能够发现它。
- 服务发现:消费者通过注册中心获取服务提供者的位置信息后,进行服务调用。
- 实例心跳:服务提供者会定期向注册中心发送心跳信号,表明自己仍然可用。
二、CAP理论
-
一致性(Consistency):在 CAP 理论中,一致性指的是强一致性,要求所有节点在同一时间具有相同的数据。当一个写操作完成后,所有后续的读取操作必须能够返回最新的写入数据。这种严格的同步性通常会带来较高的性能开销。
-
可用性(Availability):保证系统的每个请求都能收到响应,无论响应的结果是否正确。例如,在一个分布式服务中,即使某些节点数据不一致,服务仍然会返回一个可用的结果以满足请求,这是一种对高可用性的体现。
-
分区容错性(Partition Tolerance):分区容错性意味着在网络分区(即节点间通信失败)的情况下,系统仍然能够继续对外提供服务。这是分布式系统的基本特性,因为网络分区在实际环境中是不可避免的。
理论权衡 :由于分区容错性是分布式系统的必要条件,因此设计者必须在一致性和可用性之间进行选择。
AP架构 与 CP架构
-
MySQL 主从集群优先保证可用性和分区容错性(AP)。
-
注册中心的设计也基于 CAP 的权衡。
三、常见注册中心
Zookeeper
-
特点:
-
虽然 Zookeeper 的官方并没有明确表示它是一个注册中心,但在国内 Java 生态中,大部分集群环境依赖 Zookeeper 完成注册中心功能。
-
它强调 CP(一致性和分区容错性),服务注册和发现依赖于一致性协议(如 Paxos 或 ZAB)。
-
常用于需要严格一致性的分布式系统,例如分布式锁和配置管理。
-
Eureka
-
特点:
-
Eureka 是 Netflix 开发的基于 REST 的服务发现框架,主要用于服务注册、管理、负载均衡和服务故障转移。
-
强调 AP(可用性和分区容错性),即使注册中心与部分服务失联,服务提供者和消费者也能继续工作。
-
尽管官方声明在 Eureka 2.0 版本停止维护并不建议使用,但由于 Eureka 是 Spring Cloud 服务注册与发现的默认实现,目前仍有许多公司在使用。
-
Nacos
-
特点:
-
Nacos 是 Spring Cloud Alibaba 架构中重要的组件。
-
除了服务注册与发现功能外,Nacos 还支持配置管理、流量管理、DNS 和动态 DNS 等多种特性。
-
它支持 AP 和 CP 模式切换,用户可根据场景需求灵活选择。
-
现代化设计,适合云原生架构。
-
四、搭建 Eureka
4.1 引入依赖
XML
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
如果是服务消费者则引入下面的依赖
XML
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
4.2 配置文件
在 application.yml 中配置 Eureka:
XML
# Eureka相关配置
# Eureka 服务
server:
port: 10010
spring:
application:
name: eureka-server
eureka:
instance:
hostname: localhost
client:
fetch-registry: false # 表示是否从Eureka Server获取注册信息,默认为true.因为这是一个单点的Eureka Server,不需要同步其他的Eureka Server节点的数据,这里设置为false
register-with-eureka: false # 表示是否将自己注册到Eureka Server,默认为true.由于当前应用就是Eureka Server,故而设置为false.
service-url:
# 设置与Eureka Server的地址,查询服务和注册服务都需要依赖这个地址
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
4.3 启动服务
- 创建一个主类并添加**
@EnableEurekaServer
注解**:
java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServerApplication.class,args);
}
}
此时 完成注册中心的搭建 启动服务
五、 Eureka / Zookeeper / Nacos 区别
一致性模型
-
Eureka:强调 AP,允许短暂不一致,确保高可用性。
-
Zookeeper:强调 CP,保证严格一致性,但可能因网络分区导致服务不可用。
-
Nacos:支持 AP 和 CP 模式,用户可根据场景选择。
使用场景
-
Eureka:适合需要高可用性的微服务架构。
-
Zookeeper:适合需要一致性的场景,如分布式锁。
-
Nacos:适合需要动态配置管理的云原生应用。
扩展性和性能
-
Eureka:轻量级,性能高。
-
Zookeeper:性能较低,但一致性强。
-
Nacos:功能全面,现代化设计。
六、Eureka总结
Eureka作为分布式微服务架构中的服务注册与发现机制,其核心价值在于提供了一个简单而高效的方式来管理和协调服务之间的交互。
-
服务治理简化: Eureka简化了微服务间的服务治理问题,通过集中式注册中心管理服务的注册与发现,降低了服务间通信的复杂性。
-
动态服务注册: 服务实例在启动时自动注册到Eureka Server,并在停止时自动注销,这种动态注册机制使得服务治理更加灵活。
-
心跳检测: Eureka通过心跳机制监控服务实例的健康状态,及时剔除不健康的服务实例,保证服务调用的可靠性。
-
服务发现的灵活性: 服务消费者可以从Eureka Server动态获取服务提供者的信息,无需硬编码服务提供者的地址,提高了系统的可维护性。
-
高可用性配置: 通过部署多个Eureka Server实例并实现它们之间的信息同步,Eureka可以构建高可用的注册中心,增强系统的容错能力。
-
与Spring Cloud的集成: Eureka与Spring Cloud生态的紧密集成,使得在Spring Cloud应用中可以轻松地实现服务的注册与发现,进一步简化了微服务的开发。
-
快速响应: Eureka优化了服务发现的速度,使得服务消费者能够迅速地获取服务提供者的最新信息,这对于需要快速响应的系统尤为重要。
-
简化的服务调用: 服务消费者无需关心服务提供者的具体位置,只需通过服务名即可访问服务,这大大简化了服务调用的复杂性。
-
容错和弹性: Eureka的设计允许系统在部分节点失败时继续提供服务,提高了系统的弹性和容错性。
-
监控和度量: Eureka提供了服务注册和发现的监控功能,有助于运维团队了解服务的健康状况和性能指标。
尽管Eureka项目已经停止官方维护,但它在许多现有的微服务架构中仍然发挥着重要作用。对于需要快速实现服务注册与发现功能的场景,Eureka仍然是一个有效的解决方案。