Ⅰ. 背景
一、问题描述
上个章节的例子中可以看到,远程调用时,我们的 URL 是写死的:
String url = "http://127.0.0.1:9090/product/" + orderInfo.getProductId();
当更换机器,或者新增机器时,这个 URL 就需要跟着变更,就需要去通知所有的相关服务去修改。随之而来的就是各个项目的配置文件反复更新,各个项目的频繁部署。这种没有具体意义,但又不得不做的工作,会让人非常痛苦。
二、注册中心
注册中心(Service Registry / Service Discovery Center)是微服务架构中一个核心组件,用来管理和维护服务实例的'地址簿'。它的核心作用是让服务能够动态发现其他服务的位置,而不依赖固定的 IP 或端口。
注册中心主要有三种角色:
- 服务提供者(Server):一次业务中,被其它微服务调用的服务。也就是提供接口给其它微服务。
- 服务消费者(Client):一次业务中,调用其它微服务的服务。也就是调用其它微服务提供的接口。
- 服务注册中心(Registry):用于保存 Server 的注册信息,当 Server 节点发生变更时,Registry 会同步变更。服务与注册中心使用一定机制通信,如果注册中心与某服务长时间无法通信,就会注销该实例。
注册中心主要负责两件事:
- 服务注册(Service Registration)
- 当一个服务实例启动时,它会把自己的信息(服务名、IP、端口、健康状态等)注册到注册中心。
- 示例:服务 A 启动 → 向注册中心注册自己为
A:IP:PORT。
- 服务发现(Service Discovery)
- 当一个服务需要调用另一个服务时,它不再去找固定 IP,而是向注册中心查询目标服务的可用实例列表。
- 示例:服务 B 需要调用服务 A → 查询注册中心 → 获取 A 的可用实例 → 调用。
- 健康检查(Health Check,可选)
- 注册中心通常会定期检查服务实例的状态,发现异常则剔除,保证服务调用可靠性。
三、CAP 理论
CAP 理论是分布式系统设计中最基础,也是最为关键的理论。
- 一致性(Consistency):CAP 理论中的一致性,指的是强一致性,即所有节点在同一时间具有相同的数据。
- 可用性(Availability):保证每个请求都有响应,但是响应结果可能是旧的。
- 分区容错性(Partition Tolerance):当出现网络分区后,系统仍然能够对外提供服务。
一个分布式系统不可能同时满足数据一致性,服务可用性和分区容错性这三个基本需求,最多只能同时满足其中的两个。
在分布式系统中,系统间的网络不能 100% 保证健康,服务又必须对外保证服务,因此 Partition Tolerance 不可避免,那就只能在 Consistency 和 Availability 中选择一个,也就是 CP 或者 AP 架构。
- CP 架构: 为了保证分布式系统对外的数据一致性,可能选择不返回任何数据
- AP 架构: 为了保证分布式系统的可用性,即使这个数据不正确
四、常见的注册中心
① Zookeeper
Zookeeper 的官方并没有说它是一个注册中心,但是国内 Java 体系大部分的集群环境都是依赖 Zookeeper 来完成注册中心的功能。
② Eureka
Eureka 是 Netflix 开发的基于 REST 的服务发现框架,主要用于服务注册、管理、负载均衡和服务故障转移。


