Eureka是SpringCloud Netflix的子组件,作用是注册中心,类似于Dubbo的Zookeeper,以及Alibaba的Nacos,负责查看和管理各个微服务的情况,同时也协调了各个微服务

Eureka分类Eureka-Server和Eureka-Client两部分,
1.Eureka-Server:通过 REST 协议暴露服务，提供应用服务的注册和发现的功能
2.Application Server:也被称为服务的提供者,向Eureka-Server提供注册服务
3.Application Server:也被称为服务的消费者,向Eureka-Server拉取服务注册信息
注:没有严格意义的划分清晰的 Application Server, Application Client,微服务间各个服务间相互之间都是消费者和提供者的关系,从这两个组件搭建时的依赖就可知晓

这里先普及几个关于注册中心的概念

  1. Register（注册）
    服务提供方使用 Eureka-Client 注册自己到 Eureka-Server 上，添加到注册表，成为服务的一个实例。

  2. Renew（续租）
    服务提供方使用 Eureka-Client 每 30 秒(可在配置文件中修改,但不建议)向 Eureka-Server 发起一次心跳，告诉 Eureka-Server 当前服务实例还存活。
    如果 Eureka-Server 90 秒没有收到 Eureka-Client 的心跳，会认为它已经下线，将该服务实例从注册表移除。

    为什么需要心跳？Eureka 采用 REST 短连接，而非 TCP 长连接(这种连接相当耗费资源,也不利于大规模搭建,网络带宽压力太大)，所以需要通过心跳机制来确认是否存活。

  3. Get Registry（获取注册信息）
    服务消费者使用 Eureka-Client 从 Eureka-Server 获取全量注册表，并缓存在本地内存。之后，服务消费者要远程调用服务提供者时，只需要从本地缓存的注册表查找对应的服务即可

  4. Cancel（下线）
    服务提供者准备下线时，使用 Eureka-Client 向 Eureka-Server 发起取消注册请求，从而从注册表中移除，避免后续服务消费者请求当前实例。
    一般来说，我们把这种方式称为 “正常下线”。与之相对的，就是心跳超时导致的 “异常下线”。
    我们先来看看 Eureka-Server 之间的交互行为：

Eureka-Server 在 CAP 定理 中，选择了 AP 来实现：
一致性（Consistency）：等同于所有节点访问同一份最新的数据副本。
可用性（Availability）：每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据。

这里科普一下CAP定理

  • 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
  • 可用性（ Availability）（每次请求都能获取到非错的响应 —— 但是不保证获取的数据为最新数据）
  • 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择）

这是经过科学推导过的,只能保证AP或者CP两者中的一个,互联网的不同注册中心有着不同的实现

Eureka-Server

Eureka由于实现的是AP,这使得Eureka-Server的集群中是不存在像CP实现的Zookeeper的选举,master节点的,Eureka的每个节点都是平等,扮演的都是相同的角色

Eureka-Server的环境搭建

image.png
在idea的Spring初始化页面中选好Eureka Server即可完成一个单节点的Eureka Server注册中心的搭建

  1. 首先将视角移向启动类
    image.png
    除了SpringBoot的启动注解外,加上一个@EnableEurekaServer注解即完成了注册中心的声明配置
  2. 然后添加下配置文件Eureka Server的配置image.png
    由于我们目前搭建的是一个单节点的注册中心,所以我们将
    register-with-eureka改为false
    fetch-register改为false
    Eureka Server集群环境下会互相注册
  3. 启动上述的启动类,然后打开对应配置端口的页面
    image.png

Eureka Server的集群搭建

  1. 首先需要准备好三份上述的Eureka Server模块,
    image.png

  2. 然后将配置文件除了上述那两项修改为true,添加服务器的主机名,以及添加其他注册中心的主机地址
    image.png
    image.png
    为了方便在本地环境搭建相应的集群,还需要修改下host环境

    127.0.0.1 eureka-a eureka-b

  3. 设置好后,启动A B两个配置类,启动过程中可能日志会有报错,这是服务端寻找另一个服务端,但另一个服务端还没有启动时的情况,不必惊慌(Sit back and relax：坐和放宽)
    image.png

服务消费者+服务提供者

提供者

  1. 首先在Spring初始化页面选择以上依赖
    image.png
  2. 在旧版本Spring Cloud Netflix Eureka client 是需要在启动类上添加@EnableDiscoveryClient注解
    在目前的版本在引入依赖后会自动进行注册发现,所以可以不用再添加该注解
    image.png
  3. 然后配置文件与上述Server端差不多
    image.png
  4. 写好一个接口供消费者进行测试
    image.png
    接下来我们去搭建一个消费者的Eureka-client

消费者

  1. 同上引入依赖
  2. 配置文件image.png
  3. 这里与上方服务提供者不同之处,在于我们引入了一个RestTemplate(这个类来自于Spring本身,并非Spring Cloud才有的Bean)
    image.png
    目前还是单节点消费者,单节点服务提供者,所以这里的代码级别的负载均衡注解暂时注释,日后再用
    image.png
    1.借助RestTemplate来实现对服务提供者的接口的调用
    image.png
  4. 这里我们请求的时消费者8100端口的hello接口,但获得了服务提供者8091端口的echo接口的信息
    image.png

Q.E.D.