注册中心-Eureka

最新推荐文章于 2024-10-13 15:17:25 发布

程序猿之魂

最新推荐文章于 2024-10-13 15:17:25 发布

阅读量179

点赞数

分类专栏： SpringCloud 文章标签： eureka java spring cloud

本文链接：https://blog.csdn.net/qq_40814565/article/details/124926730

版权

SpringCloud 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

一、服务调用出现的问题

服务消费者该如何获取服务提供者的地址信息？
如果有多个服务提供者，消费者该如何选择？
消费者如何得知服务提供者的健康状态？

二、Eureka的作用

在这里插入图片描述

消费者该如何获取服务提供者具体信息？
服务提供者启动时向eureka注册自己的信息
eureka保存这些信息
消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者，消费者该如何选择？
服务消费者利用负载均衡算法，从服务列表中挑选一个
消费者如何感知服务提供者健康状态？
服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
eureka会更新记录服务列表信息，心跳不正常会被剔除
消费者就可以拉取到最新的信息

在Eureka架构中，微服务角色有两类：

EurekaServer：服务端，注册中心
记录服务信息
心跳监控
EurekaClient：客户端

Provider：服务提供者，例如案例中的 user-service
注册自己的信息到EurekaServer
每隔30秒向EurekaServer发送心跳

Consumer：服务消费者，例如案例中的 order-service
根据服务名称从EurekaServer拉取服务列表
基于服务列表做负载均衡，选中一个微服务后发起远程调用

三、动手实践

在这里插入图片描述

搭建EurekaServer

搭建EurekaServer服务步骤如下：
1、创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖：

<dependencies>
        <!--eureka服务-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>
</dependencies>

2、编写启动类，添加@EnableEurekaServer注解

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}

3、添加application.yml文件，编写下面的配置：

server:
  port: 10086 #服务端口
spring:
  application:
    name: eurekaserver #服务名称
eureka:
  client:
    service-url: # eureka地址信息
      defaultZone: http://127.0.0.1:10086/eureka

在这里插入图片描述

注册user-service

将user-service服务注册到EurekaServer步骤如下：
1、在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖：

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2、在application.yml文件，编写下面的配置

spring: 
 application:
  name: userservice
eureka:
 client:
  service-url:
   defaultZone: http://127.0.0.1:10086/eureka/

在这里插入图片描述
2、userservice 本机部署多个实例
另外，我们可以将user-service多次启动，模拟多实例部署，但为了避免端口冲突，需要修改端口设置：

order-service完成服务注册

order-service虽然是消费者，但与user-service一样都是eureka的client端，同样可以实现服务注册：
1、在order-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2、在application.yml文件，编写下面的配置：

spring: 
 application:
  name: orderservice
eureka:
 client:
  service-url:
   defaultZone: http://127.0.0.1:10086/eureka/

在这里插入图片描述

总结

1、服务注册
引入eureka-client依赖
在application.yml中配置eureka地址
2、无论是消费者还是提供者，引入eureka-client依赖、
知道eureka地址后，都可以完成服务注册

在order-service完成服务拉取

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
1、修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：

String url = "http://userservice/user/" + order.getUserId();

OrderService层：

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
//        String url = "http://localhost:8081/user/"+order.getUserId();
        String url = "http://userservice/user/"+order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
//        ResponseEntity<User> responseEntity = restTemplate.getForEntity("http://localhost:8081/user/1", User.class);

        // 4.返回
        return order;
    }

2、在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
	return new RestTemplate();
}

在这里插入图片描述

四、Zookepper与Eureka区别

1、首先介绍一下CAP定理

在分布式系统中有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）
在这里插入图片描述

2、Zookeeper

定义：简单的说zookepper=文件系统+监听通知机制
Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目，用来控制集群中的数据，目前已升级为独立的顶级项目。很多场景下也用它作为Service发现服务解决方案。
Zookeeper是基于CP理论来设计的，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。

从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。所以说，Zookeeper不能保证服务可用性。

诚然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。

但是对于服务发现场景来说，情况就不太一样了：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。（尝试一下可以快速失败，之后可以更新配置并重试）所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。

1.1 Zookeeper的主从机制

Leader等价于Master，Follower等价于Slaver。集群中的各个节点都会尝试注册为leader节点，其他没有注册成功的则成为follower从节点。

这些follower节点通过watcher观察者监控着leader节点：

Zookeeper内部通过心跳机制来确定leader的状态，一旦leader节点出现问题，就能很快获悉并迅速通知其他follower节点，这些follower节点得知消息之后将及时采取相关操作。

1.2 脑裂现象的表现

zookeeper集群中，各个节点间的网络通信不良时，容易出现脑裂(split-brain)现象;

集群中的节点监听不到leader节点的心跳，就会认为leader节点出了问题，此时集群将分裂为不同的小集群，这些小集群会各自选举出自己的leader节点，导致原有的集群中出现多个leader节点，这就是脑裂现象。

1.3 为什么会出现脑裂

1.  集群中网络通信不好，导致心跳检测超时--follower认为leader节点由于某种原因挂掉了，可其实leader节点并未真正挂掉，这就是假死现象。

2.  leader节点假死后，zookeeper通知所有follower节点进行选举-->某个follower节点升级为新的leader，此时集群中存在2个leader节点。

3.  此时zookeeper需要将新的leader节点的信息通知给所有的follower节点，还要通知到所有的client，而这个过程由于网络等环境的影响，消息到达就会存在快慢之分。

4.  如果部分client获得了新的leader节点的信息，而部分没有获得，而此时client向zookeeper发起读写请求，zookeeper内部的不一致就会导致：部分client连接到了新的leader节点上，而部分client连接到了旧的leader节点上--服务中出现了2个leader，client不知道听谁的好，就像1个大脑被分裂成2个。

1.4 zookeeper如何解决脑裂

ZooKeeper默认采用了Quorums(法定人数)的方式: 只有获得超过半数节点的投票, 才能选举出leader，这种方式可以确保要么选出唯一的leader，要么选举失败。

ZooKeeper中Quorums的作用:

1.  指定集群中选举leader所需的最少节点数, 保证集群可用;

2.  client的数据被安全保存到集群中所需的最少节点数, 一旦这些节点保存了数据, 客户端将被通知数据已经安全保存, 可以继续其他任务 —— 基于最终一致性, 集群中剩余的节点最终也会保存相关的数据.

ZooKeeper的写也遵循quorum机制, 因此得不到大多数支持的写是无效的.

1.5 zookeeper的具体解决思路

假设: leader发生了假死, followers选举出了一个新的leader.

当旧的leader复活并认为自己仍然是leader, 它向其他followers发出写请求时, 会被拒绝.

因为ZooKeeper维护了一个叫epoch的变量, 每当新leader产生时, epoch都会递增, followers如果确认了新的leader存在, 同时也会知道其epoch的值—— 它们会拒绝epoch小于现任leader的epoch的所有旧leader的任何请求.

注意: 仍然会存在有部分followers不知道新leader的存在, 但肯定不是大多数, 否则新leader将无法产生.

脑裂问题剖析
在这里插入图片描述
对于zookeeper，它是一个主从架构，而像Eureka它是一个点对点的架构，对于脑裂问题，一般都是发生在主从架构，它是怎么发生的呢？比如，现在我们有一个zookeeper集群，它有三个节点，当主节点与其它节点发生了网络故障分区了，正常情况下，主节点与从节点会有数据同步的。

以zookeeper这种cp模式的集群架构来说，cp模式，写数据只能写主节点，从节点只能查数据，假如往从节点写数据，它会帮我们转移到主节点，主节点才提供写，其他节点只能提供读。如果主节点写一条数据，发现网络分区了，主节点数据不能同步到其他从节点，这里面会有一个问题，由于网络不通了，zookeeper集群被分为了两个小的集群，但是，小的集群没有leader了，不能提供写服务了，zookeeper底层会发起一个集群leader选举，这样就会产生两个leader，每个小集群都能接受客户端发来的请求。如果网络恢复了，新的leader是不会动的，旧的leader会同步新的leader的所有数据，那问题就来了，在分区的时候，往久的leader写的数据都会丢失，这就是脑裂。

zookeeper是不会有脑裂问题

它底层实现了ZAB协议，只有半数以上的节点同意，才会写入成功，否则报错。比如，现在我们三个点，那半数以上也就是有两个节点同意。对于新leader刚好两个(算是它自己)，而对于旧 leader的，就只有一个节点，所以，它是不会写入成功的。

Nacos解决脑裂问题
nacos即支持AP模式又支持CP模式，它底层实现了Raft协议，下面从源码来看，它是如何解决脑裂问题的。
在这里插入图片描述

最后总结一下两者的区别