服务注册 / 服务发现 - Eureka

背景

问题出现

解决：

注册中心

[CAP 理论](#CAP 理论)

注册中心

[Eureka 介绍](#Eureka 介绍)

[搭建 Eureka Server](#搭建 Eureka Server)

服务注册

服务发现

背景

问题出现

上篇中，我们通过 RestTemplate 接口实现远程调用的时候，URL 的写死的。

当更换机器，URL 就需要发生变更，随之而来的就是各个项目的配置文件也都需要发生变化。

解决：

微服务开发中，可以采用类似 114 查号台的操作。

当服务启动 / 变更的时候，向注册中心报道，注册中心记录应用和 IP 的关系。

调用方调用的时候，先去注册中心获取服务方的 IP，再去服务方进行调用。

注册中心

注册中心，用于维护一个列表，那个机器上线了，那个机器宕机，这些信息都会自动更新到服务列表上，客户端拿到这个列表，直接进行服务调用即可。

注册中心主要有三种角色：

服务提供者（Server）：一次业务中，提供给接口给其他微服务。

服务消费者（Client）：一次业务中，调用其他微服务提供的接口。

服务注册中心（Registry）：用于保存 Server的注册信息，当 Server 节点发生变化的时候，Resigtry 会同步进行变更。服务与注册中心使用一定的机制来进行通信。如果注册中心和某服务长时间无通信，就会注销该实例。

三者之间的关系与工作内容可以用两个概念解释：

服务注册：服务提供者在启动的时候，向 Resgitry 注册自身服务，并向 Resgistry 定期发送心跳，汇报存活状态。

服务发现：服务消费者从注册中心查询到服务提供者的信息，并通过该地址调用服务提供者的接口。

注意：服务提供者和服务消费者的定义是相对的。

CAP 理论

CAP 理论是分布式系统中最基础，也是最关键的理论。

C：一致性。CAP 理论中的一致性，指的是强一致性。所有节点在同一时间具有相同的数据。

A：可用性。保证每个请求都有响应。（响应结果可能错误）

P：分区容错性。当出现网络分区后，系统仍然能够对外提供服务。

一致性：

有如下数据库集群

数据库集群需要向客户端进行响应。

响应时机有如下两种：

主库接收到请求，处理成功，此时数据并未完全同步到从库中。随着时间的推移，主库和从库的数据，最终会达到一个一致性。 ==》此时为弱一致性

主库接收到请求，并且所有从库数据同步成功成功。 ==》强一致性

CAP 理论：一个分布式系统，不可能同时满足数据一致性，服务可用性，分区容错性这三个基本需求，最多只能同时满足两个。

在分布式系统中，系统之间的网络不可能 100% 健康，服务又必须对外保证。因此分区容错性不可避免，所有只能再在 C 和 A 中选择一个。也就是 CP 或者 AP 架构。

CP 架构：为了保证分布式系统对外的数据统一性，在第二位滑稽老铁读数据的时候，就不给他返回任何数据。

AP 架构：为例保证分布式系统的可用性，在第二位滑稽老铁读数据的时候，会给他返回 V0 版本的数据（即使这个数据已经错误了）

CAP 理论详情可参考文章：一文理解 CAP （大佬写的非常好~~~）

注册中心

Zookeeper 注册中心实现的是 CP，也就是保证数据一致性。

Eureka 注册中心实现的是 AP，也就是保证数据可用性。

Nacos 注册中心可用实现 AP 或 CP，默认实现 AP

在分布式环境中，即使拿到一个错误的数据，也胜过无法提供实例信息而造成请求失败要好（淘宝，京东实现的都是 AP 原则）

Eureka 介绍

Eureka 是 Netflix OSS 套件中关于服务注册和发现的解决方案。 SpringCloud 对 Eureka 进行了集成,并作为优先推荐方案进行宣传,虽然目前 Eureka2.0 已经停止维护,新的微服务架构设计中,也不再建议使用,但是目前依然有大量公司的微服务系统使用 Eureka 作为注册中心。

Eureka 分为两部分：

Eureka Server ：作为注册中心的服务端，为微服务应用提供服务注册，服务发现，健康检查等核心能力。

Eureka Client ：作为服务提供者 的客户端，当服务启动时，会主动向 Eureka Server 注册自身信息。Eureka Server 会存储这些信息，以供其他服务查询和调用。